Recovering a database

he ability to recover your database is just as important as the ability to back it up. After all, a backup is no good if you cant restore from it. A lot of issues are involved in restoring an Oracle database. You have to know the difference between restoring a database that runs in NOARCHIVELOG mode and one that runs in ARCHIVELOG mode. You need to know how to handle the redo log files, and you need to understand media recovery. In this chapter, you learn how to restore lost datafiles, and then how to recover the database to the point in time at which the files were lost.

22
C H A P T E R

In This Chapter

Requiring recovery Restoring a NOARCHIVELOG mode database Requiring media recovery Recovering from a lost datafile Terminating an incomplete recovery Restoring a database from an export

Requiring Recovery
Rarely would you ever lose an entire Oracle database. Its far more common to have a single drive go bad, causing you to lose just the files that are on that drive. How you recover from such a loss depends largely on whether your database is running in ARCHIVELOG mode. If youre not running in ARCHIVELOG mode and you lose a database file, your only option is to restore the entire database from the most recent backup. Any changes made since the backup was performed are lost. In addition, you must shut down the entire database while it is being restored. Because its usually not acceptable in a production setting to lose data or to shut down the database for an extended period, most Oracle production databases are run in ARCHIVELOG mode. If you lose files from a database running in ARCHIVELOG mode, you recover from that loss by restoring the most recent versions of those files from tape and then performing media

566

Part V Backup and Recovery

recovery to bring those files up to date. You can do all this while the database is running, and without any committed changes being lost. In the context of Oracle, the term recovery has a very specific meaning. Recovery refers to the process of reading redo log entries from archived and online redo log files and applying those changes to a datafile to bring it up to date. Figure 22-1 illustrates this.

Datafile

Restored datafile is current as of this point in time.

Log File

Log File

Log File

Both archived and online redo log files are used to bring the datafile up to date with changes made since the backup was taken. This process is known as recovery.

Time
Datafile

Log File

After the recovery process is complete, the datafile is up-to-date.

Figure 22-1: The recovery process

When you restore a file from a backup, the file represents the state of the database at the time the file was backed up, not when it was lost. Usually, you want to recover all the changes that were made during the interim between the time the file was backed up and the time it was lost. Because all changes are written to the log files, its possible to read those log files and apply the changes again to the file that you restored. This is the core process on which all Oracle recovery operations are based.

Chapter 22 Recovering a database

567

Restoring a NOARCHIVELOG Mode Database

Restoring a database running in NOARCHIVELOG mode represents the simplest possible case. Since no archived log files exist, no media recovery is possible. The entire operation essentially turns into an exercise in copying files. The process for restoring a NOARCHIVELOG mode database consists of the following steps: 1. Shut down the database, if the instance is still running. 2. Restore the control files and the datafiles from the most recent backup. If you have a backup control file, made with the ALTER DATABASE BACKUP CONTROLFILE command, use that. It will make step 4 easier. 3. Specify whether youve moved any of the files. 4. Reopen the database.

Shutting down the database

If your database is open when you lose the files, some or all of the background processes are likely to still be running, and the instance probably still has the remaining files open. Before restoring anything, make certain that all processes associated with the instance are stopped. You can do this with the SHUTDOWN ABORT command, as shown in this example:
$sqlplus /nolog SQL*Plus: Release 8.1.5.0.0 - Production on Mon Oct 11 13:54:06 1999 (c) Copyright 1999 Oracle Corporation. SQL> connect internal Connected. SQL> shutdown abort ORACLE instance shut down. All rights reserved.

With the instance completely shut down, you can proceed to restore the files.

Restoring the files

When you restore files for a database running in noarchivelog mode, you need to do the following: Restore all control files. Restore all datafiles. Do not restore the redo log files.

568

Part V Backup and Recovery

The reason that you have to restore all the control files and datafiles is that Oracle requires these files to be consistent with respect to each other. If you have one datafile thats a day older than another, thats not consistent. Since you have no archived logs, you wont be able to apply changes from those logs to make them consistent either. Your only option is to restore all the files.
Note

