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