CHAPTER 13 • ORACLE8i RECOVERY MANAGER 596 STARTUP MOUNT; SET UNTIL LOGSEQ 6 THREAD 1; ALLOCATE CHANNEL d1 TYPE DISK; RESTORE DATABASE; RECOVER DATABASE; RELEASE CHANNEL d1; SQL “ALTER DATABASE OPEN RESETLOGS”; } RESET DATABASE; EXIT; The RESET DATABASE command can also be used to reset the incarnation of a database, so that a previous incarnation’s backup can be recovered. Again, this is only possible if you are using a recovery catalog. An example is shown in Listing 13.28. Listing 13.28: RMAN Database Incarnation Reset SHUTDOWN IMMEDIATE RESET DATABASE TO INCARNATION 1; RUN { ALLOCATE CHANNEL d1 TYPE DISK; RESTORE CONTROLFILE; STARTUP MOUNT; RESTORE DATABASE; RECOVER DATABASE; RELEASE CHANNEL d1; SQL “ALTER DATABASE OPEN RESETLOGS”; } RESET DATABASE; EXIT; In this example, all of the available archived redo logs assigned to incarnation 1 will be recovered, and the database will be opened to the point at which incarnation 1 ceased to exist. By issuing the RESETLOGS command, you create a new incarnation. Storing RMAN Scripts Another feature of the recovery catalog is its ability to store RMAN scripts that can be called from RMAN. To store scripts in the recovery catalog, you use the CREATE SCRIPT command, assigning each script a unique name that identifies it. Typically, C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 597 you will assign the script a name that identifies its purpose, such as backup_prod_db. Here is an example: CREATE SCRIPT backup_prod_db { ALLOCATE CHANNEL d1 TYPE DISK; BACKUP FULL (DATABASE FORMAT “d:\oracle\admin\ora817\backup\ora817.full.%u”); SQL “ALTER SYSTEM ARCHIVE LOG CURRENT”; BACKUP CURRENT CONTROLFILE FORMAT “d:\oracle\admin\ora817\backup\ora817.crtl.%u”; BACKUP ARCHIVELOG ALL DELETE INPUT FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”; RELEASE CHANNEL d1; } NOTE When you use a script, you do not need to include a RUN command in it. This is because when you EXECUTE a script, it is executed within the confines of a RUN command. The EXECUTE SCRIPT command, which is a job command, allows you to execute the script. Here is an example: RUN {EXECUTE SCRIPT backup_prod_db;} EXIT; The REPLACE SCRIPT command replaces existing RMAN scripts with new scripts, as shown here: REPLACE SCRIPT BACKUP_PROD_DB { ALLOCATE CHANNEL disk1 TYPE DISK; BACKUP FULL (DATABASE FORMAT “d:\oracle\admin\ora817\backup\ora817.full.%u”); SQL “ALTER SYSTEM ARCHIVE LOG CURRENT”; BACKUP CURRENT CONTROLFILE FORMAT “d:\oracle\admin\ora817\backup\ora817.crtl.%u”; BACKUP ARCHIVELOG ALL DELETE INPUT USING THE RECOVERY CATALOG Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 598 FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”; RELEASE CHANNEL disk1; } The PRINT SCRIPT command will cause the contents of the script to be printed to the screen: PRINT SCRIPT backup_prod_db; The DELETE SCRIPT command removes the script: DELETE SCRIPT backup_prod_db; Maintaining the Recovery Catalog Now that you have created the recovery catalog, you need to maintain the records in it. In this section, we will first discuss the recovery catalog views that you can use to check the records of the recovery catalog. Next, we explain how to perform cross- checking to make sure that physical datafile statuses are properly recorded in the recovery catalog. Finally, we will cover how to purge old recovery catalog records. Recovery Catalog Data Dictionary Views There are a number of views created when the recovery catalog is created that you can use to write reporting scripts and the like (though Oracle provides its own reporting through the LIST and REPORT commands). Most of these views derive their informa- tion from the recovery catalog. Many of them have corollary views that derive the same information from the database control file. These views have the same name except for their prefixes: RC_ for the recovery catalog views and V$ for the control file views. For example, if you want to find the view in the recovery catalog that is like V$ARCHIVED_LOG, you would look for RC_ARCHIVED_LOG. Table 13.12 lists the recovery catalog views, a brief description, and the corollary control file view (if one exists). TABLE 13.12: RMAN RECOVERY CATALOG VIEWS View Description Corollary Control File View RC_ARCHIVED_LOG V$ARCHIVED_LOG RC_BACKUP_CONTROLFILE Provides information on control files that are contained in backup sets Provides historical information on archived redo logs C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 599 TABLE 13.12: RMAN RECOVERY CATALOG VIEWS (CONTINUED) View Description Corollary Control File View RC_BACKUP_CORRUPTION Provides block corruption information V$BACKUP_CORRUPTION RC_BACKUP_DATAFILE V$BACKUP_DATAFILE RC_BACKUP_PIECE V$BACKUP_PIECE RC_BACKUP_REDOLOG V$BACKUP_REDOLOG RC_BACKUP_SET V$BACKUP_SET RC_CHECKPOINT RC_CONTROLFILE_COPY Provides information on control file copies on disk RC_COPY_CORRUPTION V$COPY_CORRUPTION RC_DATABASE V$DATABASE RC_DATABASE_INCARNATION Provides information on all database incarnations registered in the recovery catalog RC_DATAFILE V$DATAFILE RC_DATAFILE_COPY V$DATAFILE_COPY RC_LOG_HISTORY V$LOG_HISTORY RC_OFFLINE_RANGE V$OFFLINE_RANGE Lists recovery catalog information on the offline ranges for datafiles Lists recovery catalog information on online redo log history Lists recovery catalog information on datafile copies on disk Lists recovery catalog information on all datafiles registered in the recovery catalog Lists recovery catalog information on databases registered with the recovery catalog Lists recovery catalog information on corrupt blocks in datafile copies Provides recovery catalog resynch information, but Oracle recommends that you use the RC_RESYNC view instead Lists recovery catalog information on backup sets for all incarnations of the database Lists recovery catalog information on archived redo logs Lists recovery catalog information on backup set pieces Lists recovery catalog information on backup sets USING THE RECOVERY CATALOG Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 600 TABLE 13.12: RMAN RECOVERY CATALOG VIEWS (CONTINUED) View Description Corollary Control File View RC_PROXY_CONTROLFILE V$PROXY_CONTROLFILE RC_PROXY_DATAFILE V$PROXY_ DATAFILE RC_REDO_LOG Provides information about online redo logs for all incarnations of the database stored in the recovery catalog RC_REDO_THREAD Provides information about online redo log threads for all incarnations of the database stored in the recovery catalog RC_RESYNC Provides information on resynch operations between a target database and the recovery catalog RC_STORED_SCRIPT Provides information on scripts stored in the recovery catalog RC_STORED_SCRIPT_LINE Provides detail on each line of each script stored in the recovery catalog RC_TABLESPACE V$TABLESPACE Cross-Checking Backup Sets You might wonder what happens if a tape becomes unavailable or is overwritten for some reason. The RMAN CROSSCHECK command can be used to check all backups currently on tape and compare (cross-check) them with the cataloged backups. The status of the backups will be marked accordingly. Any backup not found will be marked with an EXPIRED status, for later removal. If, on the other hand, the backup set has an EXPIRED status, but it actually exists on the backup media, its status will be set to AVAILABLE. Table 13.13 describes the parameters for the CROSSCHECK command. Lists recovery catalog information on all tablespaces, including dropped tablespaces and those from old incarnations Lists recovery catalog information on datafile backups made while using the proxy copy function Lists recovery catalog information on control file copies made using the proxy copy function C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 601 TABLE 13.13: CROSSCHECK COMMAND PARAMETERS Parameter description of listObjList Restricts the types of objects operated on by the command to those specified. (See Table 13.15 later in this chapter.) TAG <tag_name> Defines a tag for a backup set to be cross-checked. completedTimeSpec Defines a time range to run the CROSSCHECK command over. The options are AFTER = {date string} to define when the backup was completed, BETWEEN {date string} and {date string} to define a time range between backup completions, and BEFORE = {date string} to define a time range before the backup was complete. NOTE Prior to Oracle 8.1.7, the CROSSCHECK command required the recovery catalog. In 8.1.7, this is no longer the case. Listing 13.29 shows an example of using the CROSSCHECK command. Listing 13.29: RMAN Backup Set Cross-check E:\oracle\oradata>rman target sys/robert catalog repo_own/repo_own@rmandb Recovery Manager: Release 8.1.7.0.0 - Production RMAN-06005: connected to target database: ORA817 (DBID=1598904557) RMAN-06008: connected to recovery catalog database RMAN> ALLOCATE CHANNEL FOR MAINTENANCE TYPE DISK; RMAN-03022: compiling command: allocate RMAN-03023: executing command: allocate RMAN-08030: allocated channel: delete RMAN-08500: channel delete: sid=8 devtype=DISK RMAN> CROSSCHECK BACKUP; RMAN-03022: compiling command: XCHECK RMAN-03023: executing command: XCHECK RMAN-08074: crosschecked backup piece: found to be ‘EXPIRED’ USING THE RECOVERY CATALOG Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 602 RMAN-08517: backup piece handle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.ARCH.31CU1I QB recid=93 stamp=434162508 RMAN-08074: crosschecked backup piece: found to be ‘EXPIRED’ RMAN-08517: backup piece handle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.ARCH.32CU1I QJ recid=94 stamp=434162516 RMAN-08074: crosschecked backup piece: found to be ‘AVAILABLE’ RMAN-08517: backup piece handle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.FULL.33CU36 4C recid=95 stamp=434215057 RMAN-08074: crosschecked backup piece: found to be ‘AVAILABLE’ RMAN-08517: backup piece handle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.CRTL.34CU36 7P recid=96 stamp=434215164 RMAN-08074: crosschecked backup piece: found to be ‘AVAILABLE’ RMAN-08517: backup piece handle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.ARCH.35CU36 8A recid=97 stamp=434215180 RMAN-03023: executing command: partial resync RMAN-08003: starting partial resync of recovery catalog RMAN-08005: partial resync complete RMAN> RELEASE CHANNEL; RMAN-03022: compiling command: release RMAN-03023: executing command: release RMAN-08031: released channel: delete As an alternative, you can issue the CROSSCHECK command using a date range, as in this example: CROSSCHECK BACKUP COMPLETED AFTER ‘SYSDATE - 30’; Purging Old Recovery Catalog Records We all need to take out the trash from time to time, and this applies to maintaining the recovery catalog as well as your household. Without some reoccurring mainte- nance, the recovery catalog will grow and grow. The CROSSCHECK command marks backups that are no longer available with an EXPIRED status, but this command does not remove them from the recovery catalog. The DELETE EXPIRED BACKUP command C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 603 is the one that handles this chore. This command will remove all records in the recov- ery catalog associated with expired backups. NOTE Prior to Oracle 8.1.7, the DELETE EXPIRED command required the recovery cata- log. In 8.1.7, this is no longer the case. Listing 13.30 shows an example of using the DELETE EXPIRED command. Listing 13.30: RMAN Recovery Catalog Record Deletion RUN { ALLOCATE CHANNEL FOR DELETE disk1 TYPE DISK; CROSSCHECK BACKUP OF TABLESPACE user; DELETE EXPIRED BACKUP OF TABLESPACE user; RELEASE CHANNEL disk1; } In this example, we first allocate a channel, but this time we use the FOR DELETE syntax, which indicates to RMAN that we are likely going to be removing some physi- cal backup pieces. The CROSSCHECK command will mark as expired all tablespace backups of the USER tablespace that no longer have physical backup sets. The DELETE EXPIRED BACKUP command will then physically remove those backups from RMAN. Housecleaning at its best! Although the CHANGE command allows you to mark backup items with a DELETED status, currently, there is no RMAN command that allows you to remove these DELETED records from RMAN. Fortunately, Oracle has provided the prgrmanc.sql script, which will remove all records that have a DELETED status from the recovery catalog. This script can be found in the $ORACLE_HOME/rdbms/admin directory of your Oracle software installation. Generating Reports and Lists DBAs need information, and RMAN is poised to provide that information. RMAN facilitates reporting of backup sets, image copies, and many other facets of the backup and recovery landscape through the use of the REPORT and LIST commands. In this section, we will look at each of these types of RMAN information output. GENERATING REPORTS AND LISTS Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 604 Producing Backup Reports The REPORT command provides information on the state of the database with regard to backups. With the REPORT command, for example, you can determine which datafiles have not been backed up in a certain number of days. You can also generate reports on database datafiles that need to be backed up because UNRECOVERABLE operations have been performed on them since the last backup. Most output from the REPORT command can be run without a recovery catalog, but there are few exceptions (use of the AT clause parameters, described shortly). The NEED BACKUP Option The NEED BACKUP {report criteria} parameter lists all datafiles of the target database that require a backup. (If a file has not been backed up, it will not appear on the report.) The following report criteria are valid: • INCREMENTAL {n} sets a maximum number of backups that should be required for full recovery. If this number is exceeded, a level 0 incremental backup is required. • DAYS {n} defines the maximum number of days of redo log file application that any datafile should require. Thus, if this were set to 5, any datafile that was backed up more than 5 days ago would appear on the report. • REDUNDANCY {n} defines a minimum number of backups or datafiles copies that must exist for a datafile. If this number of copies does not exist, the datafile will appear on the report. Let’s say that you want a list of all the datafiles in the database that have not been backed up in two days. Here is the REPORT command and the resulting output that shows the desired information: RMAN> REPORT NEED BACKUP DAYS 2; RMAN-03022: compiling command: report Report of files whose recovery needs more than 2 days of archived logs File Days Name 1 6 D:\ORACLE\ORADATA\ORA817\SYSTEM01.DBF 2 6 D:\ORACLE\ORADATA\ORA817\RBS01.DBF 3 6 D:\ORACLE\ORADATA\ORA817\USERS01.DBF 4 6 D:\ORACLE\ORADATA\ORA817\TEMP01.DBF 5 6 D:\ORACLE\ORADATA\ORA817\TOOLS01.DBF 6 6 D:\ORACLE\ORADATA\ORA817\INDX01.DBF C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 605 The report shows the datafiles that are in need of backup because it would take more than two days of archived redo logs to recover them. This report provides the file number, the actual number of days’ worth of archived redo logs that would be required to recover the datafile, and the names of the datafiles themselves. As another example, suppose that you have decided that you need a minimum of three backups of every database datafile to feel that you have a sufficiently redundant backup strategy. These backups don’t need to be at the same time—you just want three different backups (you can apply the archived redo logs, of course). So, you might produce this report: RMAN> REPORT NEED BACKUP REDUNDANCY 3; RMAN-03022: compiling command: report Report of files with less than 3 redundant backups File #bkps Name 1 1 D:\ORACLE\ORADATA\ORA817\SYSTEM01.DBF 3 2 D:\ORACLE\ORADATA\ORA817\USERS01.DBF 4 1 D:\ORACLE\ORADATA\ORA817\TEMP01.DBF 5 2 D:\ORACLE\ORADATA\ORA817\TOOLS01.DBF 6 1 D:\ORACLE\ORADATA\ORA817\INDX01.DBF This report indicates that you do have some datafiles that do not meet your mini- mum redundancy requirement. Some of them, like SYSTEM01.DBF, require another backup to meet the requirement; others, like TOOLS01.DBF, require two backups. Any datafiles that have a sufficient number of backups to meet the criteria do not appear on the report. The UNRECOVERABLE Option Perhaps you want to know if any UNRECOVERABLE actions have occurred that might necessitate a backup of a datafile. You can get this information with the REPORT UNRECOVERABLE parameter: RMAN> REPORT UNRECOVERABLE RMAN-03022: compiling command: report Report of files that need backup due to unrecoverable operations File Type of Backup Required Name 3 full or incremental D:\ORACLE\ORADATA\ORA817\USERS01.DBF From this report, you see that the USERS01.DBF datafile is in need of either a full or incremental backup. This is because you have performed some UNRECOVERABLE GENERATING REPORTS AND LISTS Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... logmnr.opt file, you define the PH column the table columns are assigned to For example, suppose that you have a table called APPOINTMENTS in the DOCTORS schema In that table, you have a column called LAST_NAME You set up a logmnr.opt file with the following entry: colmap = doctors appointments (1, last_name); Then, when you mine the redo logs, any changes to the LAST_NAME column will appear in the PH1 column