Oracle7 Enterprise Backup Utility Administrator's Guide | ![]() Library |
![]() Product |
![]() Contents |
![]() Index |
This chapter describes the restore and recovery component of the Enterprise Backup Utility.
The following topics are covered:
The type of restore depends on two factors:
Whenever a restore database (consistent or otherwise), is performed, the database needs to be fully shutdown. To verify this status, the database will be started and mounted exclusively by EBU before each restore that requires it to be down. By doing that, EBU ensures, in the case of Oracle Parallel Server, that no other instance has the database mounted and that the database is fully shutdown. The startup might fail if the control files are lost or the parameter files have been lost, in that case EBU will assume that the database is in the correct state.
It might be desirable to use a sized down parameter file when verifying the state of the database, or when the original parameter file is lost. The specifier startup_pfile=<pfile> can be used in these circumstances to direct EBU to use this alternative parameter file.
If the database can be started but not mounted due to other instances having it mounted in shared mode, the restore will be aborted.
Each database file type is restored following the rules given below in the restore subset section.
Whenever you do not restore all the datafiles belonging to a database, it is called a subset restore or partial restore. Subset restores can be performed when the database is either online or offline.
There are 4 types of objects that can be restored. They are the following:
Datafiles are restored to the same location where they were backed up, unless remap is used See "Remap". Since generally the datafile is very large and could even be a physical or a logical device, it is not possible to make a saved copy of it before restoring it, the datafile is restored over the original place even if a previous datafile still exists with data in it. The user needs to back up the datafile before the restore if the existing data is to be preserved.
If the datafile is not a logical or physical device (i.e, a regular file), the file is first truncated and then restored to ensure that the restored size is correct.
If the datafiles are restored when the database is online, the datafiles need to be offline, either because the datafile itself has been placed offline, or because the tablespace has been offlined, unless the datafile is being remapped.
The online datafiles belonging to tablespaces with offline datafiles are not restored by default when restore database or restore <subset> is used, as these files are not backed up by default during online backups.
In order to restore datafiles that belong to a tablespace with offline datafiles, the datafiles have to be explicitly requested during the restore <subset>. It is not possible to restore these datafiles when using restore database. Only during restore database consistent are they restored by default.
Note that the SYSTEM tablespace or any of the datafiles belonging to it cannot be restored without remapping if the database is online.
A control file might or might not be restored to its original location. In order for the control file to be restored to its original location, the database has to be shut down, otherwise an error is issued.
There are some circumstances that cause the controlfile restore to be done to its original location:
In this case, if a control file exists and it is a regular file, it is first backed up to a copy, its name being generated using the original name with the .<jobid> suffix added, where <jobid> is the number of the job generated by EBU.
For example, for restore job #40 the control file /oracle/data/cntrl1@.dbf will be backed up to /oracle/data/cntrl1@.dbf.40 before the restore happens.
If the control file is not a regular file, but a logical/physical device, an attempt is made to back it up. If this fails, a warning is issued, but the job does not fail. The backup copy is placed in the default directory for database files (operating system specific). The name of the control file is created using the basename of the control file and the .<jobid> suffix. I.e. control file /dev/rrz4c is backed up as rrz4c.<jobid> before the restore happens.
When the control file is being restored to its original place and the control file chosen by EBU comes from a backup online, then recovery needs to be performed using the `using backup controlefile' clause, this in turn will force the database to be open with RESETLOGS option. If the recover specifier is used for the restore, then EBU will automatically issue these commands.
Also, it is worth noting that when recovery to a point in time is specified with restore, the database will be opened using the database RESETLOGS option. See "Resetlogs" for implications of this operation.
Parameter files can be restored any time irrespective of the state of the database. If the parameter file exists, the restored parameter file is not restored to its original location. Instead, the suffix .<jobid> is added. Otherwise, the file is restored to its original location.
Archivelog files can be restored any time, irrespective of the state of the database. There are two possibilites when restoring archivelog files. They are the following:
EBU automatically performs aggregated restores, except when a consistent database is specified.
An aggregate restore means that EBU will determine which are the most recent backups of each datafile (all of them, if database is specified). These files do not need to come from a single job, or even from a single configuration. The most recent backup selection is performed automatically by EBU.
Since the restored datafiles may belong to different jobs with possibly different configurations and different database states (online, offline), the resulting set of datafiles may not be consistent with each other and recovery may need to be performed.
The database RECOVER command can be performed manually or automatically by EBU. EBU can handle many database recovery situations involving the database RECOVER command, but there are some that will require that the RECOVER be performed manually via the command-line interface to the server.
A consistent restore brings all datafiles in the database to a consistent state (all files are restored as of a single point-in-time), where no recovery is needed to open the database. This can only be accomplished if all the files come from a single backup offline database.
Furthermore, the restore database consistent without Point in Time specification requires that no configuration update has been recorded in the catalog database since the last offline backup. If configuration updates have been recorded, a to specifier needs to be used with the restore command to force a point-in-time restore.
When restore database consistent is used, the online datafiles of the tablespaces containing offline datafiles are restored by default, as they were backed up during the offline backup.
Offline backups can be taken when the database is operating in ARCHIVELOG mode. In that case, the offline backup will also back up the archivelogs found in the archive destination. Under such circumstances, the restore database consistent can still be recovered to the current point in time (assuming all archivelogs and online redo logs are restored and online redo logs are present). This recovery can be performed manually or automatically by EBU (using the recover specifier).
You must perform "minimal" recovery, if recovery to current point in time is not done for any of the following reasons:
This type of recovery must be performed manually; EBU cannot perform this type of recovery.
To perform minimal recovery and open a database following a restore database consistent, execute the following commands after connecting to the database in Server Manager:
SVRMGRL> STARTUP MOUNT; SVRMGRL> RECOVER DATABASE UNTIL CANCEL; SVRMGRL> ALTER DATABASE OPEN RESETLOGS;
See "Resetlogs" for implications.
Files which were backed up using the include_dbfile are only restored if the include_dbfile is used during restore. Since the backup was an image copy, it will not be recovered automatically by the recover specifier.
By default, EBU will always restore the latest backup of the database or datafile. Sometimes it might be desirable to restore the database or datafiles using a backup older than the latest. This might be necessary when, for example, the latest backup is not available due to media failure, or when the latest backup has logical corruptions, or when a previous database configuration is wanted.
Point-in-time restore is independent of recovery. Point in time restore only forces the use of specific BFS's. These BFS's can then be recovered to any point in time after the point in time of the restore, including the current point in time if all the archivelogs and online redo logs are present (except in the case of crossing a RESETLOGS boundary.)
If the database is operating in archivelog mode, the latest backup of the specified datafiles (which belong to jobs finished before the specified point in time) will be used for the restore. The aggregate restore and the rules for the database objects described above apply.
If the operation is a restore database consistent, the latest offline backup (belonging to the configuration implicitly selected by the specified point in time) will be used.
The to specifier is used to indicate the point in time to restore to. The format for the to specifier is: MM/DD/YYYY [HH24[:MI[:SS]]].
Once the datafiles are restored, they have to be made consitent with each other and with the controlfile. This process is called recovery. EBU can automatically perform the recovery for most situations, although given the varied range of possibilities it might be necessary to sometimes perform recovery manually. Recovery is required before the database can be opened.
EBU recovery uses the following procedure. In case of failure in any part of the recovery, the user must address the source of the problem (detailed error messages are written to the log file) and perform manual recovery.
During recovery, detailed error messages from both the Oracle7 Server and the Enterprise Backup Utility are written to the EBU log file. If recovery fails, use this log file to diagnose and fix problems.
EBU only tries to recover the database once following a restore job. If this initial attempt to recover the database is unsuccessful, the user must fix the recovery problem, then either perform manual recovery, or restart the entire restore/recovery job.
All database recoveries involve bringing the database to a particular point in time, usually the point immediately preceding a media failure, i.e. the present point in time.
When the recovery does not use all redo generated since the last backup (including the online redo logs), it is called an incomplete recovery, as not all redo has been applied. By default, EBU will try to recover to the current point in time.
At times you must peform incomplete recovery - to retrieve a table that was accidentally dropped, for example. You must restore all database files when performing point in time recovery; you cannot restore only a subset.
If you perform incomplete recovery, remember that you will erase all database transactions made since the point in time you are recovering the database to.
If online redo logs are not present or the recovery is to be incomplete, a point-in-time recovery is needed. This operation can be automatically performed by EBU with the recover=[<scn>|<date>] specifier. Point in time recovery is not possible unless the database is fully shutdown.
Note: The time to which you want to recover must be entered in the format MM/DD/YYYY HH24:MI. This is a different format than used the SQL command RECOVER UNTIL. |
After an incomplete recovery, the database has to be opened using the RESETLOGS option (See "Resetlogs" for implications).
ALTER DATABASE OPEN RESETLOGS is typically necessary in the following situations:
You must update information in the backup catalog following an OPEN RESETLOGS.
After opening the database with resetlogs, an immediate backup database should be performed, as recovery is not possible across a RESETLOGS point.
The Enterprise Backup Utility can restore a database to a different host. If the original host is damaged, for instance, you can use the backup_host specifier to tell the utility to use backups from the original host to restore the database in the corresponding location on a different machine. The location on the new host must be identical to the location on the original host unless remap or remap_path is used.
The backup_host specifier is only needed if the restore occurs on a node which is not part of the Parallel Server configuration, or in the case of a non Parallel Server Database, when the restore host is not the same as the backup host.
In EBU 2.1, restores from an Oracle Parallel Server are only possible in an automatic fashion if the restore node is the same as the backup node, otherwise the backup_host specifier needs to be used.
As of EBU 2.2 it is possible to restore an Oracle Parallel Server database from any of the nodes that have been registered in the database, so the backup_host specifier is not needed for this circumstance.
Archived redo logs are restored by default whenever at least one datafile is restored. Archived redo logs are not restored by default when only control or parameter files are restored, although you can specify that they be restored with control or parameter files.
Typically there are fewer database files than there are archivelogs. Each backup job can contain hundreds of archivelog files. The format of the archivelogs might change from time to time. In order to keep track of the archivelogs, EBU stores the range of sequences that are backed up for each thread. By default, archivelogs are grouped thirty-two (32) at a time into a single BFS.
By default, a backup job that includes datafiles will attempt to restore all archivelogs for all threads that were backed up by all the different jobs that comprise the restore, and all the archivelogs that have been backed up until the current point in time.
For example, assume the following backup jobs:
By default the archivelogs restored will be:
Restore Of | Archivelogs Restored |
---|---|
data1, data2 |
345 to 682 |
data5 |
550 to 682 |
data6 |
550 to 682 |
database |
345 to 682 |
Sometimes it might be necessart to restore more archivelogs that are restored automatically. This can happen when:
In these cases the start_lsn specifier can be used to augment the archivelogs to be restored. The actual sequence number will only be used to figure out the job needed to start tbe archivelog group restore, and will not be limited to that actual sequence, as the following examples show:
At times, it may be necessary to control the upper limit of the archivelogs to be restored, the end_lsn specifier can be used in this instance to point to a job which limits the group of archivelogs restored. Again, as for start_lsn the archivelogs restored will not be limited to that sequence, but to a group of archivelogs as the following examples show:
When backups are performed for a Parallel Server, each backup might include archivelogs of more than one thread. EBU keeps track of all the sequences for all the threads. When a restore is performed, the start_lsn and end_lsn specifier can be specified with the thread number, in the format <thread#>:<sequence#>. If no thread is specified, the thread defaults to either the thread of the node on which the restore is being performed (if it can be obtained) or to 1 (if the database cannot be mounted).
The actual archivelogs restored will not necesarilly be all the archivelogs in the required range, as previously mentioned, only archivelogs not already existent on disk are restored.
Just like a database file, an archivelog could have been backed up many times, EBU will always select the latest copy of an archivelog. As mentioned on the backup chapter, it is also possible to make multiple copies of the archivelogs in a single backup job (by using the arch_copies specifier). EBU will restore the latest copy of the multiple copies in the single job.
If it happens that the latest copy of the archivelog is located in a corrupted BFS, it is necessary to force EBU to restore one of the other copies. A special restore command is used for that purpose: restore bfs=<bfsname>. To obtain the BFS names where a particular archivelog file is located, ebutool -whatbfs=<file> can be used.
A job report detailing the archivelog range sequence for all threads which were backed up by a given job is easily obtained using ebutool.
When a datafile is restored to a different location than where it was originally backed up, it is called a remap. EBU allows the remapping of all datafiles, control files, parameter files and archivelog files.
Datafiles, control files and parameter files are remapped individually using the remap specifier. In this case, the remap might not only change the location of the file, but its actual name as well.
When a large number of datafiles are being remapped and all of them have a common path, the remap_path can be specified to rename them with a single specifier. The path is not limited to be a directory, but it also can include a prefix common to all the datafiles.
If the datafiles have been remapped the RDBMS needs to be informed of this change of name by using ALTER DATABASE RENAME before the database can be opened. EBU can be instructed to perform the renaming automatically after the restore by using the rename specifier.
If the recover specifier is used and remap or remap_path is also used, then the rename specifier must also be used.
If the parameter file is being remapped and the original parameter file does not exist and the recover specifier is used, then the startup_pfile specifier must be used, to indicate to EBU the new location of the parameter file so that the database can be started.
When controlfiles are remapped the parameter file used for startup needs to be modified to specify the new location before the database can use them. If EBU is to use these remapped control files, a parameter file with these new locations should be created before the restore job is started and the startup_pfile specifier should be used.
The following steps outline the procedure for restoring and recovering a target database. Recovery is an option with the restore command, but it is not the default action.
Additional Information:
Some media management software requires special operating system privileges for the user(s) performing restores. Check your media management software documentation. |
$ ebu script_name
Some situations require that you restore part of a database. You may have to restore part of a database if you accidentally drop a table or tablespace. You may also need to perform this operation if the database has failed, and you need to make critical data available, but cannot wait for the entire database to be restored and recovered.
Under these conditions, you can restore part of the database and recover only the datafiles you need. You always need the SYSTEM tablespace and the tablespaces containing rollback segments to open the database, hence you must restore them in order to open the database successfully.
The following steps help you perform this type of recovery.
Additional Information:
For a complete step-by-step discussion of recovery processes, or more information on renaming datafiles, see the Oracle7 Server Administrator's Guide. |
Once invoked with a command script, the Enterprise Backup Utility performs the following steps:
Tablespace A | Tablespace B |
---|---|
datafile a1 |
datafile b1 |
datafile a2 |
datafile b2 |
datafile a3 |
datafile b3 |
datafile a4 |
|
Use Table 5-6, "Sample Database Backup Scheme" with the table of database restores Table 5-7, "Sample Database Restores" .
Use Table 5-7, "Sample Database Restores" with the sample database backup scheme in "Sample Database Backup Scheme". Assume that all restores are performed on 7/22/96.
Following are four sample restore scripts:
restore database consistent db_name = "PROD" parallel = 4 recover log = "/opt1/oracle/obackup/log/obkPROD.log" Restore of Tablespaces and Control File Without Recovery restore control_file tablespace = "A","B"Example 5-2 Datafile Restore with Remap Option
restore dbfile = "/oracle/dbs/data1PROD.ora" remap = "/oracle/dbs/data1PROD.ora" to "/opt1/newhome/data1PROD.ora"Example 5-3 Point-in-time Restore Database with Point-in-Time Recovery
restore database db_name = "PROD" to = "10/01/1996 12:00" recover = "10/01/1996 15:00"
Additional Information:
For more information on the following topics see the Oracle7 Server Administrator's Guide. |
![]() ![]() Prev Next |
![]() Copyright © 1997 Oracle Corporation. All Rights Reserved. |
![]() Library |
![]() Product |
![]() Contents |
![]() Index |