Oracle Parallel Server Requirements
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 backup catalog is up-to-date by running the register command.
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.
4. Invoke the backup job.
To invoke a backup job directly, use the Enterprise Backup Utility command obackup from either the UNIX shell prompt or from within your media management software:
$ obackup script_name
Alternatively, you can embed the obackup command in a backup shell script among other shell commands that take care of pre- and post-backup activities, such as database shutdown and startup (see "Offline Backup Shell Scripts ![[*]](jump.gif)
).
Backup Command Scripts
Backup command scripts tell the Enterprise Backup Utility how to perform a particular job. Following are several sample backup scripts:
Example 1
Command script for performing backup offline database.
backup offline database
db_name = "PROD"
oracle_sid = "PROD"
parallel = 4
log = "/opt1/oracle/obackup/log/obkPROD.log"
Example 2
Command script for performing backup online database.
backup online database
db_name = "PROD"
oracle_sid = "PROD"
parallel = 3
Example 3
Command script for performing backup online <subset> of tablespaces A and B, and the control file(s).
backup online
db_name = "PROD"
oracle_sid = "PROD"
control_file
tablespace = "A","B"
Additional Information: See Also: For a full description of the command scripts, see Appendix A, "Command Script Syntax".
Offline Backup Shell Scripts
A backup shell 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 shell script might shut down the database and verify the registration in the backup catalog before invoking the backup, then bring the database up after the backup is completed.
A sample template is provided for reference purposes when creating backup offline database shell scripts. The script is installed as $OBK_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 backup 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 all transactions are written to disk.
9. Shut down the database normally.
10. Start and mount the database, then select the database checkpoint.
11. Shut down the database normally.
12. Invoke the obackup executable to perform a backup offline database.
13. After the backup job, start and mount the database, select the checkpoint and open the database.
14. Compare the database checkpoint values collected before and after the backup. If the value obtained in Step 10 is not the same as that obtained in Step 13, the backup should be invalidated.
If the values are the same, you should invoke obackup to perform a backup of the archived redo logs. This step enables rolling forward from the previous backup, in the event that becomes necessary
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.
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. 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:
- parameter file (initsid.ora and configdb_name.ora files)
- archived redo log file (may exist)
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.
Based on the backup types described above, there are four backup methods: Table 4 - 1 shows the support matrix for the Enterprise Backup Utility.
Backup
Offline
Online
database
supported
supported
<subset>
not supported
supported
Table 4 - 1. Types of Backups Performed by the Enterprise Backup Utility
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 is specified for backup. The utility automatically gets the name of the control file from the backup catalog and backs it up. Control files are always backed up last, because they store all the header information for datafiles, which is required to perform recovery.
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. 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: See Also: The syntax for control file backup, as well as other file types that can be specified within a subset clause, is given .
Archived Redo Log Backup
EBU backs up archived redo logs by default for online backups. EBU does not back them up for offline backups, because the database must be online to determine a starting log sequence number (LSN) and log format. However, the backup online archivelog command can be added to offline backup shell scripts, thereby automating the archived log backup.
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.
Oracle Corporation recommends the you not change the LOG_ARCHIVE_FORMAT over the life of the database. This is because EBU backs up only those files matching the current LOG_ARCHIVE_FORMAT. If the format were changed between backups, files matching the old format would not be backed up by EBU.
Note: EBU does not support the use of the star (*) or pound (#) wildcards within the LOG_ARCHIVE_FORMAT.
When EBU initiates an online backup (by issuing the SQL statement ALTER TABLESPACE with the BEGIN BACKUP option), the Oracle7 Server stops recording the occurrence of checkpoints in the headers of the online datafiles being backed up. This means that when a datafile is restored, it "knows" of the most recent datafile checkpoint that occurred before the online backup, not any that occurred during it. As a result, the Oracle7 Server asks for the appropriate set of redo log files to apply, should recovery be needed. Once an online backup is completed (as indicated by the SQL statement ALTER TABLESPACE with the END BACKUP option), the Oracle7 Server advances the file header to the current database checkpoint.
After backing up all control, parameter, and data files, EBU issues the statements ALTER SYSTEM ARCHIVELOG ALL and ALTER SYSTEM ARCHIVELOG CURRENT to ensure that all the log files belonging to the backup period are archived so the utility can back them up.
Alternative directories can also be specified in the command script, but the files in LOG_ARCHIVE_DEST are not backed up automatically if you specify another directory to back up. If you wish to back up additional directories of archived redo logs, you must explicitly indicate all the directories (including the LOG_ARCHIVE_DEST directory) in the command script.
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.
Attention: 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.
Backup Catalog Backups
The backup 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). Catalog backup can be specified explicitly, or disabled for any backup job.
Additional Information: See Also: "Backing Up the Backup Catalog" for information on catalog backup.
Read-Only Tablespaces
The Enterprise Backup Utility treats read-only tablespaces like offline 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 offline and temporary tablespaces.
Lights-Out or Unattended Backups
A lights-out or unattended backup is a backup that, 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.
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:
- If the database runs in ARCHIVELOG mode, all online redo logs are archived and backed up.
- If the database runs in NOARCHIVELOG mode, offline backups should be taken only when the database is shut down cleanly. A clean shutdown ensures that the offline backup will be able to bring the database to a consistent point-in-time with only minimal recovery. See "OPEN RESETLOGS" for essential information on "minimal" recovery.
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.
Warning: 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.
3. The initsid.ora parameter LOG_ARCHIVE_FORMAT must have the thread number hard-coded, 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. See page A - 24 for detailed syntax instructions regarding archived redo log files.