NOARCHIVELOG mode is suitable only in situations where you can afford to lose all the changes that youve made since the most recent backup. Development and test databases are often run in NOARCHIVELOG mode. Read-only databases may also be run in NOARCHIVELOG mode.

Specifying new file locations

If the loss of a disk forces you to restore files to different locations than they were in originally, you need to tell Oracle about that. Otherwise, when you try to restart the database, Oracle will look for the files, it wont be able to find them, and youll see an error message like the following:
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file ORA-01110: data file 2: E:\ORACLE\ORADATA\JONATHAN\USERS01.DBF

Oracle stores the names and locations of all database files in the control file. The reason you get an error like this is that Oracle is trying to open a file named in the control file, and that file cannot be found. You can use two methods to tell Oracle that you have moved a database file. One approach is to issue an ALTER DATABASE RENAME FILE command. That command allows you to change the file names and locations recorded in the database control file. Another approach to the same task is to re-create the entire control file. Issuing ALTER DATABASE RENAME FILE commands is probably the safer approach. Creating a new control file allows you to rename all your files at once, but if you make a mistake, you could cause more problems, and you could lose data.

Using the ALTER DATABASE RENAME FILE Command

The ALTER DATABASE RENAME FILE command allows you to change the name and location of a file as recorded in the database control file. It accepts two parameters. One parameter is the original path and file name. The other parameter is the new value that you want Oracle to use in its place. The syntax looks like this:
ALTER DATABASE RENAME FILE original_filename TO new_filename;

Replace original_filename with the full path and file name that Oracle is currently using. Replace new_filename with the full path and file name representing where the file is currently located. The format for these strings, and whether they are case-

Chapter 22 Recovering a database

569

sensitive, depends on the operating system. UNIX systems typically have casesensitive file names. Windows NT systems do not. To rename a database file, the database must be mounted but not open. It must be mounted because the changes need to be recorded in the control file. Oracle opens the control file when you mount the database. You cant rename a file when the database is open because the files would then be in use. You cant rename files that are currently open. Listing 22-1 shows the ALTER DATABASE RENAME FILE command being used to specify that you have renamed USERS01.DBF to USERS0199.DBF.

Listing 22-1: Renaming database files

SQL> CONNECT INTERNAL Connected to an idle instance. SQL> STARTUP MOUNT ORACLE instance started. Total System Global Area 38322124 bytes Fixed Size 65484 bytes Variable Size 21405696 bytes Database Buffers 16777216 bytes Redo Buffers 73728 bytes Database mounted. SQL> ALTER DATABASE RENAME FILE 2 E:\ORACLE\ORADATA\JONATHAN\USERS01.DBF TO 3 E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF; Database altered.

Note that this command changes the name and location of a file only as recorded in the database control file. It doesnt rename the file at the operating-system level, nor does it physically move the file to the new location. You must perform both of those tasks yourself. The ALTER DATABASE RENAME FILE command does a search and replace, taking the original file name that you provided and replacing it with the new file name. To issue the ALTER DATABASE RENAME FILE command, you need to know what the original file names in your database are. How can you find that out? If your database is operational, you can query the V$DATAFILE view for this information. However, if youre restoring the database, its not going to be operational, so consider generating a list of file names in advance. You may want to periodically run a SQL script such as the following:
SPOOL datafile_list SELECT name FROM v$datafile; SPOOL OFF

570

Part V Backup and Recovery

You can even run a slightly more complex script periodically that generates the ALTER DATABASE RENAME FILE commands for you. For example:
SET PAGESIZE 0 SPOOL rename_file_commands.sql SELECT ALTER DATABASE RENAME FILE || || name || TO ; FROM v$datafile; SPOOL OFF

The result of executing this script will be a file containing an ALTER DATABASE RENAME FILE command for every datafile in your database. The contents will look like the following:
ALTER DATABASE RENAME FILE E:\ORACLE\ORADATA\JONATHAN\SYSTEM01.DBF TO ; ALTER DATABASE RENAME FILE E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF TO ; ALTER DATABASE RENAME FILE E:\ORACLE\ORADATA\JONATHAN\RBS01.DBF TO ;

