Release 8.1.5
A67773-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Backup and Recovery Guide Release 8.1.5 A67773-01 |
|
This chapter describes how to use Recovery Manager to manage backup and copy operations, and includes the following topics:
Perform backups of any of the following objects using the RMAN backup command:
RMAN backs up the files into one or more backup sets. You can set parameters for the backup command to specify the filenames for the backup pieces, the number of files to go in each set, and which channel should operate on each input file.
You can make RMAN backups when the database is open or closed. Closed backups can be consistent or inconsistent, depending on how the database was shut down; open backups are always inconsistent. Consistent backups can be restored without recovery. An inconsistent backup will require some media recovery when it is restored, but is otherwise just as valid as a consistent backup.
RMAN backup are further divided into full and incremental backups. Full backups are non-incremental, i.e., every used block is backed up.
This section contains the following procedures:
See Also: For an overview of RMAN backups, see "Backup Sets". For a complete description of backup command syntax, see "backup". For a discussion of the various RMAN backup types, see "Backup Types".
The procedures in this chapter allow you to make backups when the database is open or closed. Closed backups are either consistent or inconsistent; open backups are always inconsistent. Note that Oracle does not permit inconsistent backups in NOARCHIVELOG mode.
To make a consistent backup, the database:
If these conditions are not met, the backup will be inconsistent.
If you can afford to close your database, Oracle recommends taking closed, consistent backups of your whole database. If you cannot shut down your database, then your only option is to make an open backup.
% rman target / catalog rman/rman@rcat
To write the output to a log file, specify the file at startup. For example, enter:
% rman target / catalog rman/rman@rcat log /oracle/log/mlog.f
$ORACLE_HOME/dbs on UNIX):
run { allocate channel ch1 type disk; backup database; sql 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # archives current redo log sql 'ALTER SYSTEM ARCHIVE LOG ALL'; # archives all un-archived redo logs }
Optionally, use the format parameter to specify a filename for the backup piece. For example, enter:
run { allocate channel ch1 type 'sbt_tape'; backup database format '/oracle/backup/%U'; # %U generates a unique filename }
Optionally, use the tag parameter to specify a tag for the backup. For example, enter:
run { allocate channel ch1 type 'sbt_tape'; backup database tag = 'weekly_backup'; # gives the backup a tag identifier }
Back up tablespaces and datafiles when the database is either open or closed. Note that all open database backups are always inconsistent. Do not issue ALTER DATABASE BEGIN BACKUP before making an online tablespace backup.
% rman target / catalog rman/rman@rcat
If you want to write the output to a message log file, specify the file at startup. For example, enter:
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
run { allocate channel ch1 type disk; allocate channel ch2 type disk; allocate channel ch3 type disk; backup filesperset = 3 tablespace inventory, sales include current controlfile; }
% rman target / catalog rman/rman@rcat
If you want to write the output to a message log file, specify the file at startup. For example, enter:
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
run { allocate channel ch1 type disk; backup (datafile 1,2,3,4,5,6 filesperset 3) datafilecopy '/oracle/copy/tbs_1_c.f'; }
% rman target / catalog rman/rman@rcat
If you want to write the output to a message log file, specify the file at startup. For example, enter:
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
df1.copy to tape:
run { allocate channel ch1 type 'sbt_tape'; backup datafilecopy '/oracle/copy/df1.copy'; }
You can make backups of the control file when the database is open or closed. RMAN uses a snapshot control file to ensure a read-consistent version.
Whole database backups automatically include the current control file, but the current control file does not contain a record of the whole database backup. To obtain a control file backup with a record of the whole database backup, make a backup of the control file after executing the whole database backup.
Include a backup of the control file within any backup by specifying the include current controlfile option.
% rman target / catalog rman/rman@rcat
If you want to write the output to a log file, specify the file at startup. For example, enter:
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
run { allocate channel ch1 type 'sbt_tape'; backup current controlfile tag = mondayPMbackup; }
% rman target / catalog rman/rman@rcat
If you want to write the output to a log file, specify the file at startup. For example, enter:
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
'/oracle/copy/cf.f':
run { allocate channel ch1 type disk; backup controlfilecopy '/oracle/copy/cf.f'; }
Specify the include current controlfile option after specifying the backup object. For example, this command backs up tablespace FOO and includes the current control file in the backup:
run { allocate channel c1 type disk; backup tablespace foo include current controlfile; }
The archived redo logs are the key to successful recovery. Back them up regularly.
You can specify the delete input option in the backup command, which will delete the archived redo logs after you have backed them up. Thus, you can back up archived logs to tape and clear your disk space of the old logs in one step.
% rman target / catalog rman/rman@rcat
If you want to write the output to a log file, specify the file at startup. For example, enter:
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
run { allocate channel ch1 type 'sbt_tape'; backup archivelog all # Backs up all archived redo logs. delete input; # Optionally, delete the input logs }
You can also specify a range of archived redo logs by time, SCN, or log sequence number. This example backs up all archived logs created more than 7 and less than 30 days ago:
run { allocate channel ch1 type disk; backup archivelog from time 'SYSDATE-30' until time 'SYSDATE-7'; }
You can make consistent or inconsistent incremental backups of the database or individual tablespaces or datafiles. This procedure makes an incremental backup of a database that was shut down cleanly.
% rman target / catalog rman/rman@rcat
run { allocate channel ch1 type disk; backup incremental level = 0 database; }
This example makes a differential level 1 backup of the SYSTEM tablespace and datafile sales.f. It will only back up those data blocks changed since the most recent level 1 or level 0 backup:
run { allocate channel ch1 type disk; backup incremental level = 1 tablespace system datafile '/oracle/dbs/sales.f'; }
This example makes a cumulative level 2 backup of the tablespace TBS_2. It will only back up those data blocks changed since the most recent level 1 or level 0 backup:
run { allocate channel ch1 type disk; backup incremental level = 2 cumulative # specify cumulative option tablespace tbs_1; }
In many cases, making a copy is better than making a backup, because copies are not in an RMAN-specific format and hence are suitable for use without any additional processing. In contrast, you must process a backup set with a restore command before it is usable. So, you can perform media recovery on a datafile copy, but not directly on a backup set, even if it contains only one datafile and is composed of a single backup piece.
Use the copy command to create image copies. RMAN always writes the output file to disk. You can copy the following types of files:
% rman target / catalog rman/rman@rcat
RMAN> report schema; RMAN-03022: compiling command: report Report of database schema File K-bytes Tablespace RB segs Name ---- ---------- -------------------- ------- ------------------- 1 35840 SYSTEM YES /oracle/dbs/tbs_01.f 2 978 SYSTEM YES /oracle/dbs/tbs_02.f 3 978 TBS_1 NO /oracle/dbs/tbs_11.f 4 978 TBS_1 NO /oracle/dbs/tbs_12.f
run { allocate channel ch1 type disk; copy datafile 1 to '/oracle/copy/df_1.f', datafile 2 to '/oracle/copy/df_2.f', datafile 3 to '/oracle/copy/df_3.f', datafile 4 to '/oracle/copy/df_4.f', current controlfile to '/oracle/copy/cf.f'; }
% rman target / catalog rman/rman@rcat
run { allocate channel ch1 type disk; # allocate multiple channels for parallelization. For parallelization, issue one # copy command rather than multiple copy commands. allocate channel ch2 type disk; allocate channel ch3 type disk; copy # copy datafiles and datafile copies datafile '/oracle/dbs/tbs_8.f' to '/oracle/copy/df_8.f', datafilecopy '/oracle/copy/df_2.cp' to '/oracle/dontouch/df_2.f', datafilecopy tag = 'weekly_df1_copy' to '/oracle/copy/df_1.f', # copy archived redo logs archivelog '/oracle/arc_dest/arcr_1_1.arc' to '/oracle/copy/arcr_1_1.arc', archivelog '/oracle/arc_dest/arcr_1_2.arc' to '/oracle/copy/arcr_1_2.arc', # copy a control file copy controlfilecopy '/oracle/copy/cf.f' to '/oracle/dontouch/cf.f'; }
You may need to identify what a server session performing a backup or copy operation is doing. RMAN allows you to perform the following checks:
To identify which server sessions correspond to which RMAN channels, use the set command with the command id parameter. The command id parameter enters the specified string into the CLIENT_INFO column of the V$SESSION dynamic performance view. Join V$SESSION with V$PROCESS to correlate the server session with the channel.
The CLIENT_INFO column of V$SESSION will contain information for each Recovery Manager server session. The data will appear in one of the following formats:
This form appears for the first connection to the target database established by RMAN.
This form appears for all allocated channels.
The SPID column of V$PROCESS identifies the O/S process number.
See Also: For more information on V$SESSION and V$PROCESS, see the Oracle8i Reference.
% rman target / catalog rman/rman@rcat
run { allocate channel t1 type disk; allocate channel t2 type disk; set command id to 'rman'; backup incremental level 0 filesperset 5 tablespace 'SYSTEM'; # optionally, issue a host command to access the O/S prompt host;sql 'ALTER SYSTEM ARCHIVE LOG ALL';}
SELECT sid, spid, client_info FROM v$process p, v$session s WHERE p.addr = s.paddr AND client_info LIKE '%id=rman%'; SID SPID CLIENT_INFO ---------- --------- ---------------------------------------------------------------- 8 21973 id=rman 16 22057 id=rman 17 22068 id=rman,ch=t1 18 22070 id=rman,ch=t2
See Also: For set command id syntax, see "set_run_option".
Monitor the progress of backups, copies, and restores by querying the view V$SESSION_LONGOPS.
Each server session performing a backup, restore, or copy reports its progress compared to the total amount of work required for that particular part of the restore. For example, if you perform a restore using two channels, and each channel has two backup sets to restore (a total of 4 sets), then each server session reports its progress through a single set. When that set is completely restored, RMAN starts reporting progress on the next set to restore.
Query this information using the following SQL statement:
SELECT sid, serial#, context, sofar, totalwork round(sofar/totalwork*100,2) "% Complete", FROM v$session_longops WHERE opname LIKE 'RMAN:%' AND opname NOT LIKE 'RMAN: aggregate%';
See Also: For more information on V$SESSION_LONGOPS, see the Oracle8i Reference. If you want more detailed progress and performance information, see V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO.
Monitor backup and restore performance by querying V$BACKUP_SYNC and V$BACKUP_ASYNC_IO. For a complete description of the contents of these views and how you can use them to tune backup performance, see Oracle8i Tuning.
See Also: For more information on these views, see the Oracle8i Reference.
Following are some useful scenarios for performing backups and copies:
The following command reports all datafiles in the database that would require the application of 6 or more incremental backups to be recovered to their current state:
report need backup incremental 6 database;
The following command reports all datafiles from tablespace SYSTEM that have not had a backup (full or incremental) in five or more days:
report need backup days 5 tablespace system;
The following example, which assumes that the database is running in ARCHIVELOG mode, shows a common way to back up the database (skipping tablespaces that are offline):
run { allocate channel dev1 type 'sbt_tape'; backup database skip readonly skip offline; }
You need to back up a read-only tablespace only once after it has been made read-only. You can use the skip readonly option to skip read-only datafiles. If you use the skip offline option, then the backup will not attempt to access offline datafiles. Use this option if the offline datafiles are not available.
Typically, you do not need to specify a format when backing up to tape because the default %U conversion variable generates a unique filename for all tape backups. When backing up to disk, however, you can specify a format if you want to spread your backup across several disk drives for improved performance. In this case, allocate one disk channel per disk drive and specify the format string on the allocate channel command. Specify the format so that the filenames are on different disks.
For example, issue:
run { allocate channel disk1 type disk format '/disk1/%d_backups/%U'; allocate channel disk2 type disk format '/disk2/%d_backups/%U'; backup database; }
In this scenario, you have a 40 Gb database that you want to back up to disk. Because RMAN does not back up to raw disk, you must spread the backup across filesystems. You decide to back up to four filesystems and make each backup set roughly the same size: 10 Gb. You want to make each backup piece no more than 2 Gb so that each backup set contains five backup pieces.
You decide to use the format parameter of the allocate channel command so that each channel will write to a different filesystem. You use conversion variables to guarantee unique names for the backup pieces. For example, the following RMAN script spreads the backup across four filesystems (/fs1, /fs2, /fs3, /fs4), creating four backup sets in these directories and grouping the datafiles so that each backup set is about the same size.
run { allocate channel fs1 type disk format='/fs1/%u.%p'; allocate channel fs2 type disk format='/fs2/%u.%p'; allocate channel fs3 type disk format='/fs3/%u.%p'; allocate channel fs4 type disk format='/fs4/%u.%p'; setlimit channel fs1 kbytes=2000000; #limit file size to 2Gb setlimit channel fs2 kbytes=2000000; setlimit channel fs3 kbytes=2000000; setlimit channel fs4 kbytes=2000000; backup database; }
When making backups, RMAN divides the total number of files requiring backups by the number of allocated channels to calculate the number of files to place in each backup set. Use the filesperset and setsize parameters to override this calculation and specify how many files should go in each backup set.
When you specify the filesperset parameter, RMAN compares the filesperset value to the automatically calculated value (number of files / allocated channels) and takes the lowest of the two, thereby ensuring that all channels are used. If the number of files specified or implied by the combined backupSpec clauses is greater than filesperset, e.g., eight total files need backing up when filesperset = 4, then RMAN creates multiple backup sets to maintain the correct ratio of files per backup set.
If you do not specify filesperset, RMAN compares the calculated value (number of files / allocated channels) to the default value of 64 and takes the lowest of the two, again ensuring that all channels are used. The default value of 64 is high for most applications: specify a lower value or use the setsize parameter to limit the size of a backup set.
RMAN always attempts to create enough backup sets so that all allocated channels have work to do. An exception to the rule occurs when there are more channels than files to back up. For example, if RMAN backs up one datafile when three channels are allocated and filesperset = 1, then two channels are necessarily idle.
This example parallelizes a backup, specifying that no more than three datafiles go in any one backup set, and no more than one archived redo log in any one backup set:
run { allocate channel ch1 type disk; allocate channel ch2 type disk; allocate channel ch3 type disk; allocate channel ch4 type disk; backup datafile 1,2,3,4,5,9,10,11,12,15 filesperset = 3 archivelog all filesperset = 1; }
The setsize parameter specifies a maximum size for a backup set in units of 1K (1024 bytes). Thus, to limit a backup set to 2Mb, specify setsize = 2000. RMAN attempts to limit all backup sets to this size, which is useful in media manager configurations when you want each backup set to be no larger than one tape.
Configure your backup sets so that they fit on one tape volume rather than span multiple tape volumes. Otherwise, if one tape of a multi-volume backup set fails, then you lose the whole backup set.
The setsize parameter is easier to use than filesperset when you make backups of archived redo logs. This scenario backs up archived redo logs to tape, setting the size at 2Mb to ensure that each backup set fits on one tape volume:
run { allocate channel ch1 type 'sbt_tape'; allocate channel ch2 type 'sbt_tape'; backup setsize = 2000 archivelog all;
}
The setsize parameter is also easier for datafile backups when your datafiles are striped or reside on separate disk spindles and you either:
For example, if your datafiles are striped four ways, then setting filesperset = 4 allows each backup set to read data from four disk spindles, thereby distributing the I/O load.
Assume you want to back up a database called FOO. The following conditions obtain:
You set filesperset equal to 4 because it is sufficient to keep the tape drive streaming. In this example, you are not concerned about how datafiles are grouped into backup sets.
Issue the following commands:
create script foo_full { allocate channel t1 type 'SBT_TAPE'; allocate channel t2 type 'SBT_TAPE'; allocate channel t3 type 'SBT_TAPE'; backup filesperset 4 database format 'FOO.FULL.%n.%s.%p'; }
This script will back up the whole database, including all datafiles and the control file. Since there are 27 files to be backed up (26 datafiles and a control file) and a maximum of four files per backup set, Oracle creates seven backup sets. The backup piece filenames will have the following format, where db_name is the database name, set_num is the backup set number, and piece_num is the backup piece number:
FOO.FULL.db_name.set_num.piece_num # for example, a file may have the following name: FOO.FULL.prod1.3.1
Assuming no backup sets have been recorded in the recovery catalog prior to this job, then set_num will range from 1 through 7 and piece_num will be 1 or more.
Note that in the SBT API version 2.0, media vendors can specify the maximum size of a backup piece, causing RMAN to comply with this restriction automatically.
You can also back up archived redo logs to tape. You can specify the range of archived redo logs by time, SCN, or log sequence number.
|
Note: If specifying by time range, set the NLS_LANG and NLS_DATE_FORMAT environment variables before invoking Recovery Manager. See "Setting NLS Environment Variables". |
Specifying an archived log range does not guarantee that RMAN backs up all redo in the range. For example, the last archived log may end before the end of the range, or a log in the range may be missing. RMAN backs up the logs it finds and does not issue a warning. Online logs cannot be backed up; you must first archive them.
This example backs up the logs archived between 8:57 p.m. and 9:06 p.m. on November 18, 1998.
NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS' run { allocate channel dev1 type 'sbt_tape'; backup archivelog all from time 'Nov 13 1998 20:57:13' until time 'Nov 13 1998 21:06:05'; }
The following example backs up all archived logs from sequence# 288 to sequence# 301 and deletes the archived redo logs after the backup is complete. If the backup fails the logs are not deleted.
run { allocate channel dev1 type 'sbt_tape'; backup archivelog from logseq 288 until logseq 301 thread 1 delete input; }
The following command backs up all archived logs generated during the last 24 hours. The example archives the current redo log first to ensure that all redo generated up to the present gets backed up.
run { allocate channel dev1 type 'sbt_tape'; sql "ALTER SYSTEM ARCHIVE LOG CURRENT"; backup archivelog from time 'SYSDATE-1'; }
See Also: For more information about your environment variables, see your operating system-specific documentation.
In this scenario, you set your initialization parameters so that you automatically archive your redo logs to two locations: /oracle/arch/dest_1/* and /oracle/arch/dest_2/*. Therefore, you have two identical copies of the archived redo log for each log sequence number. You decide to back up each copy of your archived redo logs and then delete the originals.
Because the backup archivelog all command has the meaning of "Back up exactly one copy of each distinct log sequence number," RMAN will not put two copies of the same log sequence number into the same backup set. Furthermore, if you specify the delete input option, RMAN only deletes the specific copy of the archived redo log that it backs up.
The easiest solution in this case is to back up both copies of each archived redo log and then delete both copies. Use the like parameter of the archivelogRecordSpecifier to indicate which destination to use. The like parameter allows you to match file filenames in both of your archive destinations. For example, execute the following:
run { allocate channel t1 type 'sbt_tape'; allocate channel t2 type 'sbt_tape'; backup filesperset=20 format='al_%d/%t/%s/%p' (archivelog all like '/oracle/arch/dest1/%' channel t1 delete input) (archivelog all like '/oracle/arch/dest2/%' channel t2 delete input); }
This example backs up the archived redo logs in the primary destination on one set of tapes and the logs from the second destination on another set of tapes. This scenario assumes that you have two tape drives available. Note that some tape subsystems will combine the two RMAN channels into a single data stream and write them to a single tape drive. You may need to configure your media management vendor to prevent this scenario from occurring.
A differential incremental backup contains only blocks that have been changed since the most recent backup at the same level or lower. The first incremental backup must be a level 0 backup that contains all used blocks.
run { allocate channel dev1 type 'sbt_tape'; backup incremental level 0 database; }
An incremental backup at level 1 or higher will contain all blocks changed since the most recent level 1 backup. If no previous level 1 backup is available, RMAN copies all blocks changed since the base level 0 backup.
run { allocate channel dev1 type 'sbt_tape'; backup incremental level 1 database; }
If you add a new datafile or tablespace to the database, then make a level 0 backup before making another incremental backup. Otherwise, the incremental backup of the tablespace or the database will fail because Recovery Manager does not find a parent backup for the new datafiles.
run { allocate channel dev1 type 'sbt_tape'; backup incremental level 0 tablespace new_tbs; }
Note that you can perform incremental backups in NOARCHIVELOG mode.
A cumulative incremental backup at level n contains only blocks that have been changed since the most recent backup at level n - 1 or lower. Cumulative backups require more storage space than differential backups, but they are preferable during a restore operation because only one backup for a given level is needed. Note that the first incremental backup must be a level 0 backup that contains all used blocks.
A cumulative backup at level 2 will contain all blocks changed since the most recent level 1 backup, copying all blocks changed since the base level 0 backup only if a previous level 1 is unavailable. In contrast to a cumulative backup, a differential backup at level 2 will determine which level 1 or level 2 backup occurred most recently and copy all blocks changed since that backup.
run { allocate channel dev1 type 'sbt_tape'; backup incremental level 2 cumulative # blocks changed since level 0 or level 1 database; }
Prudence suggests making multiple copies of your backups to protect against disaster, media damage, or human error. Oracle allows you to make up to four backup sets simultaneously, each an exact duplicate of the others.
The set duplex command, which affects only the backup command, specifies the number of copies of each backup piece that RMAN should create. The set duplex command affects all channels allocated after issuing the command and is in effect until explicitly disabled (OFF) or changed during the session.
For example, you can enter:
run { set duplex=3; allocate channel ch1 type 'sbt_tape'; backup datafile 1; }
This command will create three identical backups of datafile 1. Each backup piece will have a unique name since the %U default format guarantees it.
Note that you must set the BACKUP_TAPE_IO_SLAVES initialization parameter to TRUE in order to perform duplexed backups; otherwise, an error will be signaled. RMAN will configure as many slaves as needed for the number of backup copies you request.
See Also: For more information on the BACKUP_TAPE_IO_SLAVES initialization parameter, see the Oracle8i Reference.
If you want to create multiple backup sets and allocate multiple channels, then RMAN automatically parallelizes its operation and writes multiple backup sets in parallel. The allocated server processes divide up the work of backing up the specified datafiles, control files, and archived redo logs. Note that you cannot stripe a single backup set across multiple channels.
RMAN automatically assigns a backup set to a device. You can specify that Oracle should write all backup sets for a backupSpec to a specific channel using the channel parameter.
For example, this RMAN parallelizes the backup operation by specifying which channels RMAN should allocate for which operations:
run { allocate channel ch1 type 'SBT_TAPE'; allocate channel ch2 type disk; allocate channel ch3 type disk; backup # channel ch1 backs up datafiles to tape (datafile 1,2,3,4 channel ch1) # channel ch2 backs up control file copy to disk (controlfilecopy '/oracle/copy/cf.f' channel ch2) # channel ch3 backs up archived redo logs to disk (archivelog from time 'SYSDATE-14' channel ch3); }
This script puts the database into the correct mode for a consistent, whole database backup and then backs up the database. Note that the script performs a shutdown, startup, shutdown, and then startup again before performing a duplexed backup:
# Shut down the database cleanly using immediate priority. This type of shutdown lets # current calls to the database complete, but prevents further logons or calls. # If the database is not up now, you will get a message saying so but RMAN will not # treat this situation as an error. shutdown immediate; # Start up the database in case it crashed or was not shutdown cleanly prior to # starting this script. This will perform a crash recovery if it is needed. Oracle # uses the default INIT.ORA file. Alternatively, use this form: startup force dba # pfile=<filename>. Use the DBA option because you are going to shut down again right # away and do not want to let users in during the short interval. Use the FORCE # option because it cannot hurt and might help in certain situations. startup force dba; shutdown immediate; # Here, we know that the database is cleanly closed and is now ready for a cold # backup. RMAN requires that the database be started and mounted to perform a backup, # so do that now. startup mount; run { # duplex the backup set duplex = 2; # allocate channel t1 type 'SBT_TAPE'; # allocate channel t2 type 'SBT_TAPE'; allocate channel t1 type disk; allocate channel t2 type disk; set limit channel t1 kbytes 2097150; set limit channel t2 kbytes 2097150; backup incremental level 0 filesperset 5 database; } # now that the backup is complete, open the database. alter database open;
Note that you can skip tablespaces, but any skipped tablespace that has not been offline or read-only since its last backup will be lost if the database has to be restored from a backup. When backing up to disk, make sure that the destination (file system or raw device) has enough free space.
The following script distributes datafile and archived redo log backups across two nodes in a parallel server environment:
run { allocate channel node_1 type disk connect 'sys/sys_pwd@node_1'; allocate channel node_2 type disk connect 'sys/sys_pwd@node_2'; backup filesperset 1 (tablespace system, rbs, data1, data2 channel node_1) (tablespace temp, reccat, data3, data4 channel node_2); backup filesperset 20 (archivelog until time 'SYSDATE' thread 1 delete input channel node_1); (archivelog until time 'SYSDATE' thread 2 delete input channel node_2); }
See Also: For more information about OPS backups, see Oracle8i Parallel Server Concepts and Administration.
You can use O/S utilities to make datafile copies and then catalog them in the recovery catalog. Note that you can only catalog copies made to disk. Because the format of backup pieces is proprietary, O/S utilities cannot write backups that Recovery Manager can read.
You must make the datafile copies using O/S techniques. If the database is open and the datafile is online, first issue ALTER TABLESPACE BEGIN BACKUP. The resulting image copy can be cataloged:
catalog datafilecopy '?/dbs/tbs_33.f';
How long you must keep backups and copies depends on factors such as:
For example, if you back up all datafiles daily, do not require point-in-time recovery, and need only one backup per datafile, then you can delete previous backups as soon as the new one completes.
# delete a specific datafile copy change datafilecopy '?/dbs/tbs_35.f' delete; # delete archived redo logs older than 31 days change archivelog until time 'SYSDATE-31' delete';
You must allocate a channel before deleting a backup piece. The specified backup piece must have been created on the same type of device. Note that the allocate channel for maintenance command is not issued inside of a run command.
# delete a backup piece allocate channel for maintenance type 'sbt_tape'; change backuppiece 'testdb_87fa39e0' delete;
release channel;
By default a checksum is calculated for every block read from a datafile and stored in the backup or image copy. If you use the nochecksum option, then checksums are not calculated. If the block already contains a checksum, however, then the checksum is validated and stored in the backup. If the validation fails, the block is marked corrupt in the backup.
The set maxcorrupt for datafile command determines how many corrupt blocks in a datafile that backup or copy will tolerate. If any datafile has more corrupt blocks than specified by the maxcorrupt parameter, the command aborts. Note that if you specify the check logical option, RMAN checks for logical and physical corruption.
By default, the backup command terminates when it cannot access a datafile. You can specify various parameters to prevent termination:
run { allocate channel dev1 type 'sbt_tape'; set maxcorrupt for datafile 1,2,3 to 5; backup database skip inaccessible skip readonly skip offline; }
