This chapter describes the basic concepts for the Oracle Recovery Manager (RMAN) utility, and includes the following topics:
Overview of Recovery Manager
When you start RMAN, the following events occur:
When you use RMAN to connect to the target database, RMAN allocates server sessions to perform the backup and recovery operations through a PL/SQL interface. RMAN physically stores its backups and copies on disk or, if you use media management software, on tape.
RMAN stores metadata about its backup and recovery operations in the recovery catalog, which is a centralized repository of information, or exclusively in the control file. Typically, the recovery catalog is stored in a separate database. If you do not use a recovery catalog, RMAN uses the control file as its repository of metadata.
Recovery Manager (RMAN) is an Oracle tool that allows you to back up, copy, restore, and recover datafiles, control files, and archived redo logs. It is included with the Oracle server and does not require separate installation. You can invoke RMAN as a command line utility from the operating system (O/S) prompt or use the GUI-based Enterprise Manager Backup Manager.
RMAN users server sessions to automate many of the backup and recovery tasks that were formerly performed manually. For example, instead of requiring you to locate appropriate backups for each datafile, copy them to the correct place using operating system commands, and choose which archived logs to apply, RMAN manages these tasks automatically.
RMAN automates important backup and recovery operations. For example, Recovery Manager is able to:
Setting Up Recovery Manager
Typically, you need to use a password file when connecting to the target database over a non-secure Net8 connection, especially when you:
Note: Recovery Manager does not back up initialization or password files. When developing your backup and recovery strategy, plan how you will protect these files from media failure |
Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG environment variables. These variables determine the format used for the time parameters in RMAN commands such as restore, recover, and report.
The following example shows typical language and date format settings:
NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
When specifying dates in RMAN commands, the date string can be either:
Following are examples of typical date settings in RMAN commands:
backup archivelog from time 'SYSDATE-31' until time 'SYSDATE-14';
restore database until time "TO_DATE('12/20/98','MM/DD/YY')";
If you are going to use RMAN to connect to a non-mounted database and then mount the database later while RMAN is still connected, set the NLS_LANG variable so that it also specifies the character set used by the database.
A database that is not mounted assumes the default character set, which is US7ASCII. If your character set is different from the default, then RMAN returns errors after the database is mounted. To avoid this problem, set the NLS_LANG to specify the target database's character set. For example, if the character set is WE8DEC, you can set the NLS_LANG parameter as follows:
NLS_LANG=american_america.we8dec.
To use a recovery catalog, you need to set up the schema. Oracle suggests you put the recovery catalog schema in its own tablespace; however, you can put it in the SYSTEM tablespace if necessary. Note that SYS cannot be the owner of the recovery catalog.
Install the recovery catalog schema in a different database from the target database you will be backing up. If you do not, the benefits of using a recovery catalog are lost if you lose the database and need to restore.
|
WARNING: Ensure that the recovery catalog and target databases do not reside on the same disks; if they do and you lose one database, you will probably lose the other. |
Assume the following for the examples below:
catalog.sql and catproc.sql have successfully run.
SQL> CONNECT sys/change_on_install@rcat
SQL> SPOOL create_rman.log
SQL> CREATE USER rman IDENTIFIED BY rman 2> TEMPORARY TABLESPACE temp 3> DEFAULT TABLESPACE cattbs 4> QUOTA UNLIMITED ON cattbs;
SQL> GRANT recovery_catalog_owner TO rman;
SQL> GRANT connect, resource TO rman;
create_rman.log file for any errors before continuing. For example, a UNIX user can issue: SQL> host % vi create_rman.log
% rman catalog rman/rman@rcat
You can also connect from the RMAN prompt:
% rman RMAN> connect catalog rman/rman@rcat
RMAN> create catalog tablespace cattbs;
Note that the creation of the catalog can take several minutes.
create_rman.log file for any errors before continuing. For example, a UNIX user can issue: RMAN> host; % vi create_rman.log
SQL> SELECT table_name FROM user_tables;
For RMAN to function effectively, the RMAN executable and recovery catalog versions must be compatible. Compatibility between RMAN and the recovery catalog is determined by two factors:
The compatible parameter specifies the minimum acceptable release of the RMAN executable that can function with the catalog. For example, if the recovery catalog compatibility is set to 8.1.4, then only an RMAN executable of release 8.1.4 or later can connect to the catalog.
You cannot set the compatible parameter to a version that is not supported by the currently-installed DBMS_RCVMAN or DBMS_RCVCAT packages. If you try to set compatibility to a version that is not supported by one of the packages, then you receive an error message that indicates the lowest and highest value you can set, as in the following example:
RMAN> configure compatible = 8.0.1; RMAN-03022: compiling command: configure RMAN-03026: error recovery releasing channel resources RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure during compilation of command RMAN-03013: command type: configure RMAN-06455: illegal compatible value 8.0.1: must be between 08.00.04 and 08.01.06
Start a SQL*Plus session and connect to the recovery catalog database as the recovery catalog owner. For example, enter:
SQL> connect rman/rman@rcat
Issue the following query:
SQL> SELECT value FROM config WHERE name='compatible'; VALUE --------------------------------------------------------------------------------- 080106
To use RMAN, you must first connect to it. This connection is necessary to:
Whenever you start RMAN, you must connect to a target database. Note that RMAN connects you to the target database with the SYSDBA privilege: if you do not have this privilege, the connection fails.
You have several options for how you connect. For example, you can start RMAN:
In these examples, assume that you maintain a recovery catalog and:
|
sys |
User with SYSDBA privileges |
|
rman |
Owner of the recovery catalog having RECOVERY_CATALOG_OWNER privilege |
|
target_pwd |
The password for connecting as SYSDBA specified in the target database's |
|
target_str |
The net service name for the target database |
|
cat_pwd |
The password for user RMAN specified in the recovery catalog's |
|
cat_str |
The net service name for the recovery catalog database |
If the target database does not have a password file, then the user must be validated using operating system authentication. You can use operating system authentication only if you connect locally, that is, RMAN and the target database reside on the same machine. You cannot connect to the target database using operating system authentication in conjunction with a net service name.
ORACLE_SID to the target database. For example, at the UNIX prompt type: % ORACLE_SID=PROD1; export ORACLE_SID
% rman catalog rman/cat_pwd@cat_str
RMAN> connect target
If the target and recovery catalog databases use password files, then you can connect using a password. Use a password file for either local or remote access. You must use a password file if you are connecting remotely through a net service name.
To connect to RMAN from the operating system command line, enter the following:
% rman target sys/target_pwd@target_str catalog rman/cat_pwd@cat_str
Alternatively, you can start RMAN and connect to the target database from the RMAN prompt:
% rman RMAN> connect target sys/target_pwd@target_str RMAN> connect catalog rman/cat_pwd@cat_str
If you want to connect to RMAN from the operating system command line and hide authentication information, you can write a connect script and then create execute-only privileges on the file.
For example, if you are running RMAN in an UNIX environment, you can place the following connection information in a text file called connect_rman.sh:
rman target sys/target_pwd@target_str catalog rman/cat_pwd@cat_str
Then, change the permissions on the connect script so that everyone can execute the script but only the desired users have read access:
% chmod 711 connect_rman.sh
To connect to RMAN, users can execute the script from the operating system command line:
% connect_rman.sh
To disconnect from RMAN, type exit at the RMAN prompt:
RMAN> exit
The RMAN executable uses PL/SQL procedures to interpret commands. The PL/SQL packages perform two main functions:
The DBMS_RCVCAT and DBMS_RCVMAN packages are created by the create catalog command. RMAN uses DBMS_RCVCAT to maintain information in the recovery catalog and DBMS_RCVMAN to query the recovery catalog or control file.
The DBMS_BACKUP_RESTORE package is created by the dbmsbkrs.sql and prvtbkrs.plb scripts. This package is automatically installed in every Oracle database when the catproc.sql script is run. This package interfaces with the Oracle server and the operating system to provide the I/O services for backup and restore operations as directed by Recovery Manager.
A stored script is a set of RMAN commands that is enclosed in braces and stored in the recovery catalog. Maintaining a stored script allows you to plan, develop, and test a set of commands for backing up, restoring, or recovering the database. Stored scripts also minimize the potential for operator errors. Each stored script relates to only one database
RMAN allows you to:
% rman catalog rman/rman@rcat
create script b_whole{
allocate channel ch1 type disk;
allocate channel ch2 type disk;
backup database;
sql 'ALTER SYSTEM ARCHIVE LOG ALL';
backup archivelog all;
}
RMAN-08085, then the script was successfully created and stored in the recovery catalog: RMAN-03022: compiling command: create script RMAN-03023: executing command: create script RMAN-08085: created script b_whole
% rman target / catalog rman/rman@rcat
run { execute script b_whole; }
% rman target / catalog rman/rman@rcat
b_whole with the following: replace script b_whole {
allocate channel ch1 type 'sbt_tape';
backup database;
}
% rman catalog rman/rman@rcat
delete script 'b_whole';
rman_log: % rman target / catalog rman/rman@rcat log rman_log
print script b_whole;
RMAN> host; % vi rman_log
% sqlplus rman/rman@rcat
SQL> SELECT script_name FROM rc_stored_script; SCRIPT_NAME --------------------------------------------------------------------------------- backupdb binc binc1 3 rows selected.
The RMAN repository is the collection of metadata about your target databases that RMAN uses to conduct its backup, recovery, and maintenance operations. You can either create a recovery catalog in which to store this information, or let RMAN store it exclusively in the target database control file. Although RMAN can conduct all major backup and recovery operations using just the control file, some RMAN commands function only when you use a recovery catalog.
The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database's control file.
The recovery catalog is an optional repository of information about your target databases that RMAN uses and maintains. Conveniently, you do not need an additional database for storing the recovery catalog because you can put the recovery catalog in an existing database. RMAN uses the information in the recovery catalog, which is obtained from the control file, to determine how to execute requested backup and recovery operations.
The recovery catalog contains information about:
The recovery catalog obtains crucial RMAN metadata from the target database control file. Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current.
Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed data, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments (only if the database is open), and online redo logs. In a full resynchronization, RMAN updates all changed records, including schema records.
When you issue certain commands in RMAN, the program automatically detects when it needs to perform a full or partial resynchronization and executes the operation as needed. You can also force a full resynchronization by issuing a resync catalog command.
It is a good idea to run RMAN once a day or so and issue the resync catalog command to ensure that the catalog stays current. Because the control file employs a circular reuse system, backup and copy records eventually get overwritten. Resynchronizing the catalog ensures that these records are stored in the catalog and so are not lost.
RMAN generates a snapshot control file, which is a temporary backup control file, each time it resynchronizes. This snapshot control file ensures that RMAN has a consistent view of the control file either when refreshing the recovery catalog or when querying the control file. Because the snapshot control file is intended for RMAN's short-term use, it is not registered in the recovery catalog. RMAN records the snapshot control file checkpoint in the recovery catalog to indicate how current the recovery catalog is.
Because most information in the recovery catalog is also available in the target database's control file, RMAN supports an operational mode in which it uses the target database control file instead of a recovery catalog. This mode is especially appropriate for small databases where installation and administration of another database for the sole purpose of maintaining the recovery catalog is burdensome.
Oracle does not support the following features in this operational mode:
Use RMAN's report and list commands to gain information about backups and image copies. RMAN obtains the information from the RMAN repository: either the control file or the recovery catalog.
The list command lists the contents of the RMAN repository, whereas the report command performs a more detailed analysis. RMAN writes the output from these commands to the screen or to a log file.
The list command queries the recovery catalog or control file and produces a record of its contents. Use it to list:
RMAN reports are intended to provide analysis of your backup and recovery situation. An RMAN report can answer questions such as:
Issue the report need backup and report unrecoverable commands regularly to ensure that the necessary backups are available to perform media recovery, as well as to ensure that you can perform media recovery within a reasonable amount of time.
You must allocate a channel before you execute backup and recovery commands. Each allocated channel establishes a connection from RMAN to a target or auxiliary database (either a database created with the duplicate command or a temporary database used in TSPITR) instance by starting a server session on the instance. This server session performs the backup and recovery operations. Only one RMAN session communicates with the allocated server sessions.
Use channel control commands to:
You can allocate multiple channels, thus allowing a single RMAN command to read or write multiple backups or image copies in parallel. Thus, the number of channels that you allocate affects the degree of parallelism within a command. When backing up to tape you should allocate one channel for each physical device, but when backing up to disk you can allocate as many channels as necessary for maximum throughput.
RMAN internally handles parallelization of backup, copy, and restore commands. You only need to specify:
When you execute the backup command, you create one or more backup sets. A backup set, which is a logical construction, contains one or more physical backup pieces. Backup pieces are operating system files that contain the backed up datafiles, control files, or archived redo logs. You cannot split a file across different backup sets or mix archived redo logs and datafiles into a single backup set.
A backup set is a complete set of backup pieces that constitute a full or incremental backup of the objects specified in the backup command. Backup sets are in an RMAN-specific format; image copies, in contrast, are available for use without additional processing.
When backing up files, the target database must be mounted or open. If the database is mounted and was not shut down abnormally prior to mounting, then RMAN produces a consistent backup. The control file must be current.
If the database is in ARCHIVELOG mode, then the target database can be open or closed; you do not need to close the database cleanly (although Oracle recommends you do so that the backup is consistent). If the database is in NOARCHIVELOG mode, then you must close it cleanly prior to taking a backup.
RMAN is equipped to handle the two primary types of backup errors: I/O errors and corrupt blocks. Any I/O errors that RMAN encounters when reading files or writing to the backup pieces cause the system to abort the jobs. RMAN needs to rewrite the backup sets that it was writing at the time of the error, but it retains any backup sets that it successfully wrote prior to the abort.
RMAN copies datafile blocks that are already identified as corrupt into the backup. If RMAN encounters datafile blocks that have not already been identified as corrupt, it writes them to the backup with a reformatted header indicating that the block has media corruption (assuming that set maxcorrupt is not equal to 0 for this datafile and the number of corruptions does not exceed the limit). In either case, Oracle records the address of the corrupt block and the type of corruption in the control file. Access these control file records through the V$BACKUP_CORRUPTION view.
Use the set maxcorrupt command to limit the number of previously undetected block corruptions that Oracle allows in a specified datafile or list of datafiles. If a backup or copy command detects more than this number of corruptions, then the command aborts. The default limit is zero, meaning that RMAN does not tolerate corrupt blocks.
A full backup reads the entire file and copies all blocks into the backup set, skipping only datafile blocks that have never been used. The server session does not skip blocks when backing up archived redo logs or control files.
|
Note: A full backup is not the same as a whole database backup; full is an indicator that the backup is not incremental. |
An incremental backup reads the entire file and then backs up only those data blocks that have changed since a previous backup. Oracle allows you to create and restore incremental backups of datafiles, tablespaces, or the whole database. Note that RMAN can include a control file in an incremental backup set, but the control file is always included in its entirety--no blocks are skipped.
The primary reasons for making an incremental backup are:
RMAN allows you to create multi-level incremental backups. Each incremental level is denoted by an integer, for example, 0, 1, 2, etc. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. When you generate a level n incremental backup in which n is greater than 0, you back up:
The benefit of performing multi-level incremental backups is that you do not back up all of the blocks all of the time. Since RMAN needs to read all of the blocks of the datafile, full backups and incremental backups taking approximately the same amount of time (assuming that the output of the backup is not a bottleneck).
Incremental backups at levels greater than 0 only copy blocks that were modified. The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.
An image copy contains a single datafile, archived redo log file, or control file that you can use as-is to perform recovery. Use the RMAN copy command or an operating system command such as the UNIX cp command to create image copies.
An image copy produced with the RMAN copy command is similar to an operating system copy of a single file, except that an Oracle server session produces it. The server session performs additional actions like validating the blocks in the file and registering the copy in the control file. An image copy differs from a backup set because it is not multiplexed, nor is there any additional header or footer control information stored in the copy. RMAN only writes image copies to disk.
Use the RMAN copy command to create an image copy. If the original file needs to be replaced, and if the image copy is of a datafile, then you do not need to restore the copy. Instead, Oracle provides a switch command to point the control file at the copy and update the recovery catalog to indicate that the copy has been switched. Issuing the switch command in this case is equivalent to issuing the SQL statement ALTER DATABASE RENAME DATAFILE. You can then perform media recovery to make the copy current.
RMAN can catalog an image copy and read the metadata. This operation is important when the recovery catalog is lost and you must perform disaster recovery. Only image copies and archived logs can be cataloged.
You can assign a user-specified character string called a tag to backup sets and image copies (either RMAN-created copies or O/S-created copies). A tag is a symbolic name for a backup set or file copy such as weekly_backup; you can specify the tag rather than the filename when executing the restore or change command. The maximum length of a tag is 30 characters.
For example, if datafile copies are created each Monday evening and are always tagged mondayPMcopy, then the tag refers to the most recent copy. Thus, this command switches
datafile 3 to the most recent Monday evening copy:
switch datafile 3 to datafilecopy tag mondayPMcopy;
Use the RMAN restore command to restore datafiles, control files, and archived redo logs from backup sets or image copies on disk. Because a backup set is in an Oracle proprietary format, you cannot simply import it; you must use the RMAN restore command to extract it. In contrast, Oracle can use image copies created using RMAN without additional processing.
You can restore:
RMAN automates the procedure for restoring files. You do not need to go into the operating system, locate the backup or copy that you want to use, and manually copy files into the appropriate directories. When you issue a restore command, RMAN directs a server session to restore the correct backups and copies to either:
RMAN uses the recovery catalog--or target database control file if no recovery catalog is available--to select the best available backup sets or image copies for use in the restore operation. It gives preference to image copies rather than backup sets. When multiple choices are available, RMAN uses the most current backup sets or copies, taking into account whether you specified the untilClause.
Note the following constraints on the restore command:
Media recovery is the application of online or archived redo logs or incremental backups to a restored datafile in order to update it to the current time or some other specified time. Use the RMAN recover command to perform media recovery and apply incremental backups automatically. You can only recover current datafiles.
The generic steps for media recovery using RMAN are:
If RMAN has a choice between applying an incremental backup or applying redo to the restored datafiles, then it always chooses to use the incremental backup. If over-lapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time.
If RMAN cannot find an incremental backup, it looks for an archived redo log. Whenever ARCn archives a redo log, Oracle immediately records it in the control file. Recovery Manager propagates this information into the recovery catalog during resynchronization, classifying archived redo logs as image copies. Use the list command to display them.
During recovery, RMAN looks for the appropriate archived redo logs in the default locations specified in the parameter file. If it cannot find them anywhere on disk, it looks in backup sets and restores archived redo logs as needed to perform the media recovery.
By default, RMAN restores the archived redo logs to the current log archive destination specified in the initialization parameter file. Use the set archivelog destination command to specify a different restore location.
RMAN can perform either complete or incomplete recovery. Using the set until command, you can specify a time, SCN, or log sequence number as a limit for incomplete recovery. Typically, you use this command before issuing the restore and recover commands. After performing incomplete recovery, always open the database with the RESETLOGS option and then immediately back up the database.
Use the RMAN duplicate command to create a test database on which to practice your backup and recovery procedures. The command takes disk backups of your primary database's files and uses them to create a new database. A test database is especially useful if your production database must be up and running 24 hours per day, 7 days a week.
As part of the duplicating operation, RMAN manages the following:
Note also the following features of RMAN duplication. You can:
Oracle prohibits any attempts to perform operations that result in unusable backup files or corrupt restored datafiles. Oracle performs integrity checks to:
Because an Oracle server session is performing backup and copy operations, the server session is able to detect many types of corrupt blocks. Each new corrupt block not previously encountered in a backup or copy operation is recorded in the control file and in the
alert.log.
RMAN queries corruption information at the completion of a backup and stores it in the recovery catalog and control file. Access this data using the views V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.
If RMAN encounters a datafile block during a backup that has already been identified as corrupt by the database, then the server session copies the corrupt block into the backup and Oracle logs the corruption in the control file as either a logical or media corruption.
If RMAN encounters a datafile block with a corrupt header that has not already been identified as corrupt by the database, then it writes the block to the backup with a reformatted header indicating that the block has media corruption.
RMAN can test data and index blocks that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, it logs the block in the
alert.log and server session trace file.
Provided the sum of physical and logical corruptions detected for a file remain below its maxcorrupt setting, the RMAN command completes and Oracle populates V$BACKUP_CORRUPTION and V$COPY_CORRUPTION with corrupt block ranges. If maxcorrupt is exceeded, then the command terminates without populating the views.
Because backups and copies can disappear from disk or tape or become corrupted, the RMAN metadata repository can contain outdated information. To ensure that data about backup sets and image copies in the recovery catalog or control file is synchronized with corresponding data on disk or in the media management catalog, perform a crosscheck.
Use either the change ... crosscheck or crosscheck backup command to check the specified files. Note that these commands do not delete operating system files or remove repository records; you must use separate commands for those operations.
The following table explains the difference between the crosscheck commands:
|
Command |
Catalog Needed? |
Purpose |
|
change ... crosscheck |
Only for backupset and backuppiece options |
To determine whether the backups or copies exist. If RMAN cannot find backup pieces, it marks them as EXPIRED. It marks all other types of absent files--image copies and archived redo logs--as DELETED. If the files are on disk, RMAN queries the file headers. For other device types, RMAN queries the media manager to see if the file exists in the media catalog. |
|
crosscheck backup |
No |
To determine whether backups stored on disk or tape exist. Backups are either backup sets or media-managed proxy copies. This command checks only backup sets marked AVAILABLE or EXPIRED, either by examining the backup pieces for type disk or by querying the media manager for type 'sbt_tape'. It only processes backups created on the specified channel. RMAN does not delete backup pieces that it cannot find, but marks them as EXPIRED. |
Use the crosscheck feature to check the status of a backup on disk or tape. If the backup is on disk, the change backupset ... crosscheck and crosscheck backup commands determine whether the header of the backup piece is valid; if on tape, the commands simply check that the backups exist.
If a backup piece is unreadable or absent, then RMAN marks the backup piece EXPIRED in the output of the list command and the recovery catalog views. If it was marked EXPIRED but is now available, RMAN marks the backup piece as AVAILABLE in the output of the list command and the recovery catalog views.
allocate channel for maintenance type 'sbt_tape';
list backup;
RMAN> change backupset 1338, 1339, 1340 crosscheck; RMAN-03022: compiling command: change RMAN-08074: crosschecked backup piece: found to be 'EXPIRED' RMAN-08517: backup piece handle=/oracle/dbs/2eafnuj3_1_1 recid=77 stamp=352057957 RMAN-08074: crosschecked backup piece: found to be 'AVAILABLE' RMAN-08517: backup piece handle=/oracle/dbs/2dafnuj2_1_1 recid=78 stamp=352057957 RMAN-08074: crosschecked backup piece: found to be 'AVAILABLE' RMAN-08517: backup piece handle=/oracle/dbs/2fafnuj3_1_1 recid=79 stamp=352057960
If a backup set is no longer available, RMAN marks it as EXPIRED. If it was marked EXPIRED and is now available, RMAN marks it AVAILABLE.
release channel;
allocate channel for maintenance type 'sbt_tape';
For example, check all backups of datafile tbs_8.f over the last six months:
crosscheck backup of datafile "/oracle/dbs/tbs_8.f" completed after 'SYSDATE-180';
If a backup set is no longer available, RMAN marks it as EXPIRED. If it was marked EXPIRED and is now available, RMAN marks it AVAILABLE.
release channel;
You can use RMAN to delete backups, copies, and archived logs and update their status in the repository to DELETED status or remove the records entirely.
Allocate a channel of type maintenance:
allocate channel for maintenance type disk;
Issue a change ... uncatalog command for the backups or copies that you deleted from the operating system using operating system commands. This example removes references to copies of the control file and datafile 1 from the repository:
change controlfilecopy '/oracle/backup/cf_c.f' uncatalog; change datafilecopy '/oracle/backup/df_1_c.f' uncatalog;
Release the allocated channel:
release channel;
This procedure does not require the use of a recovery catalog.
Check for the expired backup sets and copies. Use the list output to obtain their primary keys.
list backup of database archivelog all; # lists backups of database files and logs list copy;
Allocate a channel of type delete:
allocate channel for delete type disk;
Issue a change ... delete command to eliminate the specified physical files and the repository records. If you are deleting archived logs, then depending on the compatibility setting of the recovery catalog, this command either changes the recovery catalog record to status DELETED or removes the record altogether.
This example deletes the backup piece with key 101, the control file copy with key 63, and all archived logs through log sequence 300 from disk:
change backuppiece 101 delete;
change controlfilecopy 63 delete;
change archivelog until logseq = 300 delete; # effect on catalog records for these
# logs depends on compatibility settingRelease the allocated maintenance channel:
release channel;
This procedure does not require the use of a recovery catalog. The script below works only on UNIX systems.
Change into the $ORACLE_HOME/rdbms/demo directory and edit the following shell script as needed:
% vi rman1.sh
Execute the script:
% rman1.sh
If desired, check deleted.log to see the command output.
This procedure requires the use of a recovery catalog.
allocate channel for delete type disk;
delete expired backup;
If the expired pieces exist, RMAN removes them from the operating system.
release channel;
This procedure requires the use of a recovery catalog.
list copy;
This example removes records of copies of the control file and of the datafile copy with the primary key 4833:
change controlfilecopy '/oracle/backup/cf_c.f' uncatalog; change datafilecopy 4833 uncatalog;
Note that change ... uncatalog does not remove files from the operating system; it only removes recovery catalog records.
SQL> SELECT cdf_key, status FROM rc_datafile_copy WHERE cdf_key = 4833; CDF_KEY S ---------- - 0 rows selected.
To remove all copy and backup records from the recovery catalog:
You can remove all recovery catalog records of deleted backups and copies at once using the $ORACLE_HOME/rdbms/prgrmanc.sql script. Only perform this operation if you do not want a historical record of what you have backed up.
allocate channel for maintenance type 'sbt_tape';
change backupset 100, 101, 102, 103 delete;
release channel;
% sqlplus rman/rman@rcat
prgrmanc.sql script, which is stored in the $ORACLE_HOME/rdbms/admin directory: SQL> @prgrmanc.sql
RMAN removes all records with status DELETED from the recovery catalog.
allocate channel for maintenance type 'sbt_tape';
change backupset 100, 101, 102, 103 delete;
release channel;
% sqlplus rman/rman@rcat
SQL> SELECT * FROM rc_database_incarnation;
key_value is the value of DBINC_KEY: SQL> DELETE FROM dbinc WHERE dbinc_key=key_value;
RMAN will remove the specified incarnation records from the recovery catalog.