You could easily edit this file, type in new file names, and then execute it. If all else fails and you dont have a list of original file names to work from, you can always attempt to open the database, get the file name from the error message, and then rename that file. You would have to repeat this process once for each file that you move.

Re-creating the Control File

If youre moving all or most of your datafiles at once, you may find it easier to re-create the control file. As part of that process, you can provide new names and locations for all database files. Re-creating the control file is a good idea only if you have previously been in the habit of generating control file backups using the following command:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

This command actually generates a trace file containing the necessary CREATE CONTROLFILE command, together with other necessary commands. Although you could write the CREATE CONTROLFILE command yourself, its not easy to do, especially if you dont have access to the database anymore. You also risk losing data if you get it wrong, so let Oracle generate it for you. Listing 22-2 provides an example of a script generated when you back up the control file to trace.

Chapter 22 Recovering a database

571

Listing 22-2: Trace file contents for a control file backup

STARTUP NOMOUNT CREATE CONTROLFILE REUSE DATABASE JONATHAN NORESETLOGS ARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 2 MAXDATAFILES 32 MAXINSTANCES 16 MAXLOGHISTORY 1630 LOGFILE GROUP 1 E:\ORACLE\ORADATA\JONATHAN\REDO04.LOG SIZE 1M, GROUP 2 E:\ORACLE\ORADATA\JONATHAN\REDO03.LOG SIZE 1M, GROUP 3 E:\ORACLE\ORADATA\JONATHAN\REDO02.LOG SIZE 1M, GROUP 4 E:\ORACLE\ORADATA\JONATHAN\REDO01.LOG SIZE 1M DATAFILE E:\ORACLE\ORADATA\JONATHAN\SYSTEM01.DBF, E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF, E:\ORACLE\ORADATA\JONATHAN\RBS01.DBF, E:\ORACLE\ORADATA\JONATHAN\TEMP01.DBF, E:\ORACLE\ORADATA\JONATHAN\OEMREP01.DBF, E:\ORACLE\ORADATA\JONATHAN\INDX01.DBF, E:\ORACLE\ORADATA\JONATHAN\USERS02.DBF, E:\ORACLE\ORADATA\JONATHAN\CHECKUP_HISTORY.DBF, E:\ORACLE\ORADATA\JONATHAN\LOCAL_UNIFORM.DBF, E:\ORACLE\ORADATA\JONATHAN\LOCAL_AUTOALLOCATE.DBF, E:\ORACLE\ORADATA\JONATHAN\LOCAL_UNIFORM_2.DBF, E:\ORACLE\ORADATA\JONATHAN\ITEM_DATA.DBF, E:\ORACLE\ORADATA\JONATHAN\ITEM_PHOTOS.DBF, E:\ORACLE\ORADATA\JONATHAN\TEST_MIN_EXTENT_SIZE.DBF, E:\ORACLE\ORADATA\JONATHAN\TEST_MIN_EXTENT_SIZE_2.DBF, E:\ORACLE\ORADATA\JONATHAN\TEST_5.DBF, E:\ORACLE\ORADATA\JONATHAN\TEST_5B.DBF, E:\ORACLE\ORADATA\JONATHAN\TEST_LARGE.DBF, E:\ORACLE\ORADATA\JONATHAN\TEST_LARGEB.DBF CHARACTER SET WE8ISO8859P1 ; # Recovery is required if any of the datafiles are restored backups, # or if the last shutdown was not normal or immediate. RECOVER DATABASE # Database can now be opened normally. ALTER DATABASE OPEN; # No tempfile entries found to add. #

572

Part V Backup and Recovery

