Oracle7 Enterprise Backup Utility Administrator's Guide

Library

Product

Contents

Index

CHAPTER 5. Restoring and Recovering a Database

Performing Restore and Recovery
Types of Database Restores
How Restore Works
Restoring an Incomplete Database
Recovery

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

The following topics are covered:

Performing Restore and Recovery

Types of Database Restores

How Restore Works

Restoring an Incomplete Database

Recovery

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 operator group status for the person performing restores. Check your media management software documentation.

2. Verify that the backup catalog database is up and running.

restore database

restore database consistent

5. Invoke the restore job. Enter the Enterprise Backup Utility command at either the UNIX shell prompt:

	$ obackup script_name

Sample Restore Scripts

Following are four sample restore scripts:

Example

restore database consistent with recovery to the most recent point in time

restore database consistent 
db_name = "PROD" 
oracle_sid = "PROD" 
parallel = 4   
recover
log = "/opt1/oracle/obackup/log/obkPROD.log"

Example

restore of tablespaces and control file without recovery

restore
db_name = "PROD"
oracle_sid = "PROD" 
control_file 
tablespace = "A","B"

Example

Datafile restore with remap option

restore  
db_name = "PROD" 
oracle_sid = "PROD" 
dbfile = "?/dbs/data1PROD.ora"
remap = "?/dbs/data1PROD.ora" to "/opt1/newhome/data1PROD.ora"

Example

Point-in-time restore database with point-in-time recovery

restore database   
db_name = "PROD" 
oracle_sid = "PROD" 
to = "10/01/1996 12:00" 
recover = "10/01/1996 15:00"

Types of Database Restores

The type of restore you perform depends on two factors: the completeness of the restore and the state to which the database is restored.

Database State

A consistent restore brings the database to a state consistent with itself at a single point-in-time, where only minimal recovery is needed to open the database. (See page 5 - 12 for a detailed description of opening a database after a restore database consistent.) A consistent restore can only be accomplished by restoring all files from a single backup offline database.

Note: Although a consistent restore requires only minimal recovery operation, archived redo logs (if they exist) can be applied to a consistent restore to bring the restored database to a more recent point-in-time.

Unlike a consistent restore, an inconsistent restore may use files from a number of backups, resulting in a restored database that is inconsistent with a single point-in-time. However, an inconsistent restore can still be recovered to a consistent point-in-time by applying archived redo log files.

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.

At times you may wish to restore and recover the database to some other point-in-time - to retrieve a table that was accidentally deleted, for example. This is called a point-in-time recovery. You must restore all database files when performing point in time recovery; you cannot restore only a subset.

If you perform a point-in-time restore and recovery, remember that you will erase all database transactions made since the recovery 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.

This is not the same as using the remap specifier, which is discussed later in this chapter.

Restoring Archived Redo Logs

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, though you can specify that they be restored with control or parameter files.

When restoring archived log files, the utility restores all the files that were backed up, starting with the oldest backup job included in the restore job. The files are restored to the same location from which they were backed up.

Note: If a file with the same name is already present in the destination directory, the utility skips that file and goes on to restoring the next file. The utility does not overwrite an existing archived log file.

If it is necessary to restore archived log files to a directory other than the one from which they came, you can do so by specifying that directory in the archivelog clause of the command script.

No archived log files are restored during a restore consistent, or when the archivelog=none specifier is used.

You can use restore archivelog [start_lsn] to restore the log files associated with an offline backup. Specifying a start_lsn tells the utility to restore all archived logs from all jobs, starting with the job in which the start_lsn is contained and ending with the most current backup.

Remap

The Enterprise Backup Utility supports remapping for parameter files, control files and datafiles. Each type of file remapping requires additional steps to successfully reopen the database:

If you remap the parameter file you must use the pfile specifier with the STARTUP command.

If you remap control file(s) you must update the control file parameter in the RDBMS parameter file.

If you remap datafiles you must perform an ALTER DATABASE RENAME DATAFILE operation.

Additional Information: See the Oracle7 Server Administrator's Guide for more information about the ALTER DATABASE command.

Archived redo logs can also be restored to a different location, but not with the remap specifier. Restore archived redo log files to a new location by specifying the destination in the restore archivelog command script.

Note: The remap and recover specifiers are mutually exclusive. You cannot recover a database you restore with the remap option in release 2.1.

Control File Restore

The Enterprise Backup Utility restores control files for every restore database job and any subset restores using the control_file specifier. If you are using the recover option, EBU determines the correct control file and performs automatic recovery with that file.

The Enterprise Backup Utility restores all copies of the control files. If none of the control files is present, the utility restores the control files as old_name.job_id, where old_name is the original control file name and job_id is the job ID number of the restore job. If no control files are present they are restored with the original file names.

If the control files are on raw devices, as with Oracle Parallel Server, the Enterprise Backup Utility always restores the control files to the $ORACLE_HOME/dbs directory as pseudo_device.job_id, where pseudo_device is the name of the device with slashes (/) replaced by underscores (_).

If you are restoring across different database configurations, be sure to use the control file that most closely reflects the target database structure to which you want to recover. This may not be the current control file if you are performing a point-in-time recovery.

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

EBU uses the most recent backup job(s), unless to is specified. If to is specified, EBU uses the most recent job(s) prior to the to specification.

If restore is database consistent, EBU locates all files in the most recent, single backup offline database job.

If consistent is not specified, EBU uses the most recent copies of database files, possibly spanning multiple backup jobs.

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.

remap

Sample Database Restore Scenarios

Table 5 - 1 represents backups made to the following simplified database:

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

1277 / 1278

online tablespace = A dbfile = b1 archdelete

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

07/14/1996 17:01

1347 / 1350

online dbfile = a1, a2, b3 archdelete

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

