Recovering A Database: Requiring Recovery

4623-6 ch22.f.
qc 1/28/00 12:33 PM Page 565
Recovering a
database
22
C H A P T E R
✦ ✦ ✦ ✦
In This Chapter
T 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 can’t restore from it. A lot of issues are involved in
Requiring recovery
Restoring a
NOARCHIVELOG
restoring an Oracle database. You have to know the difference
mode database
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 Requiring media
understand media recovery. In this chapter, you learn how recovery
to restore lost datafiles, and then how to recover the database
to the point in time at which the files were lost. Recovering from a
lost datafile
Terminating an
Requiring Recovery incomplete recovery
Rarely would you ever lose an entire Oracle database. It’s far Restoring a database
more common to have a single drive go bad, causing you to from an export
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 you’re 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 it’s 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
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 566
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.
Restored datafile is
current as of this point
in time.
Datafile
Log File
Both archived and online

Log File redo log files are used to
Time
bring the datafile up to

date with changes made
since the backup was
Log File taken. This process is
known as recovery.
Log File
Datafile
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, it’s 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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 567
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 you’ve 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. All rights reserved.
SQL> connect internal

Connected.
SQL> shutdown abort
ORACLE instance shut down.
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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 568
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 that’s a day older than another, that’s not consistent. Since you have no
archived logs, you won’t 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 you’ve 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 won’t be able to find them, and you’ll
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-
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 569
sensitive, depends on the operating system. UNIX systems typically have case-
sensitive 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 can’t rename a file when the
database is open because the files would then be in use. You can’t 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 doesn’t 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
you’re restoring the database, it’s 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
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 570
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:

‘E:\ORACLE\ORADATA\JONATHAN\SYSTEM01.DBF’ TO ‘’;
‘E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF’ TO ‘’;
‘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 don’t 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 you’re 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, it’s not easy to do,
especially if you don’t 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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 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 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.
#
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 572
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 doesn’t 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 won’t 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 doesn’t involve media recovery, to use the RESETLOGS
option, you will need to use a backup control file. What if you don’t 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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 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. All Rights Reserved.
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
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.

1 file(s) copied.

1 file(s) copied.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 574
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
Database mounted.
SVRMGR> ALTER DATABASE OPEN RESETLOGS;
Statement processed.
Given the requirement that you issue RESETLOGS in conjunction with a backup
control file, it’s 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
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 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 you’re 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 you’ll encounter. If you’re 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 won’t 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 hasn’t 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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 576
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 NAME
------- --------------------------------------------------
SYSTEM E:\ORACLE\ORADATA\JONATHAN\SYSTEM01.DBF
OFFLINE E:\ORACLE\ORADATA\JONATHAN\USERS0199.DBF
ONLINE E:\ORACLE\ORADATA\JONATHAN\RBS01.DBF
In this case, you can see that the USERS0199.DBF file is offline. If the file that you’ve
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 doesn’t require
access to the data in the file that you’ve 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’...];

4623-6 ch22.f.qc 1/28/00 12:33 PM Page 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-00278: log file ‘D:\ORADATA\JONATHAN\ARCH_307.1’ no longer needed for this
recovery
...

recovery
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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 578
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 aren’t 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 you’ve 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, it’s
back online, and the users can work as normal.
Terminating an Incomplete Recovery

When you recover a database, Oracle doesn’t 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 you’ve lost your online redo log files, then you can’t
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, that’s where you have to stop.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 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 doesn’t always represent the ideal way to recover from pro-
cess 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, it’s 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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 580
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 can’t
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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 581
Listing 22-5: Performing an incomplete recovery

SQL> CONNECT INTERNAL
Connected to an idle instance.
SQL> STARTUP MOUNT

Database mounted.
SQL> RECOVER DATABASE UNTIL TIME ‘1999-10-10:08:00:00’
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

AUTO
recovery

recovery

recovery

recovery
Log applied.
Media recovery complete.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 582
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 it’s not something
that you want to be in the position of having to do. It’s 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 can’t restore individual files.
✦ You can’t perform media recovery, so you can’t 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.
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 583
For more information on the Import utility, see Chapter 9, “Using Oracle8i’s Import
Utility.” For more information on the Export utility, see Chapter 8, “Using Oracle8i’s
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, don’t 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 you’ve 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 it’s 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.
✦ ✦ ✦
4623-6 ch22.f.qc 1/28/00 12:33 PM Page 584

Recovering A Database: Requiring Recovery

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Recovering A Database: Requiring Recovery

Загружено:

Авторское право:

Доступные форматы

4623-6 ch22.f.

qc 1/28/00 12:33 PM Page 565

T he ability to recover your database is just as important

If you lose files from a database running in ARCHIVELOG

566 Part V ✦ Backup and Recovery

Both archived and online

bring the datafile up to

Chapter 22 ✦ Recovering a database 567

Restoring a NOARCHIVELOG Mode Database

1. Shut down the database, if the instance is still running.

Shutting down the database

SQL*Plus: Release 8.1.5.0.0 - Production on Mon Oct 11 13:54:06 1999

(c) Copyright 1999 Oracle Corporation. All rights reserved.

SQL> connect internal

Restoring the files

✦ Restore all control files.

568 Part V ✦ Backup and Recovery

Specifying new file locations

ORA-01157: cannot identify/lock data file 2 - see DBWR trace file

Using the ALTER DATABASE RENAME FILE Command

ALTER DATABASE RENAME FILE

Chapter 22 ✦ Recovering a database 569

Listing 22-1: Renaming database files

Total System Global Area 38322124 bytes

570 Part V ✦ Backup and Recovery

ALTER DATABASE RENAME FILE

Re-creating the Control File

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Chapter 22 ✦ Recovering a database 571

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

572 Part V ✦ Backup and Recovery

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

Reopening the database

✦ An incomplete media recovery is performed.

1. Start Server Manager (or SQL*Plus) and mount the database.

Chapter 22 ✦ Recovering a database 573

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

Oracle Server Manager Release 3.1.5.0.0 - Production

(c) Copyright 1997, Oracle Corporation. All Rights Reserved.

Oracle8i Release 8.1.5.0.0 - Production

SVRMGR> CONNECT INTERNAL

E:\Oracle\ORADATA\orcl>copy controlxx.ctl control02.ctl

E:\Oracle\ORADATA\orcl>copy controlxx.ctl control03.ctl

574 Part V ✦ Backup and Recovery

SVRMGR> CONNECT INTERNAL

Requiring Media Recovery

Chapter 22 ✦ Recovering a database 575

Recovering from a Lost Datafile

To restore a lost file, follow these steps:

576 Part V ✦ Backup and Recovery

Taking the lost datafile offline

SQL> SELECT status, name FROM v$datafile;

Restoring the lost datafile

Recovering the lost datafile

RECOVER DATAFILE ‘filename’ [,’filename’...];

Chapter 22 ✦ Recovering a database 577

To recover a datafile, you must connect to the database as either SYSDBA,

SQL> CONNECT SYSTEM/MANAGER AS SYSDBA

Listing 22-4: Recovering a datafile

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 3181229 generated at 10/10/99 10:20:05 needed for thread 1

578 Part V ✦ Backup and Recovery