This script is meant to be executed from Server Manager. If you decide to execute it from SQL*Plus, you will need to change the pound signs (#) to a double dash (--), or delete the comment lines entirely, because SQL*Plus doesnt recognize pound signs as comment characters. You will also want to edit the trace file and remove all the messages that Oracle places before and after these commands.
Note

You must be connected as SYSDBA or as INTERNAL to create a control file.

Also before you execute the script, be sure to edit it and change all the file names to reflect the new locations and names of the database files. If your original control files still exist, leave in the keyword REUSE, and the new files will be created over the top of the originals. Otherwise, remove the keyword REUSE to create totally new files. If you are restoring the database from a backup, you should delete the RECOVER DATABASE and ALTER DATABASE OPEN commands and open the database yourself.

Reopening the database

After restoring the datafiles and rebuilding the control file if necessary, you should open the database using the RESETLOGS option. This resets the log files to ensure that there wont be any conflicts between new entries and those left over from the previous incarnation of the database.
RESETLOGS is an option of the ALTER DATABASE OPEN command. One issue that you may run into when you try to use it is that Oracle will allow the option to be used only in two cases:

An incomplete media recovery is performed. A backup control file is used to start the database. Backup control files are those created with the ALTER DATABASE BACKUP CONTROLFILE command (but not using the TO TRACE option). Because restoring from an offline backup doesnt involve media recovery, to use the RESETLOGS option, you will need to use a backup control file. What if you dont have a backup control file? Fortunately, you can make one. Just follow these steps: 1. Start Server Manager (or SQL*Plus) and mount the database. 2. Use the ALTER DATABASE BACKUP CONTROLFILE command to make a backup control file. 3. Shut down the database. 4. Copy the backup control file over the original control files that you have restored.

Chapter 22 Recovering a database

573

With the backup control file in place, you are now ready to open the database using the RESETLOGS option.
Note

This information applies only to Oracle8 and Oracle8i. Prior releases of Oracle did not allow you to use RESETLOGS on backup control files.

Listing 22-3 shows backup control files being created on a Windows NT server.

Listing 22-3: Replacing control files with a backup control file

E:\Oracle>svrmgrl Oracle Server Manager Release 3.1.5.0.0 - Production (c) Copyright 1997, Oracle Corporation. Oracle8i Release 8.1.5.0.0 - Production With the Partitioning and Java options PL/SQL Release 8.1.5.0.0 - Production SVRMGR> CONNECT INTERNAL Connected. SVRMGR> STARTUP MOUNT ORACLE instance started. Total System Global Area 34451404 bytes Fixed Size 65484 bytes Variable Size 17469440 bytes Database Buffers 16384000 bytes Redo Buffers 532480 bytes Database mounted. SVRMGR> ALTER DATABASE BACKUP CONTROLFILE TO CONTROLXX.CTL; Statement processed. SVRMGR> SVRMGR> EXIT Server Manager complete. E:\Oracle\ORADATA\orcl>copy controlxx.ctl control01.ctl 1 file(s) copied. E:\Oracle\ORADATA\orcl>copy controlxx.ctl control02.ctl 1 file(s) copied. E:\Oracle\ORADATA\orcl>copy controlxx.ctl control03.ctl 1 file(s) copied. All Rights Reserved.

574

Part V Backup and Recovery

The end result of this cumbersome process is that you replace your database control files with backup control files. You can now go back into Server Manager, start up the instance, and open the database using the RESETLOGS option. Consider this example:
SVRMGR> CONNECT INTERNAL Connected. SVRMGR> STARTUP MOUNT ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted. SVRMGR> ALTER DATABASE OPEN RESETLOGS; Statement processed.

34451404 65484 17469440 16384000 532480

bytes bytes bytes bytes bytes

Given the requirement that you issue RESETLOGS in conjunction with a backup control file, its probably best if you routinely make backup control files as part of your backup process. Then you can use those backup control files when restoring the database, instead of having to go through the rather cumbersome process shown here.

Requiring Media Recovery

Media recovery is the process of reading changes from the redo log files and reapplying those changes to one or more datafiles that have been restored from a backup. The end result is that the datafiles are brought up to date and they reflect all changes made since the backup. The need to do media recovery is the reason you have a redo log in the first place. The online redo log files allow Oracle to perform media recovery to recover from a system crash or the sudden failure of a database instance. Whenever you commit a transaction, Oracle makes certain that the changes from that transaction are written to the redo log files. The changes may not be written to the datafiles until later. If the system crashes before the changes can be written to the datafiles, Oracle will detect the crash when you restart the database, read the lost changes from the redo log files, and apply them to the datafiles. Media recovery, when performed in response to a crash like this, is referred to as crash recovery. You know that Oracle cycles through the set of redo log files for a database, writing to each file in turn. Throughout all this, Oracle ensures that redo log entries are not overwritten until their changes have been written to the datafiles. This ensures that crash recovery can always be performed. Imagine, though, if redo log entries were

Chapter 22 Recovering a database

575

kept indefinitely. You could use such a log to replay all the changes that took place over a period of days, weeks, or even months. Not only could you recover from a crash, but you could also recover from losing a file due to drive failure. This is where archived redo logs come into play. When you run a database in ARCHIVELOG mode, Oracle makes a copy of each redo log file as it is filled. These copies, known as archived log files, together with any online redo log files that have not yet been copied, form a continuous record of all changes made to the database. If you lose a datafile and are forced to restore it from a backup, the information in the archived log files can be used to reapply all the changes to that file that were made since the backup took place. The net effect is that you suffer zero data loss. How long archived log files are retained is up to you. In fact, if youre not using RMAN and an automated scheduling tool such as what Enterprise Manager provides, you will need to write your own scripts to purge old archived log files. As long as you have all the archived log files generated since the most recent full backup of a database file, you will always be able to recover that file.

Recovering from a Lost Datafile

The loss of a datafile, usually caused by the failure of a disk, is probably the most common recovery scenario that youll encounter. If youre running in archivelog mode, you can restore just the files that you lost, recover them to the way they were at the point of failure, and do all this while the rest of the database is up and running.
Note

If the lost file is part of the SYSTEM tablespace, then you wont be able to keep the database open while it is being restored.

To restore a lost file, follow these steps: 1. Take the datafile offline if Oracle hasnt already done that for you. 2. Restore the file from the most recent backup. 3. Recover the file. 4. Bring the file back online. The process is usually quite painless, especially if you have the necessary archived log files still on disk and in the directory pointed to by the ARCHIVE_LOG_DEST parameter.

576

Part V Backup and Recovery

Taking the lost datafile offline

Chances are, if a drive failure caused you to lose a datafile, Oracle will have already taken the file offline. Verify this, however, before proceeding further. To check the status of files in your database, issue the query shown in this example:
SQL> SELECT status, name FROM v$datafile; STATUS ------SYSTEM OFFLINE ONLINE NAME -------------------------------------------------E:\ORACLE\ORADATA\JONATHAN\SYSTEM01.DBF E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF E:\ORACLE\ORADATA\JONATHAN\RBS01.DBF

In this case, you can see that the USERS0199.DBF file is offline. If the file that youve lost is not yet offline, you can take it offline by issuing this command:
ALTER DATABASE DATAFILE filename OFFLINE;

Replace filename with the full path and name of the file, as reported by the v$datafile view. With the file safely offline, you can proceed to restore and recover it. Users of the database will still be able to do work that doesnt require access to the data in the file that youve taken offline.

Restoring the lost datafile

Before you can recover the file, you need to restore it. You should, of course, restore it from the most recent backup that you have available. If a drive failure forces you into restoring the file to a new location, you need to issue an ALTER DATABASE RENAME FILE command to record the new location in the database control file. See the section Using the ALTER DATABASE RENAME FILE command earlier in this chapter for details on doing this.

Recovering the lost datafile

After restoring the file, you need to recover it. You can use the SQL*Plus (or Server Manager) RECOVER command for this purpose. If you need to recover multiple files, you can recover them all at once by issuing this command:
RECOVER DATABASE

Using RECOVER DATABASE causes Oracle to check all the files and recover any that need recovering. A more surgical approach would be to use RECOVER DATAFILE and list the files that you specifically want to recover. The syntax for doing that is as follows:
RECOVER DATAFILE filename [,filename...];

Chapter 22 Recovering a database

577

Replace filename with the path and name of a file that you want to recover. You can list multiple files in the command. Separate the file names with commas. To recover a datafile, you must connect to the database as either SYSDBA, SYSOPER, or INTERNAL. For example:
SQL> CONNECT SYSTEM/MANAGER AS SYSDBA Connected.

Once connected, you can issue the RECOVER command. As Oracle proceeds to recover the datafile, it will prompt you each time it needs to access an archived log file. You can respond to each prompt by pressing the Enter key, or you can use the keyword AUTO to specify that Oracle proceed without prompting you all the time. Listing 22-4 shows the use of RECOVER DATAFILE to bring the USERS0199.DBF file up to date.

Listing 22-4: Recovering a datafile

SQL> RECOVER DATAFILE E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF; ORA-00279: change 3080219 generated at 10/07/99 19:20:50 needed for thread 1 ORA-00289: suggestion : D:\ORADATA\JONATHAN\ARCH_307.1 ORA-00280: change 3080219 for thread 1 is in sequence #307

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} AUTO ORA-00279: change 3100373 generated at 10/08/99 08:56:17 needed for thread 1 ORA-00289: suggestion : D:\ORADATA\JONATHAN\ARCH_308.1 ORA-00280: change 3100373 for thread 1 is in sequence #308 ORA-00278: log file D:\ORADATA\JONATHAN\ARCH_307.1 no longer needed for this recovery ... ORA-00279: ORA-00289: ORA-00280: ORA-00278: recovery change 3181229 generated at 10/10/99 10:20:05 needed for thread 1 suggestion : D:\ORADATA\JONATHAN\ARCH_312.1 change 3181229 for thread 1 is in sequence #312 log file D:\ORADATA\JONATHAN\ARCH_311.1 no longer needed for this

