Skipping Tablespaces when Backing Up a Database: Example
The following example assumes that the database is running in
ARCHIVELOG mode and that you have an automatic sbt channel configured as follows:RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 1; RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=(NSR_DATA_VOLUME_POOL=BackupPool)';
To back up the database while skipping offline and read-only tablespaces, you can run the following command:
RMAN> BACKUP DATABASE
SKIP READONLY
SKIP OFFLINE;
You only need to back up a read-only tablespace once after it has been made read-only. You can use the
SKIP READONLY option to skip read-only datafiles. If you use theSKIP OFFLINE option, then the BACKUP command does not attempt to access offline datafiles. Use this option if the offline datafiles are not available.
Another way to persistently skip tablespaces across RMAN sessions is to issue the
CONFIGURE EXCLUDE command for each tablespace that you always want to skip. For example, you may always want to skip the example tablespace, which has been made read-only. You can then issue:RMAN> CONFIGURE EXCLUDE FOR TABLESPACE example;
Then, whenever you run
BACKUP DATABASE, RMAN skips this tablespace. You do not have to specify a SKIP clause on the BACKUP command. You can override this behavior and include the example tablespace as follows:RMAN> BACKUP DATABASE NOEXCLUDE;
Restarting a Backup: Example
Assume that you back up the database and archived logs every night to tape by running this command:
RMAN> BACKUP MAXSETSIZE 10G DATABASE PLUS ARCHIVELOG;
The preceding command sets an upper limit to the size of each backup set so that RMAN produces multiple backup sets. Assume that the media management device fails halfway through the backup and is then restarted. The next day you discover that only half the backup sets completed. In this case, you can run this command in the evening:
RMAN> BACKUP # Note that the NOT BACKED UP SINCE clause should be placed immediately after the BACKUP # keyword or after each individual backupSpec clause NOT BACKED UP SINCE TIME 'SYSDATE-1' MAXSETSIZE 10M DATABASE PLUS ARCHIVELOG;
With this form of the command, RMAN backs up only files that were not backed up during in the previous 24 hours. When RMAN finds out that a backup from the specified time window is already avaialble, it displays output similar to the following:
RMAN-06501: skipping datafile 1; already backed up on NOV 02 2003 18:10:00 RMAN-06501: skipping datafile 2; already backed up on NOV 02 2003 18:09:45 RMAN-06501: skipping datafile 3; already backed up on NOV 02 2003 18:09:45
If the
NOT BACKED UP SINCE clause is placed immediately after the backup command, it affects all objects to be backed up. It can also be placed after individualbackupSpec clauses, to cause only backups for those objects described by the backupSpec to be subject to the limitation.Spreading a Backup Across Multiple Disk Drives: Example
Typically, you do not need to specify a format when backing up to tape because the default
%U variable generates a unique filename for tape backups. When backing up to disk, however, you can specify a format if you need to spread the backup across several drives for improved performance. In this case, allocate one DISK channel for each disk drive and specify the format string on the ALLOCATE CHANNEL command so that the filenames are on different disks. For example, issue:RUN
{
ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;
}
You can distribute backups in this manner by default in the future, by configuring channels as follows:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U'; CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U'; CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U'; BACKUP AS COPY DATABASE;
If you specify a nonexistent directory, RMAN displays output such as the following:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/29/2001
14:36:04
ORA-19504: failed to create file "/nosuchdisk/0cd2momi_1_1"
ORA-27040: skgfrcre: create error, unable to create file
SVR4 Error: 2: No such file or directory
Specifying the Size of Backup Sets: Example
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
MAXSETSIZE parameter to override this calculation and specify how many files should go in each backup set.
The
MAXSETSIZE parameter specifies a maximum size for a backup set in units of bytes (default), kilobytes, megabytes, or gigabytes. Thus, to limit a backup set to 305 MB, specify MAXSETSIZE=305M. RMAN attempts to limit all sets to this size.
You can use
MAXSETSIZE to limit the size of backup sets so that the database is divided among more than one backup set. If you configure MAXSETSIZE so that you generate multiple backup sets, however, then if the backup fails partway through, you can use the restartable backup feature to back up only those files that were not backed up during the previous attempt. See "Restartable Backups" for a conceptual overview of restartable backups.
The following example configures a tape device, then backs up archived redo logs to tape, limiting the size to 100 MB so that if the backup fails partway through, it can be restarted:
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 1; RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; RMAN> BACKUP MAXSETSIZE = 100M ARCHIVELOG ALL;
This example accomplishes the same result with
CONFIGURE MAXSETSIZE:RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; RMAN> CONFIGURE MAXSETSIZE = 100M; RMAN> BACKUP ARCHIVELOG ALL;
Note that if you specify a
MAXSETSIZE value that is too small to contain the biggest file that you are backing up (either the actual size of that file, or if binary compression is specified, then the size of tha tfile after compression), then RMAN displays an error stack such as the following:RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/03/03 14:40:33
RMAN-06182: archive log larger than MAXSETSIZE: thread 1 seq 1
/oracle/oradata/trgt/arch/archive1_1.dbf
Limiting the Size of Backup Pieces: Example
Backup piece size is an issue in those situations where it exceeds the maximum file size of the file system or media management software. Use the
MAXPIECESIZEparameter of the CONFIGURE CHANNEL or ALLOCATE CHANNEL command to limit the size of backup pieces.
For example, to always limit the backup piece size to 2GB or less, you can configure the automatic
DISK channel as follows and then run BACKUP DATABASE:# max file size for backup pieces is 2GB RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2GB; RMAN> BACKUP DATABASE;
Note that in version 2.0 of the media management API, media management vendors can specify the maximum size of a backup piece that can be written to their media manager. RMAN will respect this limit regardless of the settings you configure for
MAXPIECESIZE
No comments:
Post a Comment