Release 8.0
A54640-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8(TM) Server Backup and Recovery Guide Release 8.0 A54640-01 |
|
This chapter provides scenarios that use Recovery Manager, and includes the following topics:
In this scenario the database is operating in NOARCHIVELOG mode, and the administrator has chosen to shut it down cleanly and back it up.
It is possible to 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.
You must use Server Manager/LineMode to shutdown the database.
SVRMGR> shutdown; SVRMGR> startup mount
Then start Recovery Manager and enter the following:
run { # backup the database to disk allocate channel dev1 type disk; backup (database format '/oracle/backups/bp_%s_%p'); }
The filename of the backup piece is generated using the format string. When the backup is written to disk, it is important to make sure that the destination (file system or raw device) has enough free space.
In the following examples, the database is running in ARCHIVELOG mode.
To back up a database to tape you must first allocate a tape device. Query V$BACKUP_DEVICE to see what devices are available to you.
The following example shows how to back up the database (except tablespaces that are offline):
run { allocate channel dev1 type 'sbt_tape'; backup skip offline (database format '%d_%u'); }
A read-only tablespace needs to be backed up only once or twice after it has been made read-only. You can use the skip read only 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.
The following example shows how to back up individual tablespaces. It is important to back up tablespaces that contain important data frequently (including system data and any tablespace that contains rollback segments). Tablespaces containing only temporary segments need not be backed up. Because this example backs up to disk, the format string determines the name of the backup file.
run { allocate channel dev1 type disk; backup (tablespace system,tbs_1,tbs_2,tbs_3,tbs_4,tbs_5 format '/oracle/backups/bp_%s_%p'); }
You can also use Recovery Manager to back up individual datafiles as follows:
run { allocate channel dev1 type 'sbt_tape'; backup (datafile '?/dbs/t_dbs1.f' format '%d_%u'); }
The current control file is automatically backed up when the first datafile of the system tablespace is backed up. The current control file can also be explicitly included in a backup or backed up individually.
run { allocate channel dev1 type 'sbt_tape'; backup (tablespace tbs_5 include current controlfile format '%d_%u'); }
You can also back up archived logs to tape. The range of archived logs can be specified by time or log sequence. Note that specifying an archive log range does not guarantee that all redo in the range is backed up. For example, the last archived log may end before the end of the range, or an archived log in the range may be missing. Recovery Manager simply backs up the logs it finds and does not issue a warning. Note that online logs cannot be backed up; they must be archived first.
Hint: Set the NLS_LANG and NLS_DATE_FORMAT environment variables before invoking Recovery Manager.
NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS' run { allocate channel dev1 type 'sbt_tape'; backup (archivelog from time 'Nov 13 1996 20:57:13' until time 'Nov 13 1996 21:06:05' all format '%d_%u'); }
Here we back up all archived logs from sequence# 288 to sequence# 301 and delete the archived logs after the backup is complete. If the backup fails the logs are not deleted.
run { allocate channel dev1 type 'sbt_tape'; backup (archivelog low logseq 288 high logseq 301 thread 1 all delete input format '%d_%u'); }
The following commands back up all archived logs generated during the last 24 hours. We archive the current 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' all format '%d_%u') ; }
See Also: For more information about your environment variables, see your operating system-specific documentation.
The following script distributes datafile and archivelog backups across two instances in a parallel server environment:
run { allocate channel node_1 type disk connect 'internal/kernel@node_1'; allocate channel node_2 type disk connect 'internal/kernel@node_2'; backup filesperset 1 format 'df_%s_%p' (tablespace system, rbs, data1, data2 channel node_1) (tablespace temp, reccat, data3, data4 channel node_2); backup filesperset 20 format 'al_%s_%p' (archivelog until time 'SYSDATE' thread 1 delete input channel node_1); (archivelog until time 'SYSDATE' thread 2 delete input channel node_2); release channel node_1; release channel node_2; }
Here we use Recovery Manager to make copies of datafiles to disk. A datafile copy is an image copy of the datafile.
run { allocate channel dev1 type disk; copy datafile '?/dbs/tbs_01.f/dbs/tbs_01.f' to '?/copy/temp3.f'; }
An incremental backup contains only blocks that have been changed since the previous backup. 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 format '%d_%u'); }
The next incremental backup at level 1 or higher will contain all blocks changed since the previous level 0 or level 1 backup.
run { allocate channel dev1 type 'sbt_tape'; backup incremental level 1 (database format '&d_%u'); }
If a new datafile or tablespace is added to the database then make a level 0 backup before the incremental backup. Otherwise the incremental backup of the tablespace or the database will fail because Recovery Manager doesn't find a parent backup for the new datafiles.
run { allocate channel dev1 type 'sbt_tape'; backup incremental level 0 (tablespace new_tbs format '%d_%u'); }
You can perform incremental backups in NOARCHIVELOG mode.
By default a checksum is calculated for every block read from a datafile and stored in the backup. If you use the nochecksum option then checksums are not calculated. However, if the block already contains a checksum, the checksum is validated and stored in the backup. If the validation fails, the block is marked corrupt in the backup.
The set maxcorrupt clause determines how many corrupt blocks backup tolerates. If any datafile has more corrupt blocks than specified by maxcorrupt, the backup will terminate.
By default, backup will terminate if it cannot access a datafile. If the skip inaccessible option is specified, then backup will skip inaccessible datafiles and continue to back up other files. If skip offline is used, then backup will not attempt to access offline files.
run { allocate channel dev1 type 'sbt_tape'; set maxcorrupt 5; backup (database format 'bp_%s_%p'); }
Datafile copies you make using O/S utilities can be catalogued in the recovery catalog. Note that only copies made to disk can be catalogued. Because the format of backup pieces is proprietary, O/S utilities cannot write backups that Recovery Manager can read.
The datafile copies must be made using Oracle7 techniques. If thedatabase is open and the datafile is online, you must first issue ALTER TABLESPACE BEGIN BACKUP. The resultant backup can be cataloged:
catalog datafilecopy '?/dbs/tbs_33.f';
How long backups and copies must be kept depends on factors such as:
For example, if all datafiles are backed up daily, no point-in-time recovery is needed and only one backup per datafile is sufficient, then previous backups can be deleted as soon as the new one completes.
# list all files#### # delete a specific datafilecopy change datafilecopy '?/dbs/tbs_35.f' delete; # delete archivelogs older than 31 days change archivelog until time 'SYSDATE-31' delete';
There is currently no way to delete all the pieces of a multi-piece backup set with a single command. You must delete all the backup pieces individually.The deletion of any piece of a backup set automatically removes that backup set from consideration for restore and recovery.
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 delete command is not issued inside of a run command.
# delete a backup piece allocate channel for delete type 'sbt_tape'; change backuppiece 'testdb_87fa39e0' delete; release channel;
When and how to restore and/or recover information depends on the state of the database and the location of its datafiles.
The first step toward restoring/recovery is to determine the status of the database by executing the following query:
select status, parallel from v$instance;
If the status is open, then the database is open, but it is possible that some tablespaces and their datafiles need to be restored or recovered.
To recover or restore, execute the following query:
select file#, status, error, recover, tablespace_name, name from v$datafile_header;
If the error column is not null, then either the datafile could not be accessed or its header could not be validated. Unless the error is caused by a temporary hardware or operating system problem, the datafile must be restored or switched to a copy of that datafile:
run { # recover tablespace tbs_1 while the database is open allocate channel dev1 type 'sbt_tape'; sql "alter tablespace tbs_1 offline immediate" ; restore tablespace tbs_1 ; recover tablespace tbs_1 ; sql "alter tablespace tbs_1 online" ; release channel dev1 ; }
If a datafile cannot be accessed due to a disk failure, it is likely that it must be restored to a new location or switched to an existing datafile copy. The following restore example allocates one disk channel and one 'sbt_tape' channel to allow restore to use datafile copies on disk and backups on 'sbt_tape'. This example allocates one disk device and one tape device to allow Recovery Manager to restore both from disk and tape.
run { allocate channel dev1 type disk; allocate channel dev2 type 'sbt_tape'; sql "alter tablespace tbs_1 offline immediate" ; set newname for datafile 'disk7/oracle/tbs11.f' to 'disk9/oracle/tbs11.f' ; restore (tablespace tbs_1) ; switch datafile all ; recover tablespace tbs_1 ; sql "alter tablespace tbs_1 online" ; release channel dev1; release channel dev2; }
Because V$DATAFILE_HEADER only reads the header block of each datafile it does not detect all problems that require the datafile to be restored. For example, if the datafile contains unreadable data blocks, but its header block is intact, no error is reported.
If the file can be accessed (error is null), but the recover column returns "yes," then the file should be recovered. The Recovery Manager recover command first applies any suitable incremental backups and then applies archived logs and/or online logs. The incremental backups and archived logs are restored as needed.
run { # recover tablespace tbs_1 while the database is open allocate channel dev1 type disk ; sql "alter tablespace tbs_1 offline" ; recover tablespace tbs_1 ; sql "alter tablespace tbs_1 online" ; release channel dev1 ; }
If the database status is "mounted," check the control file type:
select LOG_MODE, CONTROLFILE_TYPE, OPEN_RESETLOGS from v$database;
If the database status is "current," try to open the database:
alter database open;
If the open succeeds, then use the procedure above to find out if any tablespaces and datafiles need recovery.
If the open fails, then you need to restore and/or recover the database first. If the control file type is "backup," the database is probably being restored and recovered.
The database must be closed to perform database point-in-time recovery. You can use ServerManager to close the database:
SVRMGR> shutdown abort; SVRMGR> startup nomount;
In this scenario, we are recovering the database up until 3 p.m. Assume that the disk containing tablespace TBS_1 datafiles crashed and that there is no backup of tablespace TEMP1 because it only contains temporary segments, no user data. A new location is specified for TBS_1 datafiles. Note that, by default Recovery Manager will restore the files to their most recent location, not to where they were located at 3 p.m.
Hint: Set the NLS_LANG and NLS_DATE_FORMAT environment variables before invoking Recovery Manager.
NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
run { # recover database until 3pm after restoring tbs_1 to a new location allocate channel dev1 type disk; allocate channel dev2 type 'sbt_tape'; set until time 'Nov 15 1996 15:00:00' set newname for datafile '/vobs/oracle/dbs/tbs_11.f' to '?/dbs/temp1.f' ; set newname for datafile '?/dbs/tbs_12.f' to '?/dbs/temp2.f' ; restore controlfile to '/vobs/oracle/dbs/cf1.f' ; replicate controlfile from '/vobs/oracle/dbs/cf1.f'; sql "alter database mount" ; restore database skip tablespace temp1; switch datafile all; recover database skip tablespace temp1; sql "alter database open resetlogs"; sql "drop tablespace temp1"; sql "create tablespace temp1 datafile '/vobs/oracle/dbs/temp1.f' size 10M"; release channel dev1; release channel dev2; }
Now assume that log sequence 1234 was lost due to a disk crash and the database needs to be recovered using available archivelogs. We know that tablespace READONLY1 has not changed since logseq 1234, so we don't restore it.
run { # recover database until log sequence 1234 allocate channel dev1 type disk; allocate channel dev2 type 'sbt_tape'; set until logseq 1234 thread 1; restore controlfile to '/vobs/oracle/dbs/cf1.f' ; replicate controlfile from '/vobs/oracle/dbs/cf1.f'; sql "alter database mount" ; restore database skip tablespace temp1, readonly1; recover database skip tablespace temp1; sql "alter database open resetlogs"; sql "drop tablespace temp1"; sql "create tablespace temp1 datafile '/vobs/oracle/dbs/temp1.f' size 10M"; release channel dev1; release channel dev2; }
You can use the list command to query the contents of the recovery catalog, or the target database control file if no recovery catalog is used.
# list all backups of files in tablespace tbs_1 that were made since # November first. list until time 'Nov 1 1996 00:00:00' backupset of tablespace tbs_1; # list all backups on device type 'sbt_tape' list device type 'sbt_tape' backupset of database; # list all copies of a datafile, qualified by tag and directory. list tag foo like '/somedir/%' copy of datafile 21; # list all database incarnations registered in the recovery catalog list incarnation of database;
You can also use the list command to determine which copies and backups can be deleted. For example, if a full backup of the database was created on November 2, and it will not be necessary to recover the database to an earlier point-in-time, then the backup sets listed in the following report can be deleted:
list until time 'Nov 1 1996 00:00:00' backupset of database;
You can use the report command to issue more complex queries against the recovery catalog. The report command also works with the target database control file if no recovery catalog is used.
# report on all datafiles which need a new backup because they contain # unlogged changes that were made after the last full or incremental backup. report unrecoverable database; # report on all datafiles which need a new backup because 3 or more incremental # backups have been taken since the last full backup. report need backup incremental 3 database;
# report on all datafiles in tablespace tbs_1 which need a new backup because # the last full or incremental backup was taken more than 5 days ago. report need backup days 5 database;