Log applied. Media recovery complete.

In this example, the keyword AUTO is used as the response to the first prompt. This works because all the needed archived log files are still online, and they are still in the directory pointed to by the ARCHIVE_LOG_DEST parameter.

578

Part V Backup and Recovery

If the needed archived log files are on disk but not where Oracle expects them to be, you can respond to the prompt by supplying the correct path and file name for the archived log file that Oracle is seeking. If the needed archived log files arent on disk but are instead on a backup medium such as a tape, you need to restore them to disk before you can recover the datafile. This is why many DBAs keep archived log files online long enough to cover the period since the most recent full backup.

Bringing the recovered file back online

The last task, after youve recovered the file, is to bring it back online. You can do that with the ALTER DATABASE command, as shown in this example:
SQL> ALTER DATABASE 2 DATAFILE E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF 3 ONLINE; Database altered.

Now you can sit back, relax, and have a coffee. The file has been recovered, its back online, and the users can work as normal.

Terminating an Incomplete Recovery

When you recover a database, Oracle doesnt require you to recover all changes up to the moment when the database was lost. Usually you will want to do so, but sometimes you may want (or need) to terminate the recovery process earlier. When you do that, you are said to have performed an incomplete recovery. You might perform an incomplete recovery for both voluntary and involuntary reasons. The involuntary reasons include the following: Loss of an online redo log file. The last part of the recovery process reads changes from the online redo log files and applies those changes to the files being recovered. If youve lost your online redo log files, then you cant recover the changes that were recorded in those files. Loss of an archived log file. If you lose an archived log file and you have no backups of that file, then you will be able to recover changes only up to the point in time represented by that file. These two points illustrate the need to carefully protect your online redo logs and to back up your archived log files. The recovery process always proceeds from the oldest change forward, through the most recent change. If you get to a point where you are missing a file, thats where you have to stop.

