Oracle7 Enterprise Backup Utility Administrator's Guide Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index



Go to previous file in sequence Go to next file in sequence

Restoring and Recovering a Database


This chapter describes the restore and recovery component of the Enterprise Backup Utility.

The following topics are covered:

Types of Restore

The type of restore depends on two factors:

Completeness of Restore

Database state after restore

Restore Database

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.

Restore Subset

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

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.

Control Files

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:

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

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

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:

Aggregate Restores

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.

Restore Database Consistent

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.

Restoring Offline Datafiles

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.

Point-In-Time Restore

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]]].

Recover

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.

How Recovery Works

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.

Point-In-Time Recovery

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).

Resetlogs

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.

Restoring to a Different Host

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.


Note:

Be sure to check that media management software is able to restore backups performed on one node, on another node, as some vendors store the node name in the BFS name. Thus, restore from another node is not possible in an automatic fashion.

 

Archivelog Restore

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:

Table 5-1 Sample Database Backup
Job   Datafiles Backed UP   Archivelogs Backed Up  

11

 

None

 

Sequence 289 to 345

 

23

 

data1, data2

 

Sequence 345 to 362

 

26

 

data2, data3

 

Sequence 362 to 410

 

34

 

data4, data5

 

Sequence 410 to 550

 

41

 

data5, data6

 

Sequence 550 to 577

 

45

 

none

 

Sequence 577 to 620

 

53

 

system

 

Sequence 577 to 682

 

By default the archivelogs restored will be:

Table 5-2 Sample Archivelog Restores
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:

Table 5-3 Sample Archivelog Restores with start_lsn
Restore Of   Start_lsn   Archivelogs Restored Up  

data1, data2

 

300

 

289 to 682

 

data1, data2

 

500

 

345 to 682

 

data1, data2

 

650

 

345 to 682

 

data1, data2

 

690

 

ERROR

 

data5

 

300

 

289 to 682

 

data5

 

500

 

410 to 682

 

data5

 

630

 

550 to 682

 

data6

 

300

 

289 to 682

 

data6

 

500

 

410 to 682

 

data6

 

630

 

550 to 682

 

database

 

100

 

289 to 682

 

database

 

300

 

289 to 682

 

database

 

500

 

345 to 682

 

database

 

630

 

345 to 682

 

database

 

690

 

ERROR

 


Note:

When restoring only the archivelogs, start_lsn must be specified.

 

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:

Table 5-4 Sample Database Restore with end_lsn
Restore Of   end_lsn   Archivelogs Restored Up  

data1, data2

 

650

 

345 to 682

 

data1, data2

 

580

 

345 to 620

 

data1, data2

 

560

 

345 to 577

 

data1, data2

 

405

 

345 to 550

 

data4

 

650

 

410 to 682

 

data4

 

580

 

410 to 620

 

data4

 

560

 

410 to 577

 

data4

 

405

 

410 to 577

 

data5

 

650

 

550 to 682

 

data5

 

560

 

550 to 682

 

data5

 

100

 

550 to 682

 

database

 

650

 

345 to 682

 

database

 

580

 

345 to 682

 

database

 

560

 

345 to 682

 

database

 

405

 

345 to 682

 

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.

Remap

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.

Performing Restore and Recovery

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.

  1. Verify that you have the necessary permissions to restore and recover the target database. Recovery requires the user to connect as SYSDBA, or as INTERNAL with the user being in the OSDBA group.

Additional Information:

Some media management software requires special operating system privileges for the user(s) performing restores. Check your media management software documentation.

 

  1. Verify that the EBU Catalog database is up and running.
  2. Create a command script to perform the type of operation you want. See Appendix A, "Command Script Syntax" for a full description of the command scripts.
  3. Take the tablespaces or datafiles to be restored offline, or simply shut down the database with SHUTDOWN NORMAL. The database must be down if restore database or restore database consistent are performed.
  4. Invoke the restore job. Enter the Enterprise Backup Utility command at the prompt:
    $ ebu script_name
    
    

Restoring a Database Subset

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.

  1. Prepare a restore script and enter values for the tablespace specifier for the system, rollback segment, and any other tablespaces you need.
  2. Run EBU to restore datafiles belonging to the specified tablespaces.
  3. After the files are restored, mount the database and take all other datafiles that have not been restored offline. This indicates to the Oracle7 Server that these files are not needed for recovery.
  4. Perform recovery on those parts of the database you have restored.
  5. Open the database. At this point, you should be able to export the needed table or make the partial database available for limited use.


    Note:

    If you are restoring because you accidentally dropped a table or tablespace, Oracle Corporation strongly suggests you restore the database to a new location, so that you do not overlay the existing database files with the backup set. If this process is not clear, please contact Oracle Worldwide Customer Support Services at the number given in the preface of this guide before proceeding.

     

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.

 

How Restore Works

