The redo logs can then be applied to recover the database to the point in time immediately before the failure. In an online backup, EBU uses the ALTER DATABASE BACKUP CONTROLFILE command, then backs up the copy. If you run your database in NOARCHIVELOG mode, offline backups are the only backup option that provides any protection against media failure. The only method of preserving data in online redo logs against media failure is to duplicate the logs on different physical devices. EBU will issue warnings for any missing archived redo logs during the backup, either from job to job, or intra-job. 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. Oracle Enterprise Manager: 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. The maximum number of copies for a job is 4.
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.
EBU will mount the database using the default parameter file initsid.ora. The Enterprise Backup Utility backs up control files in offline backups somewhat differently than in online backups.
The following steps outline the procedure for backing up a target database. Different system priorities suggest different backup strategies. A sample script for the UNIX operating system, lightsout.sh, is included with EBU and installed in EBU_HOME/admin.
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. By default, the controlfile copy is made in the database default directory. 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. (See "Offline Backup Command Scripts".). The script is installed as EBU_HOME/admin/lightsout.sh. For performance, archived redo logs are backed up in a "tar-like" BFS format. Additionally, if EBU finds any tablespace already in BACKUP mode, it fails and returns an error.
Table 4-1, "Types of Backups Performed by the Enterprise Backup Utility", "Backing Up and Restoring the EBU Catalog". You may set the specifier tempdir to specify the directory where the ALTER DATABASE BACKUP CONTOLFILE command backs up the control file to. A lights-out or unattended backup is a backup which, once set up, is performed automatically. This can be accomplished with the arch_copies specifier. Since the database is closed, all its files are closed and consistent with respect to the point-in-time of the backup. For more detailed information on how to set up a lights-out backup, refer to the documentation provided by your media management software vendor.
If this is accomplished by NFS-mounting the other instance LOG_ARCHIVE_DEST directories, the mounts must include the write option.
Following are several sample backup scripts: For a full description of the command scripts, see Appendix A, "Command Script Syntax". This technique can also be used to exclude temporary tablespaces.
Table 4-1, "Types of Backups Performed by the Enterprise Backup Utility" shows the support matrix for the Enterprise Backup Utility. The utility must have write access to all instance LOG_ARCHIVE_DEST directories. 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. Online datafiles in a tablespace containing offline datafiles during online backups cannot be backed up. You can specify that archived log files be deleted after the utility has backed them up. The utility automatically gets the name of the control file from the EBU Catalog and backs it up. You can use include_dbfile to include them during both online and offline backups. 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. no block header verification will be performed.
Oracle Corporation recommends that you mirror online redo logs. 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 default is 32 if it is not specified. In an offline backup, the utility backs up the actual control file. When a subset of the datafiles comprising a tablespace are offline, the remaining files cannot be backed up during online backups. See "Include_dbfile Restore" on page 5-4 for restoring files backed up with this specifier. The backup will be an image backup, i.e. Control files are always backed up after all datafiles, because they store all the header information for datafiles, which is required to perform recovery. EBU backs up the control file whenever at least one database file or archivelog is specified for backup. Offline datafiles are not backed up by default. The maximum number of archived redo logs per BFS is 128. Catalog backup can be specified explicitly, or disabled for any backup job. When archdelete is specified, EBU deletes all but the most recent archive log file from each directory specified. EBU will not backup offline datafiles by default.
Based on the backup types described above, there are four backup methods. This chapter explains how to back up data in an Oracle7 database using the Enterprise Backup Utility. Taking an online backup, however, means that recovery is necessary following a restore operation, since database blocks are being updated during the backup. 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. Control files keep track of a database and its physical file structure. Online datafiles in a tablespace with offline datafile(s) cannot be backed up during online backups even if the offline datafiles are.
The offline datafiles can be backed up by using the include_dbfile specifier. This strategy would use system resources more intensively, but provide greater protection against downtime. <-- There's no subset clause anymore! This is not the default, but can be enabled in the EBU command script with the archdelete specifier. 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. 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. Online backups allow users to use the database while the backup is being performed. You can overwirte this by explicitly specifying another pfile to mount the database using the startup_pfile specifier. If you want to use online backups, you must operate your database in ARCHIVELOG mode so that online redo logs are archived. 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. 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. 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. A sample template for the UNIX operating system is provided for reference purposes when creating backup offline database shell scripts. 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. A backup script is a wrapper for the backup command script to take care of pre- and post-backup activities. 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. An offline backup is one taken after the database is cleanly shut down. 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.
You must back up the archived log files from every instance in an Oracle Parallel Server cluster. During the backup, the database is not available for normal operations.
When a tablespace is placed offline, all datafiles are offline so they are not backed up by default during online or offline backups. To set up a lights-out backup, use the third-party media management vendor software to define a lights-out backup schedule.
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. Lights-out backups can also be scheduled as cron jobs.
You may, however, use the include_dbfile specifier to include any offline files in a backup script. In a subset backup, each of the tablespaces or other file types must be specified within the subset clause. Then provide the pathname of a backup shell script to the media management software so the script can be invoked at the scheduled time. EBU will detect files with corrupted block headers and abort the backup job. On restore, the utility restores the control file, then creates mirrored copies according to the locations specified in the target database data dictionary. You should back up the control file immediately any time you make a structural change to a database. See "Backing Up and Restoring the EBU Catalog" for information on catalog 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.
This release of the Enterprise Backup Utility relies on the third-party media management software to schedule and initiate lights-out backups. Even when the control file is mirrored, the Enterprise Backup Utility backs up only one copy of the control file. EBU backs up archived redo logs by default for both online and offline backups. PARAM CLAUSE?
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. 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, "