07/15/1996 17:01

1412 / 1414

online database archdelete

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

07/16/1996 17:01

1490 / 1492

online tablespace = B dbfile = a1, a2

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

07/17/1996 17:01

1565 / 1566

online dbfile = a3, a4, b1 archdelete

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

07/18/1996 17:01

1656 / 1658

online tablespace = A archdelete

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

07/19/1996 17:01

1723 / 1723

offline database

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

07/20/1996 17:01

1797 / 1801

online tablespace = A archdelete

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

07/21/1996 17:01

1886 / 1888

online dbfile = a1, b1, b2 archdelete

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

* Assumes that the last backup job to include archived redo log files ended with LSN 1130.

Table 5 - 1. Sample Database Backup Scheme

Use Table 5 - 1 with the table of database restores .

Use Table 5 - 2 of database restores with the sample database backup scheme on 5 - 8. Assume that all restores are performed on 7/22/96.

Sample Database Restores

Restore Command

Files Restored

From Job

restore database consistent

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

no archived log files restored

restore database consistent archivelog start_lsn = 1799

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

archived logs: LSN 1658-1888

90, 91

restore tablespace = B

b1, b2

archived logs: LSN 1658-1888

90, 91

restore database

a1, b1, b2

a2, a3, a4

archived logs: LSN 1658-1888

90, 91

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

a1, a2, b3

a3, a4, b1

archived logs LSN: 1130-1414

82-85

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

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

archived logs LSN: 1130-1492

82-86

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

a1, a2

archived logs LSN: 1130-1888

82-88, 90, 91

Table 5 - 2. Sample Database Restores

Additional Information: See Also: Appendix B, "Command Script Examples", for sample EBU command scripts.

Restoring an Incomplete Database

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 bring critical data online, 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 rollback segment tablespace files, and you must restore them in order to open the database successfully.

The following steps help you perform this type of recovery.

restore

tablespace

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.

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 Technical Support 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.

Recovery

Recovery is an option with any type of restore operation. It brings the database to a consistent state, which is required before the database can be opened.

Recovery requires the user to connect to the Server with SYSDBA privileges, or as INTERNAL with the user being in the OSDBA group. See "Authorizing Database Recovery" for more information on the privileges required for recovery.

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.

1. EBU starts and mounts the database, if it was shut down.

2. EBU invokes the Oracle7 recovery feature (using the ALTER DATABASE statement with the RECOVER option). The exact command is written to the log file specified in the command script.

3. If recovery is successful, EBU puts the database back to the state it was in when EBU was invoked. If recovery fails, EBU leaves the database at the point where recovery has failed and aborts. Note: If the recovery is to an earlier point in time, or if control files are restored to their original locations, EBU opens the database with the RESETLOGS option.

Point-in-Time Recovery

The default behavior for EBU recovery is to recover the database to the most recent point in time possible. However, a particular point in time can be specified by putting a time or SCN number in the recover option of the restore command. Point in time recovery is not an option when the database is already open.

The following command script specifies point-in-time recovery:

restore database   
db_name = "PROD" 
oracle_sid = "PROD" 
recover = "10/01/1996 12:00"

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.

Additional Information: See Also: Complete syntax for the recover option is described in Appendix A, "Command Script Syntax".

OPEN RESETLOGS

OPEN RESETLOGS is typically necessary in the following situations:

restoring entire database and performing incomplete recovery (that is, not recovering to the current point in time)

opening database after a consistent restore (that is, a restore from a single, offline backup)

loss of active online redo logs

Opening a Database After Incomplete Recovery

Incomplete recovery is recovering the database to a point in time earlier than the present (complete recovery recovers the database to the current point in time, including applying current online redo logs).

To perform incomplete recovery, you must restore the entire database to a time before the desired recovery point, then recover the database until the desired point in time or sequence change number (SCN).

You must open the database with the RESETLOGS option following an incomplete recovery in order to avoid confusion with the previously created log files that cover the period later than the recovery point.

EBU lets the user combine the restore, recovery, and OPEN RESETLOGS into a single command script. The following script, for instance, would perform incomplete recovery and open the database with the RESETLOGS option:

restore database
oracle_sid= "PROD"
db_name= "PROD"
to= "01/23/1996 12:00:00"
recover= "01/23/1996 15:30:00"

Opening a Database After a Consistent Restore

Even though restore database consistent creates a database consistent with a point in time, some recovery is still required. If the recovery is to be point-in-time or to the current time, EBU can perform the recovery. If redo logs are unavailable, you must perform "minimal" recovery. This 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> CANCEL;
SVRMGRL> ALTER DATABASE OPEN RESETLOGS;

Recovering from Loss of Online Log File

If you do not mirror your online redo logs and a media failure occurs, you may be able to work around the problem by dropping the log, then backing up the database to ensure that the lost log information will not be needed in the future. You will be able to drop the log file as long as it is not the active log file.

If dropping the corrupted log file is not possible, perform a RESETLOGS operation to recreate the log files.

Following an OPEN RESETLOGS

If you are running an Oracle7 Server older than release 7.3.3, be sure to back up the database after performing an OPEN RESETLOGS, as the RESETLOGS operation makes all prior backups unusable for rolling forward past the RESETLOGS point. With Oracle7 release 7.3.3 and higher, backups from before a RESETLOGS operation can be used. See the Oracle7 release 7.3.3. Server README file for detailed information.

Regardless of what Server release you are running, you must update information in the backup catalog following an OPEN RESETLOGS.

Notes on the Recovery Option

During recovery, detailed error messages from both the Oracle7 Server and the Enterprise Backup Utility are written to the EBU log file. Use the log file to diagnose and fix problems if recovery fails.

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.

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

Prev Next

Library

Product

Contents

Index