Once invoked with a command script, the Enterprise Backup Utility performs the following steps:

  1. The utility verifies that the database to be restored is registered in the backup catalog and that configuration information exists.
  2. The utility builds a job list of files to be restored.
  3. The utility locates the files from the backup job(s):
  4. The utility issues a read request to the media management software, specifying the required files. The media management software identifies the corresponding physical media devices and instructs the operator, through its own user interface, to mount them.
  5. The utility restores data from media devices to damaged files, or to any other location specified in the remap specifier.

Table 5-5 Simplified Database
Tablespace A   Tablespace B  

datafile a1

 

datafile b1

 

datafile a2

 

datafile b2

 

datafile a3

 

datafile b3

 

datafile a4

 

 
Examples

Use Table 5-6, "Sample Database Backup Scheme" with the table of database restores Table 5-7, "Sample Database Restores" .

Table 5-6 Sample Database Backup Scheme
Date/Time
Job Initiated
 
Job ID   Begin / End
Log Sequence
Number
 
Backup
Command
 
Files Backed Up  

07/12/1996 17:01

 

81
82

 

1200 / 1200
1201 / 1202

 

offline database +
online archivelog
archdelete

 

a1, a2, a3, a4, b1, b2, b3 +
archived log files LSN 1130 - 1202*

 

07/13/1996 17:01

 

83

 

1277 / 1278

 

online
tablespace = A
dbfile = b1
archdelete

 

a1, a2, a3, a4, b1
archived log files LSN 1202 - 1278

 

07/14/1996 17:01

 

84

 

1347 / 1350

 

online
dbfile = a1, a2, b3
archdelete

 

a1, a2, b3
archived log files LSN 1278 - 1350

 

07/15/1996 17:01

 

85

 

1412 / 1414

 

online database
archdelete

 

a1, a2, a3, a4, b1, b2, b3
archived log files LSN 1350 - 1414

 

07/16/1996 17:01

 

86

 

1490 / 1492

 

online
tablespace = B
dbfile = a1, a2

 

a1, a2, b1, b2, b3
archived log files LSN 1414 - 1492

 

07/17/1996 17:01

 

87

 

1565 / 1566

 

online
dbfile = a3, a4, b1
archdelete

 

a3, a4, b1
archived log files LSN 1414 - 1566

 

07/18/1996 17:01

 

88

 

1656 / 1658

 

online
tablespace = A
archdelete

 

a1, a2, a3, a4
archived log files LSN 1566 - 1658

 

07/19/1996 17:01

 

89

 

1723 / 1723

 

offline database

 

a1, a2, a3, a4, b1, b2, b3

 

07/20/1996 17:01

 

90

 

1797 / 1801

 

online
tablespace = A
archdelete

 

a1, a2, a3, a4
archived log files LSN 1658 - 1801

 

07/21/1996 17:01

 

91

 

1886 / 1888

 

online
dbfile = a1, b1, b2
archdelete

 

a1, b1, b2
archived log files LSN 1801 - 1888

 

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.

Table 5-7 Sample Database Restores
Restore Command   Files Restored   From Job  

restore database consistent

 

a1, a2, a3, a4, b1, b2, b3

 

89

 

 

no archived log files restored

 

--

 

restore database consistent
archivelog start_lsn = 1799

 

a1, a2, a3, a4, b1, b2, b3

 

89

 

 

archived logs: LSN 1658-1888

 

90, 91

 

restore
tablespace = B

 

b1, b2

 

91

 

 

b3

 

89

 

 

archived logs: LSN 1658-1888

 

90, 91

 

restore database

 

a1, b1, b2

 

91

 

 

a2, a3, a4

 

90

 

 

b3

 

89

 

 

archived logs: LSN 1658-1888

 

90, 91

 

restore database
to = 07/14/1996 23:00

 

a1, a2, b3

 

84

 

 

a3, a4, b1

 

83

 

 

b2

 

81

 

 

archived logs LSN: 1130-1414

 

82-85

 

restore database consistent
to = 07/16/1996 15:00

 

a1, a2, a3, a4, b1, b2, b3

 

81

 

 

archived logs LSN: 1130-1492

 

82-86

 

restore
to = 07/15/1996 02:30
dbfile = a1, a2, a4, b2

 

a1, a2

 

84

 

 

a4

 

83

 

 

b2

 

81

 

 

archived logs LSN: 1130-1888

 

82-88,
90, 91

 

Additional Information:

See Appendix B, "Command Script Examples", for sample EBU command scripts.

 

Sample restore Scripts

Following are four sample restore scripts:

Example 5-1 Restore Database Consistent with Recovery to the Most Recent Point in Time

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.

  • recovery from loss of an online redo log file
  • OPEN RESETLOGS
  • guidelines for database backup and creating a backup strategy
  • complete description of the backup and recovery process
 




Go to previous file in sequence Go to next file in sequence
Prev Next
Oracle
Copyright © 1997 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index