Chapter 22 Recovering a database

579

Note

The first point, that of losing online redo log files, is why Oracle recommends against backing up those files. If you get flustered in a recovery situation, and unthinkingly restore redo log files from a backup, you will have totally and utterly lost your ability to recover up to the point of failure.

You might voluntarily want to perform an incomplete recovery if either of the following applies: A processing error results in lost or damaged data and you want to rerun the process. A user error results in important data being deleted. Both of these scenarios are really the same. Either way, something went wrong at a certain point in time, and data was corrupted or lost. You might, for example, have a billing process that runs each night. If a major error occurs, you may want to be able to rerun the entire billing process again. Incomplete recovery allows you to do that. You restore the entire database from the last backup and recover it up to the moment just prior to when the billing process was run. Then you can correct the source of the error and rerun the process.
Note

Incomplete recovery doesnt always represent the ideal way to recover from process failures. If online transactions are taking place at the same time that a batch process is running, those transactions will be lost if you perform an incomplete recovery to rerun the batch process.

After performing an incomplete recovery, its important to immediately perform another full backup of your entire database. After performing an incomplete recovery, you need to open your database with the RESETLOGS option. Doing that effectively prevents you from using the existing archive and redo logs to recover again.

Understanding the different types of incomplete recovery

When you voluntarily perform an incomplete recovery, you can approach it in three ways: You can recover up to a specific point in time. You can recover up to a specific change. You can recover one log file at a time until you decide to manually cancel the recovery operation. You specify how you want to approach incomplete recovery when you issue the
RECOVERY command.

