Oracle7 Enterprise Backup Utility Administrator's Guide | ![]() Library |
![]() Product |
![]() Contents |
![]() Index |
This chapter explains how to back up data in an Oracle7 database using the Enterprise Backup Utility.
Topics covered in this chapter are:
The following steps outline the procedure for backing up a target database.
To invoke a backup job directly, use the Enterprise Backup Utility command ebu from either the UNIX shell prompt or NT DOS prompt, or from within your administrative or media management software, e.g. Oracle Enterprise Manager:
$ ebu script_name
Alternatively, you can embed the ebu command in a script among other commands that take care of pre- and post-backup activities, such as database shutdown and startup. (See "Offline Backup Command Scripts".)
Backup command scripts tell the Enterprise Backup Utility how to perform a particular job. Following are several sample backup scripts:
backup offline database parallel = 4 log = "/opt1/oracle/ebu/log/obkPROD.log"Example 4-2 Command script for performing backup online database.
backup online database parallel = 3 log=?/obackup/log/bona.logExample 4-3 Command script for performing backup online <subset> of tablespaces A and B, and the control file(s).
backup online db_name = "PROD" control_file tablespace = "A","B"
Additional Information:
For a full description of the command scripts, see Appendix A, "Command Script Syntax". |
A backup script is a wrapper for the backup command script to take care of pre- and post-backup activities. For instance, for a backup offline database, the script might shut down the database and verify the registration in the EBU Catalog before invoking the backup, then bring the database up after the backup is completed.
A sample template for the UNIX operating system is provided for reference purposes when creating backup offline database shell scripts. The script is installed as EBU_HOME/admin/lightsout.sh.
In general, any backup offline database shell script should perform the following steps:
The type of backup you perform depends on the state of the database and the completeness of the backup. A database backup strategy may employ a combination of backup types to balance the sometimes-conflicting demands of availability, system resources, and minimized recovery time in the event of failure.
Different system priorities suggest different backup strategies. If database availability is the highest priority, for instance, the strategy might exclusively use online backups, and run them frequently in order to minimize recovery time. This strategy would use system resources more intensively, but provide greater protection against downtime.
An offline backup is one taken after the database is cleanly shut down. That is, it is not taken after an instance failure, SHUTDOWN ABORT, or other such shutdown. During the backup, the database is not available for normal operations. Since the database is closed, all its files are closed and consistent with respect to the point-in-time of the backup.
If you run your database in NOARCHIVELOG mode, offline backups are the only backup option that provides any protection against media failure.
Before taking an offline backup, the database is brought up to a mount state so that EBU can query the current registration against what was stored in the catalog for any changes. EBU will mount the database using the default parameter file initsid.ora. You can overwirte this by explicitly specifying another pfile to mount the database using the startup_pfile specifier. See "How Recovery Works" for other examples of this specifier.
Online backups allow users to use the database while the backup is being performed. Taking an online backup, however, means that recovery is necessary following a restore operation, since database blocks are being updated during the backup.
If you want to use online backups, you must operate your database in ARCHIVELOG mode so that online redo logs are archived. The redo logs can then be applied to recover the database to the point in time immediately before the failure.
Backups taken from offline tablespaces in an online database are still considered online backups: whether a backup is online or offline depends on the state of the database at the time, not the state of the tablespaces. Offline datafiles are not backed up by default. Online datafiles in a tablespace containing offline datafiles during online backups cannot be backed up. Additionally, if EBU finds any tablespace already in BACKUP mode, it fails and returns an error.
A backup can also be characterized by its completeness - whether it contains all files belonging to a database or only a subset of them. A database is composed of one or more files of the following file types:
Backups that include all database files are performed with the backup database command. Backups that include only a subset of the database files are performed with the backup <subset> command. In a subset backup, each of the tablespaces or other file types must be specified within the subset clause. <-- There's no subset clause anymore!
Based on the backup types described above, there are four backup methods. Table 4-1, "Types of Backups Performed by the Enterprise Backup Utility" shows the support matrix for the Enterprise Backup Utility.
Backup | Offline | Online |
---|---|---|
database |
supported |
supported |
<subset> |
not supported |
supported |
EBU will not backup offline datafiles by default. You may, however, use the include_dbfile specifier to include any offline files in a backup script. The backup will be an image backup, i.e. no block header verification will be performed. See "Include_dbfile Restore" on page 5-4 for restoring files backed up with this specifier.
Online datafiles in a tablespace with offline datafile(s) cannot be backed up during online backups even if the offline datafiles are.
EBU will detect files with corrupted block headers and abort the backup job. You may specify the allow_corrupt specifier to force EBU to backup the file(s) with corrupted block headers and report warnings. By default EBU will report the number of blocks which the RDBMS has flagged as corrupted and have been patched by it.
Control files keep track of a database and its physical file structure. You should back up the control file immediately any time you make a structural change to a database.
EBU backs up the control file whenever at least one database file or archivelog is specified for backup. The utility automatically gets the name of the control file from the EBU Catalog and backs it up. Control files are always backed up after all datafiles, because they store all the header information for datafiles, which is required to perform recovery.
Even when the control file is mirrored, the Enterprise Backup Utility backs up only one copy of the control file. On restore, the utility restores the control file, then creates mirrored copies according to the locations specified in the target database data dictionary.
The Enterprise Backup Utility backs up control files in offline backups somewhat differently than in online backups. In an offline backup, the utility backs up the actual control file. In an online backup, EBU uses the ALTER DATABASE BACKUP CONTROLFILE command, then backs up the copy. You may set the specifier tempdir to specify the directory where the ALTER DATABASE BACKUP CONTOLFILE command backs up the control file to. By default, the controlfile copy is made in the database default directory. If the database must be restored, the presence of the copied control file forces the database to recognize that some recovery action must be performed.
Additional Information:
The syntax for control file backup, as well as other file types that can be specified within a subset clause, is given in Figure A-6, "<param_clause> Syntax" . PARAM CLAUSE? |
EBU backs up archived redo logs by default for both online and offline backups. EBU identifies archived log files by querying the target database for the current LOG_ARCHIVE_DEST, as specified by the RDBMS parameter file initsid.ora, then backing up all the files that match the format specified by the RDBMS parameter LOG_ARCHIVE_FORMAT. EBU will issue warnings for any missing archived redo logs during the backup, either from job to job, or intra-job.
For performance, archived redo logs are backed up in a "tar-like" BFS format. You can specify the number of archived redo logs to be put into one BFS by the ARCH_PER_BFS specifier. The default is 32 if it is not specified. The maximum number of archived redo logs per BFS is 128.
As a safety measure, EBU can also back up the archived redo logs multiple times in case one copy of the back up of the logs is corrupt or lost. This can be accomplished with the arch_copies specifier. The maximum number of copies for a job is 4.
You can specify that archived log files be deleted after the utility has backed them up. This is not the default, but can be enabled in the EBU command script with the archdelete specifier. When archdelete is specified, EBU deletes all but the most recent archive log file from each directory specified. EBU does not delete any archived log file that it has not backed up, nor does it delete files that do not match the format specified by the LOG_ARCHIVE_FORMAT parameter.
If you do not delete archived redo log files after backing them up, EBU continues to back them up with each backup job that includes archived log files.
When backing up a cluster, Enterprise Backup Utility default treatment of archived log files only applies to the instance from which the backup is being performed: only the one instance's archived log files are backed up automatically.
The EBU Catalog is backed up by default after every backup job that includes at least one database object (so backing up only the RDBMS parameter files, for instance, does not automatically back up the catalog). The backup catalog is first written to a file on disk (The default directory is $EBU_HOME/admin; however, you may use the tempdir in your scripts to override this default), and then the BFS is backed up to the media device. Catalog backup can be specified explicitly, or disabled for any backup job.
Additional Information:
See "Backing Up and Restoring the EBU Catalog" for information on catalog backup. |
The Enterprise Backup Utility treats read-only tablespaces like regular tablespaces, backing them up for backup database operations and restoring them for restore database operations.
If you want to avoid backing up read-only tablespaces, you must generate a list of all tablespaces, excluding the read-only tablespaces, to explicitly identify tablespaces in the command scripts.
This technique can also be used to exclude temporary tablespaces.
When a tablespace is placed offline, all datafiles are offline so they are not backed up by default during online or offline backups. You can use include_dbfile to include them during both online and offline backups.
When a subset of the datafiles comprising a tablespace are offline, the remaining files cannot be backed up during online backups. The offline datafiles can be backed up by using the include_dbfile specifier.
During offline backups, the online datafiles are backed up by default, however, the offline datafiles are not backed up unless the include_dbfile specifier is used.
A lights-out or unattended backup is a backup which, once set up, is performed automatically. This release of the Enterprise Backup Utility relies on the third-party media management software to schedule and initiate lights-out backups.
To set up a lights-out backup, use the third-party media management vendor software to define a lights-out backup schedule. Then provide the pathname of a backup shell script to the media management software so the script can be invoked at the scheduled time.
Lights-out backups can also be scheduled as cron jobs.
Additional Information:
For more detailed information on how to set up a lights-out backup, refer to the documentation provided by your media management software vendor. |
A sample script for the UNIX operating system, lightsout.sh, is included with EBU and installed in EBU_HOME/admin.
The only method of preserving data in online redo logs against media failure is to duplicate the logs on different physical devices. Oracle Corporation recommends that you mirror online redo logs. Backing up online redo logs adds no value to the recovery process, so they are not backed up by the Enterprise Backup Utility:
Oracle Parallel Server installations must follow these requirements when backing up archived redo log files:
For example, if node 1 has /arch/n1 as its LOG_ARCHIVE_DEST, all other nodes should have that directory mounted as /arch/n1.
If this is accomplished by NFS-mounting the other instance LOG_ARCHIVE_DEST directories, the mounts must include the write option. The utility must have write access to all instance LOG_ARCHIVE_DEST directories.
Additional Information:
See Oracle7 Parallel Server Concepts and Administration for more information about thread numbers and log archiving. |
![]() ![]() Prev Next |
![]() Copyright © 1997 Oracle Corporation. All Rights Reserved. |
![]() Library |
![]() Product |
![]() Contents |
![]() Index |