Oracle7 Enterprise Backup Utility Administrator's Guide Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index



Go to previous file in sequence Go to next file in sequence

Backing Up a Database


This chapter explains how to back up data in an Oracle7 database using the Enterprise Backup Utility.

Topics covered in this chapter are:

Performing Backups

The following steps outline the procedure for backing up a target database.

  1. Verify the EBU Catalog is up-to-date by running the register command. (This is only needed under the circumnstances discussed in chapter 3.)
  2. Prepare a backup command script.
  3. Verify the target database is in the correct state: open for online backups, and closed and shut down for offline backups (if using Oracle Parallel Server, ensure that all instances are down for an offline backup.)
  4. Invoke the backup job.

    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

Backup command scripts tell the Enterprise Backup Utility how to perform a particular job. Following are several sample backup scripts:

Example 4-1 Command script for performing backup offline database.

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.log

Example 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".

 

Offline Backup Command Scripts

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:

  1. Notify users that the database will be shut down in x minutes and ask users to log out of the database.
  2. Sleep for a fixed period of time while users log out.
  3. Verify the current configuration information in the EBU Catalog by running the register command.
  4. Shut down the server with the SHUTDOWN IMMEDIATE statement.
  5. Sleep for a fixed period of time while the SHUTDOWN IMMEDIATE statement completes.
  6. Issue the SHUTDOWN ABORT statement. If the SHUTDOWN IMMEDIATE statement has already completed within the specified time, this has no effect. Otherwise the SHUTDOWN ABORT overrides the SHUTDOWN IMMEDIATE statement and shuts down the database.
  7. Start up the database in RESTRICTED mode. This is important because a database cannot be backed up in the SHUTDOWN ABORT state (it might have uncommitted transactions).
  8. If the database is operating in ARCHIVELOG mode, archive the current online redo log file to back it up with other datafiles. If the database is operating in NOARCHIVELOG mode, switch the current online redo log file by performing a checkpoint. This ensures that transactions are written to disk.
  9. Shut down the database normally.
  10. Invoke the ebu executable to perform a backup offline database.
  11. Startup the database.

Backup Types and Strategies

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.

Database State During Backup

Offline Backup

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.

startup_pfile

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 Backup

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.

Completeness of Backup

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.

Table 4-1 Types of Backups Performed by the Enterprise Backup Utility
Backup   Offline   Online  

database

 

supported

 

supported

 

<subset>

 

not supported

 

supported

 

Datafile Backup

include_dbfile

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.

allow_corrupt

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 File Backup

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?

 

Archived Redo Log Backup

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.

arch_per_bfs

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.

arch_copies

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.

Deleting Backed-Up Log Files

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.

Archived Logs and Oracle Parallel Server

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.


Caution:

You must back up the archived log files from every instance in an Oracle Parallel Server cluster. To back up all the archived log files for all the nodes in a cluster, you should explicitly specify the LOG_ARCHIVE_DEST for every node, including the one from which you are performing the backup, in the archivelog clause of the backup command script.

 

EBU Catalog Backups

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.

 

Read-Only Tablespaces

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.

Offline Tablespaces/Datafiles

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.

Lights-Out or Unattended Backups

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.

Online Redo Logs

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 Requirements

Oracle Parallel Server installations must follow these requirements when backing up archived redo log files:

  1. The log archive destination for each instance must be known to all other instances, and each instance should refer to it by the same name.

    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.

  2. The thread number must be hard-coded in the instance-specific initsid.ora file and should not be changed for the life of the database.


Caution:

If you fail to hard-code instance thread numbers, the thread number for each instance defaults to the order in which it was brought online. In such a case, the thread number for an instance may vary over the life of the instance, making it difficult or impossible to restore archived log files.

 

  1. The initsid.ora parameter LOG_ARCHIVE_FORMAT must include the thread number, and the format must be consistent across all the nodes in a cluster.

Additional Information:

See Oracle7 Parallel Server Concepts and Administration for more information about thread numbers and log archiving.

 




Go to previous file in sequence Go to next file in sequence
Prev Next
Oracle
Copyright © 1997 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index