580

Part V Backup and Recovery

Incomplete recovery is sometimes referred to as point-in-time recovery because it results in a database that reflects its state at some past point in time. You cant perform incomplete recovery on datafiles and tablespaces. To perform an incomplete recovery, you need to restore all the datafiles and roll everything forward to the desired point in time.
Note

Tablespace point-in-time recovery (TSPTR) is a complex process, and it involves cloning all or part of your database. It also requires you to manually deal with dependencies between objects in the tablespace that you are restoring and objects in the rest of that database.

Using the UNTIL clause

You use the UNTIL clause of the RECOVERY command to specify an incomplete recovery. The syntax for the UNTIL clause looks like this:
RECOVER DATABASE [UNTIL CANCEL] [UNTIL CHANGE scn] [UNTIL TIME datetime] rest_of_command;

The following list describes the elements of this syntax: UNTIL CANCEL Specifies a cancel-based recovery. UNTIL CHANGE Specifies recovery up to, but not including, a specific system change number (SCN). scn Specifies the change number at which to stop the recovery process. This change number should be one higher than the one you want to recover through. In other words, to recover through change 919, specify UNTIL CHANGE 920. UNTIL TIME specifies recovery up to a certain date and time. datetime Specifies the date and time through which you want to recover the database. The format to use is YYYY-MM-DD:HH24:MI:SS. For example, to recover the database to where it was at 11:35 pm on December 29, 1988, use the string 1988-12-29:23:35:00. After performing an incomplete recovery, you must open the database using the RESETLOGS option. This defines a new incarnation of the database and tells Oracle that the data currently in the online redo log files is no longer needed for recovery. Except for issuing the actual RECOVER command, the process for performing an incomplete recovery is the same as for a complete recovery. Restore the files, in this case, all of them; make sure the required archived log files are available; and issue the command. Listing 22-5 shows a database being restored to its state as of 8:00 am on October 10, 1999.

Chapter 22 Recovering a database

581

Listing 22-5: Performing an incomplete recovery

SQL> CONNECT INTERNAL Connected to an idle instance. SQL> STARTUP MOUNT ORACLE instance started. Total System Global Area 38322124 bytes Fixed Size 65484 bytes Variable Size 21405696 bytes Database Buffers 16777216 bytes Redo Buffers 73728 bytes Database mounted. SQL> RECOVER DATABASE UNTIL TIME 1999-10-10:08:00:00 ORA-00279: change 3080219 generated at 10/07/99 19:20:50 needed for thread 1 ORA-00289: suggestion : D:\ORADATA\JONATHAN\ARCH_307.1 ORA-00280: change 3080219 for thread 1 is in sequence #307

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} AUTO ORA-00279: change 3100373 generated at 10/08/99 08:56:17 needed for thread 1 ORA-00289: suggestion : D:\ORADATA\JONATHAN\ARCH_308.1 ORA-00280: change 3100373 for thread 1 is in sequence #308 ORA-00278: log file D:\ORADATA\JONATHAN\ARCH_307.1 no longer needed for this recovery

ORA-00279: ORA-00289: ORA-00280: ORA-00278: recovery

change 3120735 generated at 10/08/99 20:56:26 needed for thread 1 suggestion : D:\ORADATA\JONATHAN\ARCH_309.1 change 3120735 for thread 1 is in sequence #309 log file D:\ORADATA\JONATHAN\ARCH_308.1 no longer needed for this

ORA-00279: ORA-00289: ORA-00280: ORA-00278: recovery

change 3140919 generated at 10/09/99 23:19:46 needed for thread 1 suggestion : D:\ORADATA\JONATHAN\ARCH_310.1 change 3140919 for thread 1 is in sequence #310 log file D:\ORADATA\JONATHAN\ARCH_309.1 no longer needed for this

ORA-00279: ORA-00289: ORA-00280: ORA-00278: recovery

change 3161072 generated at 10/09/99 23:38:49 needed for thread 1 suggestion : D:\ORADATA\JONATHAN\ARCH_311.1 change 3161072 for thread 1 is in sequence #311 log file D:\ORADATA\JONATHAN\ARCH_310.1 no longer needed for this

Log applied. Media recovery complete.

582

Part V Backup and Recovery

The database has now been brought back to the same state it was in at 8:00 am on October 10, 1999. All that remains is to open the database using the RESETLOGS option, as shown in this example:
SQL> ALTER DATABASE OPEN RESETLOGS; Database altered.

The database is now ready for use.

Restoring a Database from an Export

You can use an export file to restore a database, although its not something that you want to be in the position of having to do. Its much easier to restore a database from a file system backup. Restoring from an export has several disadvantages: The restore process takes a long time. You cant restore individual files. You cant perform media recovery, so you cant recover changes made after the export was taken.
Note

In addition to these disadvantages, if your database is a significant size to begin with, it may not be feasible to generate complete database exports in the first place.

In spite of all this, if all you have to work with is an export file, you can follow these steps to use an export file to recover your database to the way it was when the export was performed. 1. Remove all traces of the database that you are trying to recover. Delete all datafiles, log files, control files, and so forth. 2. Create a new database from scratch. Create only the SYSTEM tablespace and some rollback segments. Run the CATALOG.SQL and CATPROC.SQL scripts. 3. Import into the new database using the export file from the old database as the source. Specify IGNORE=Y on the import command line. While importing, you may encounter some errors as the Import utility attempts to create objects owned by SYSTEM that are already present in the new database. The IGNORE=Y option tells the Import utility to ignore these errors. If everything else works well, the Import utility should create all your tablespaces, create all your schema objects, and load those with data.

Chapter 22 Recovering a database

583

For more information on the Import utility, see Chapter 9, Using Oracle8is Import Utility. For more information on the Export utility, see Chapter 8, Using Oracle8is Export Utility.

Summary
In this chapter, you learned: If your database is running in noarchivelog mode and you lose a file, your only recourse is to restore the entire database from the most recent backup. You will lose all changes made since the backup. By running your database in archivelog mode, you enable yourself to restore a file and recover all changes made up until the moment that the file was lost. Production databases should almost always be run in archivelog mode. When you restore a noarchivelog mode database, dont restore the redo log files. Instead, use the RESETLOGS option when reopening the database. If you have to restore a file to a new location as the result of a bad disk, have Oracle record the new location in the database control file. You can do this by issuing an ALTER DATABASE RENAME FILE command, or you can re-create the control file completely. To recover a file that youve restored, issue the RECOVER DATABASE command. For the recovery to be complete, all archived log files generated since the backup must be available, and you must have all online redo log files available as well. The last few changes to be applied will always come from the online redo log files, so its important to preserve these. Crash recovery is the recovery process that Oracle employs after a system crash. Data is read from the redo log files and applied to the database files to restore any lost changes. Media recovery provides the same process, but the term media is used when you restore files from a backup and you recover using archived log files. Incomplete recovery is the process of recovering a database to the way it was at some point in time in the past. After performing incomplete recovery, use the RESETLOGS option when opening the database.