Tài liệu ORACLE8i- P12 pptx

CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
434
Shut down and remount the database. This is required to put the
database in ARCHIVELOG mode. Once the database is shut down, proceed to
mount it again. After you remount it, the ARCH process should be running.
Put the database in ARCHIVELOG mode and open it. At this
point, you can put the database in ARCHIVELOG mode by using the ALTER
DATABASE ARCHIVELOG command. Then open the database by issuing the
ALTER DATABASE OPEN command.
Next, you will want to test the configuration of the ARCH process. Why? Well, if
you incorrectly set up ARCH so that it is writing to a directory that doesn’t exist,
guess what will happen soon: The database will come to a screeching halt. This hap-
pens because Oracle will not allow you to overwrite the online redo log file until
ARCH can write out the archived redo logs successfully. If you are trying to archive to
a destination that doesn’t exist, these attempts to create the archived redo logs will
fail. To test your configuration, issue an ALTER DATABASE SWITCH LOGFILE com-
mand. Then check the archived log destinations a few moments later. You should see
an archived redo log file created in those directories. If these files are created, you are
in good shape.
After you put the database in ARCHIVELOG mode and test your configuration, you
should proceed to perform a hot backup as quickly as possible. Then you will be able
to recover your database using the archived redo logs, if necessary.
Considering Online Redo Log Groups
In NOARCHIVELOG mode, there is only one basic rule that Oracle follows in relation
to redo log switches: Before an online redo log can be used, the changes represented
within the redo it contains from its last use must have been written to the database
datafiles. Thus, Oracle will not reuse a redo log if its previous contents have not been
written to the database datafiles. This rule is in place to facilitate crash and instance
recovery of the database.
In ARCHIVELOG mode, things get a bit more complicated. When a log switch
occurs, Oracle will first update the control file, indicating that the redo log needs to

be archived. It will then signal the ARCH process, indicating that it has a redo log to
process. The ARCH process will wake up (assuming it’s not processing another online
redo log file already) and begin to copy that online redo log to the archived redo log
directory defined in the init.ora file (by the ARCHIVE_LOG_DEST_n parameter).
During the ARCH copy process, Oracle will proceed to the next available online redo
log and continue database activity as normal.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
435
If Oracle proceeds through the remaining redo log groups and returns to the redo
log group you are archiving, it will not reuse that online redo log until the archiving
process has completed successfully for that online redo log file. If Oracle cannot use
that online redo log, it will look for another available online redo log. If no online
redo log is available, then the Oracle database will be suspended until the ARCH
process has completed its moves. Once ARCH completes the move of the online redo
log, it will update the control file, indicating that the online redo log has been
archived. At that point, LGWR will be able to open and use the online redo log.
The log switch process in ARCHIVELOG can pose a problem if you don’t have
enough online redo log files (and/or if they are too small), because Oracle may not be
able to write out the archived redo logs fast enough to keep up with the redo creation
within the online redo logs. Thus, you may find that your database activity becomes
suspended quite often—not a condition that users or managers desire.
Something else to consider is the number of archive log destinations you will have.
Adding a destination will increase the time it takes to archive your online redo logs. If
you add a network destination, that will further erode the performance of the archiv-
ing process. There are several possible solutions to this problem:
• Add enough log file groups of sufficient size to reduce contention with the
archiving process.

• Reduce the number of archiving destinations.
• Carefully tune the I/O. Try to separate the archived logs onto their own disks to
reduce the I/O contention that ARCH might incur.
Backup and Recovery in NOARCHIVELOG Mode
With the database in NOARCHIVELOG mode, the online redo logs are overwritten
without regard to recoverability of the database. Thus, the only backup option is a
cold backup. A cold backup of a database is a backup that takes place while the data-
base is shut down. Thus, during the period that the cold backup takes place, users will
have no access to the database or the data within it.
When you perform a cold backup in NOARCHIVELOG mode, you simply back up
the entire physical structure of the database. A cold backup in NOARCHIVELOG
mode includes backups of the following:
• All database datafiles
• All database control files
BACKUP AND RECOVERY IN NOARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
436
• All online database redo logs
• Other required database files such as init.ora
The following sections describe the procedures for backing up and recovering a
database in NOARCHIVE mode.
Performing Cold Backups in NOARCHIVELOG Mode

To perform a cold backup, you simply identify the database files to be backed up, shut
down the database, and back up the physical files to the backup medium. Then you
can start the database again.
You might wonder why you need to shut down the database for a cold backup if
you can ensure that nobody will make any changes to the database while it is up. As
explained in Chapter 5, one method that Oracle uses to determine that the database
is in a consistent state is by virtue of a fuzzy file flag maintained in each database
datafile. If the fuzzy datafile flag is set when the database starts, the database will con-
sider the datafile to be fuzzy. Thus, if you recover a datafile that was backed up while
the database was running, even if the database had no activity, that backup is not
usable for recovery purposes. This is because the fuzzy flag will have been set in the
open position. There are some ways to force the database open in these cases (as you
will learn later in this chapter), but these methods are not recommended.
Identifying the Files to Back Up
To locate the database datafiles, control files, and online redo logs to back up, you can
use some data dictionary queries. Use the DBA_DATA_FILES data dictionary view to
find the database datafiles, as in this example:
SELECT tablespace_name, file_name, file_id
FROM dba_data_files
ORDER BY tablespace_name, file_name;
TABLESPACE_NAME FILE_NAME FILE_ID

IDX D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF 4
RBS D:\ORACLE\ORADATA\RECOVER\RECOVER_RBS_01.DBF 2
SYSTEM D:\ORACLE\ORADATA\RECOVER\SYSTEM01.DBF 1
TEMP D:\ORACLE\ORADATA\RECOVER\RECOVER_TEMP_01.DBF 5
USERS D:\ORACLE\ORADATA\RECOVER\RECOVER_USERS_01.DBF 3
To find the database control files, query the V$CONTROL_FILE data dictionary view:
SQL> SELECT * FROM v$controlfile;
C

opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
437
STATUS NAME

D:\ORACLE\ORADATA\RECOVER\CONTROL01.CTL
D:\ORACLE\ORADATA\RECOVER\CONTROL02.CTL
D:\ORACLE\ORADATA\RECOVER\CONTROL03.CTL
Finally, use a query to the V$LOGFILE data dictionary view to locate the database
online redo log files:
SQL> SELECT * FROM v$logfile;
GROUP# STATUS MEMBER

1 D:\ORACLE\ORADATA\RECOVER\REDO01.LOG
2 STALE D:\ORACLE\ORADATA\RECOVER\REDO02.LOG
3 D:\ORACLE\ORADATA\RECOVER\REDO03.LOG
Running the Backup
After you’ve identified the database files, you’re ready to perform a cold backup. To do
so, you must first shut down the database. When shutting down the database for a
cold backup, it is strongly recommended that you use either the normal SHUTDOWN
command or the SHUTDOWN IMMEDIATE command. This will cause DBWn to flush
all dirty buffers to the database datafiles. As long as you have issued either a SHUT-
DOWN or SHUTDOWN IMMEDIATE command, you will not need to recover (or back
up) the online redo log files for the database.
Now, you can proceed to back up the physical database files that you identified. To
shorten the time of the overall outage required to back up the database, you may wish
to back up the datafiles to disk, open the database, and then back up the other files to
slower backup medium, such as tape. It is often advisable to include in your final
backup image a copy of a backup control file (aside from the backup of the current

control file). A backup control file is a backup of the control file that can be used to
recover the control file in the event that it is lost. We will discuss the creation of a
backup control file later in this chapter, in the “Control File Backups” section. When
you’re finished backing up the database, you can open the database again. Listing 10.1
shows an example or running a cold backup in NOARCHIVELOG mode.
NOTE All of the examples in this chapter were done on Windows NT. The principles are
the same, regardless of the operating system. Only the operating system commands (such
as copy, cp, tar, or tape backup) are different.
BACKUP AND RECOVERY IN NOARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
438
Listing 10.1: Performing a Cold Backup in NOARCHIVELOG Mode
D:\ORACLE\ORA816\DATABASE>sqlplus “sys/robert as sysdba”
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
Now we are going to back up the database. Note that we have a
pretty poorly set up database here, because everything is on one
drive. We did that mostly just to keep the example easy and
to save page space.
SQL> HOST MKDIR d:\backup_oracle

SQL> HOST COPY d:\oracle\oradata\recover\*.* d:\backup_oracle\*.*
d:\oracle\oradata\recover\CONTROL01.CTL
d:\oracle\oradata\recover\CONTROL02.CTL
d:\oracle\oradata\recover\CONTROL03.CTL
d:\oracle\oradata\recover\REDO01.LOG
d:\oracle\oradata\recover\REDO02.LOG
d:\oracle\oradata\recover\REDO03.LOG
d:\oracle\oradata\recover\SYSTEM01.DBF
d:\oracle\oradata\recover\RECOVER_RBS_01.DBF
d:\oracle\oradata\recover\RECOVER_USERS_01.DBF
d:\oracle\oradata\recover\RECOVER_TEMP_01.DBF
d:\oracle\oradata\recover\afiedt.buf
d:\oracle\oradata\recover\recover_idx_01.dbf.backup
d:\oracle\oradata\recover\RECOVER_IDX_01.DBF
13 file(s) copied.
Backup is complete, restart the database.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
Database mounted.
Database opened.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
439

NOTE Listing 10.1 and many other examples start SQL*Plus or connect to the database
using the ”/ as sysdba” or “sys/robert as sysdba” string. This is done for two reasons. First,
Oracle will be dropping support for CONNECT INTERNAL in Oracle9i, so we are trying to
prepare for that eventuality. Second, with Oracle release 8.1.6, we are forced to put the
username and password on the command line. This is due to a bug in 8.1.6 that was fixed
in 8.1.7. If you are running 8.1.7, you can use “system as sysdba” with SQL*Plus, and then
respond to the password prompt that follows.
Recovering Cold Backups in NOARCHIVELOG Mode
Recovering a database from a cold backup taken in NOARCHIVELOG mode is fairly
simple. Issue a SHUTDOWN ABORT command on the database instance to make sure
that all the database processes are stopped and all operating system locks on files that
might remain are released. Then recover all of the database files to their original loca-
tions, if possible. If this is not possible, record the new location of the database files
for later use. If any of the files were recovered to a different location, you will need to
reset the location as follows:
• If the control files were recovered to a different location, edit the database param-
eter file to reflect the new location for the control files. Change any other direc-
tory paths that might have changed as a result of the recovery process.
• If the database datafiles or the redo logs were recovered to another location, you
will need to mount the database by issuing a STARTUP MOUNT command.
Issue the ALTER DATABASE RENAME FILE command for each datafile that was
recovered to another location.
• If the online redo logs were recovered to another location, issue the ALTER
DATABASE RENAME FILE command to reset the location of the database online
redo logs.
When all of the database files have been recovered, issue the STARTUP command,
and the database should open normally. Listing 10.2 provides an example of recover-
ing a database that was backed up in NOARCHIVELOG mode. (Note that due to book
page line-length restrictions, some code is broken into multiple lines.)
Listing 10.2: Performing a Cold Backup Recovery in

NOARCHIVELOG Mode
D:\ORACLE\oradata\RECOVER>sqlplus “sys/robert as sysdba”
SQL> STARTUP
BACKUP AND RECOVERY IN NOARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
440
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: ‘D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF’
SQL> SHUTDOWN ABORT
ORACLE instance shut down.
Recover the database from the backup we made earlier.
SQL> HOST COPY d:\backup_oracle\*.*
d:\oracle\oradata\recover\recover_idx_01.dbf
d:\backup_oracle\CONTROL01.CTL
d:\backup_oracle\CONTROL02.CTL

d:\backup_oracle\CONTROL03.CTL
d:\backup_oracle\REDO01.LOG
d:\backup_oracle\REDO02.LOG
d:\backup_oracle\REDO03.LOG
d:\backup_oracle\SYSTEM01.DBF
d:\backup_oracle\RECOVER_RBS_01.DBF
d:\backup_oracle\RECOVER_USERS_01.DBF
d:\backup_oracle\RECOVER_TEMP_01.DBF
d:\backup_oracle\afiedt.buf
d:\backup_oracle\recover_idx_01.dbf.backup
d:\backup_oracle\RECOVER_IDX_01.DBF
1 file(s) copied.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
Database mounted.
Database opened.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
441
If you were not able to recover the online redo logs from the backup medium, you
can still recover the database in many cases. First, if you were able to recover at least one
member of each redo log group, you can create a copy of that online redo log, naming it
with the name of the missing online redo log. If none of the online redo logs are avail-

able, as long as you shut down your database normally (or with the IMMEDIATE
option), all you need to do is open the database with the following command:
ALTER DATABASE OPEN RESETLOGS;
We will discuss the RESETLOGS command in more detail later in this chapter, in
the “RESETLOGS and Recovery” section. For now, suffice it to say that issuing this
command will cause the database to create new redo logs. Also, if the control file is
missing, you can recover using the backup control file, as described in the “Control
File Backups” section later in this chapter.
Backups in ARCHIVELOG Mode
The principle difference between NOARCHIVELOG mode and ARCHIVELOG mode is
the creation of archived redo logs, and associated with that, the ability to back up the
database while it is still running and recover the database to point of failure, or some
point prior to that failure. It is this functionality and reliability that make Oracle the
most popular database in the world.
Performing Cold Backups in ARCHIVELOG Mode
Cold backups in ARCHIVELOG mode are much the same as those in NOARCHIVELOG
mode, except that you don’t need to back up the online redo logs or the control files.
It is best not to back up online redo logs during backups in ARCHIVELOG mode
(unless you are not saving the archived redo logs), because you do not want to acciden-
tally recover them over existing online redo logs during a recovery. Also, overwriting
the existing control file will hamper your ability to recover the database to the point of
failure. Instead, create a backup control file, as discussed later in this chapter in the
“Control File Backups” section.
The steps for performing a cold backup in ARCHIVELOG mode are as follows:
1. Identify the database datafiles to be backed up.
2. Shut down the database.
3. Back up the physical datafiles to the backup medium.
4. Start the database.
BACKUPS IN ARCHIVELOG MODE
Oracle Database

Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
442
5. Back up the existing archived redo log. (This is not really a requirement at this
point if you shut down the database normally, but it’s good practice.)
6. Back up the archived redo logs on a regular basis.
All of these steps, except the last two, are the same as those for a cold backup in
NOARCHIVE mode. Steps 5 and 6 pertain to backing up archived redo logs, which is
covered in the next section.
Backing Up Archived Redo Logs
When you are doing any backup in ARCHIVELOG mode, it is assumed (and in the
case of hot backups, required) that the archived redo logs created during the time of
the backup are themselves backed up. It is the backup of these logs (and subsequent
backups of newly created archived redo logs) that allows an Oracle database in
ARCHIVELOG mode to be recovered.
When recovering from hot backups, all of the archived redo logs generated during
the hot backup are required during the recovery process. In addition, if you wish to
recover the database to a point beyond the point of recovery, you will need all of the
generated archived redo logs as well. As explained earlier in this chapter, the location
of the archived redo logs is defined in the init.ora file using the LOG_ARCHIVE_
DEST_n parameter. You can query the V$ARCHIVE_DEST data dictionary view to
determine the current location of the archived log directories, as follows:
SELECT destination FROM v$archive_dest;
DESTINATION

D:\Oracle\oradata\Recover\archive
NOTE The V$ARCHIVE_DEST data dictionary view contains a row for each destination,
even if the destination is not defined.
How often should archived redo logs be backed up? The answer to the question is
really another question: How much data loss can you tolerate? Since the archived
redo logs are typically stored on the same system as the database that generated them,
there is some risk of loss of these files. When configuring your database, you should
give careful consideration to using alternative storage locations, such as network
appliances or other options, to reduce the risk of datafile loss.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
443
Also keep in mind the performance implications of your archived redo log configu-
rations. The more archived redo log destinations you configure, the longer the ARCH
process will take to copy each archived redo log. If you are copying these over the net-
work (to a standby database in Net8), this may even further impact the overall perfor-
mance of the ARCH process. Remember that Oracle will not be able to reuse an online
redo log until all required copies to archive locations are complete.
NOTE Besides being useful for recovery, archived redo logs can also be run through the
Oracle8i utility called LogMiner, which we will cover in Chapter 14. LogMiner allows you to
review the archived redo logs for security audits and other purposes. Archived redo logs
are also used to keep standby databases current, as explained in Chapter 26, which dis-
cusses high-availability options.
Performing Hot Backups in ARCHIVELOG Mode
Now we reach the big time—hot backups in ARCHIVELOG mode. When you imple-
ment hot backups in your database, you enter a whole new world of recovery options.
When doing hot backups, you simply do not back up control files and online redo

logs. What you do is put tablespaces in hot backup mode. These tablespaces are asso-
ciated with the datafiles that you have chosen to back up.
When you put tablespaces in hot backup mode, Oracle generates block-level redo to
the online redo logs, as opposed to the normal atomic redo records that are created
when the tablespaces are not in hot backup mode. This means that all redo generated
for the tablespace is generated as an image of the entire block, rather than as just redo
records. Thus, redo generation is substantially increased during hot backup operations
(however, this is not true with RMAN hot backups, which are discussed in Chapter 13).
Block images are recorded in the redo logs to avoid problems with operating sys-
tem block splitting. Since Oracle continues to write to database datafiles during hot
backups, there is a possibility that the backed up image of the datafile will contain
fractured blocks. This is because the operating system write batch size may be smaller
than the block size of the database, so the backup image of a given datafile may con-
tain a block that is of two different versions. The generation of block images in the
online redo logs solves this problem by allowing the block to be restored during the
backup process.
BACKUPS IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
444
TIP Because of the increased level of redo generation during hot backups, as well as
the general performance impacts associated with moving large amounts of data (such as
copying database datafiles to tape), you should try to schedule database backups during

low-usage hours.
Performing hot backups is not a complicated task. Here are the basic steps:
1. Identify the database datafiles to be backed up. You also need to identify the
associated tablespace names.
2. Determine the current log sequence number.
3. For each tablespace that is associated with the datafiles to be backed up, put that
tablespace in hot backup mode.
4. Back up the physical database datafiles that are associated with the tablespace
put in hot backup mode.
5. As each tablespace backup is complete (or you have completed backups for all
the datafiles of a given tablespace), take that tablespace out of hot backup mode.
6. Once the backups are complete and all tablespaces are out of hot backup mode,
force a log switch.
7. Back up all of the archived redo logs.
8. Create backup control files.
9. Back up the archived redo logs on a regular basis.
Let’s look at these steps in a bit more detail.
Identifying the Database Files and Associated Tablespaces
Since you need to put the tablespaces of the database datafiles in hot backup mode,
you need to know not only the location of the database datafiles, but also the table-
spaces they are associated with. You can find this information via a query to the
DBA_DATA_FILES data dictionary view (as shown in Listing 10.3, a bit later in this
chapter).
Hot backups allow you to selectively back up different tablespaces at different
times. Therefore, if you wanted to back up the DATA tablespace tonight, and the
INDEX tablespace tomorrow night, you could—although good arguments could be
made not to do this. In fact, you don’t even need to back up every datafile of a given
tablespace. Again, this isn’t good practice, because it becomes a lot more difficult to
manage backups created this way and can lead to situations where the database may
be unrecoverable.

C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
445
For example, suppose that you backed up one datafile belonging to the DATA
tablespace two weeks ago and the other two datafiles a week ago. Now suppose that
your database crashes, and you lose all three datafiles. You would need to recover the
one datafile from two weeks ago and the two other datafiles from a week ago. Also,
you would need to recover the archived redo logs to apply recovery. If you couldn’t
get the one datafile off the tape from two weeks ago, you would be in bad shape and
would probably be unable to recover the database. Thus, it is normally good practice
to back up all associated datafiles with a given tablespace during a backup.
Determining the Current Log Sequence Number
Before starting the backup, you should determine the current log sequence number.
You will need to make sure that you back up this log sequence number, along with all
logs generated during the backup, after the backup has completed. Use the ARCHIVE
LOG LIST command to get this information (see Listing 10.3).
Putting Tablespaces in Hot Backup Mode
The hot backup bit is set in the database datafiles when you issue the ALTER TABLE-
SPACE BEGIN BACKUP command:
ALTER TABLESPACE idx BEGIN BACKUP;
This command places the tablespace in hot backup mode, flipping the fuzzy backup bit.
If you want to determine if a database datafile is in hot backup mode, you can
query the V$BACKUP view. The STATUS column in this view will indicate the value
ACTIVE if the tablespace is in hot backup mode (see Listing 10.3).
If the database should crash or you issue a SHUTDOWN ABORT command while a
tablespace is in hot backup mode, you will need to reset the datafiles associated with
the tablespace so that they are no longer in hot backup mode. To do this, you use the
ALTER DATABASE DATAFILE filename END BACKUP command. Here is an example:

SQL> ALTER TABLESPACE idx BEGIN BACKUP;
Tablespace altered.
SQL> SHUTDOWN ABORT
ORACLE instance shut down.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
BACKUPS IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
446
Database mounted.
ORA-01113: file 4 needs media recovery
ORA-01110: datafile 4: ‘D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF’
SQL> ALTER DATABASE DATAFILE 4 END BACKUP;
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
This example uses the file identifier (4) rather than the file path and name in the

END BACKUP command. Alternatively, you could use the filename, like this:
ALTER DATABASE DATAFILE ‘D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF’ END
BACKUP
Backing Up the Datafiles
You can use any standard copy facility (cp, copy, tar, gzip, and so on) to copy the
database files to the backup media that you wish to use. As mentioned earlier, it’s
probably a good idea to back up all of the associated datafiles, but this is not required.
All that is required for recovery is the presence of all the associated datafiles (backed
up with the database in hot backup mode or the current database datafiles) and the
archived redo logs to make those files consistent.
Completing the Backup
Once you have completed backing up the datafiles for a given tablespace, take that
tablespace out of hot backup mode, using the ALTER TABLESPACE END BACKUP
command (see Listing 10.3).
Your next step is to force a redo log switch. This is because you will need all of the
redo generated during the hot backup (and since the database is open to users during
a hot backup, you will be generating redo) to recover the database datafiles you have
backed up. After forcing a log switch, back up all archived redo logs generated during
the backup, as well as the archived redo log generated by the log switch.
To force the redo log switch after you have taken each tablespace out of hot backup
mode, issue the ALTER SYSTEM SWITCH LOGFILE command. You can determine
which log sequence numbers you need to make sure are backed up by issuing the
ARCHIVE LOG LIST command from either Server Manager or SQL*Plus when con-
nected as INTERNAL. Run this command both before the hot backups (finding the
current log sequence number) and before issuing the ALTER SYSTEM SWITCH LOG-
FILE command (again finding the current log sequence number). This will tell you the
low and high log sequence numbers that you must back up in order to recover the
hot backup you just made.
C
opyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
447
Listing 10.3 provides an example of a complete hot backup. In this example, the
database files reside in d:\oracle\oradata\recover. These datafiles are backed up to
d:\oracle_backup\hot, and the archived redo logs are backed up to d:\oracle_
backup\hot\archive.
Listing 10.3: Running a Hot Backup
First, get the tablespace names and filenames and locations.
SQL> SELECT tablespace_name, file_name, file_id
FROM dba_data_files
ORDER BY tablespace_name, file_name;
TABLESPACE_NAME FILE_NAME FILE_ID

IDX D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF 4
RBS D:\ORACLE\ORADATA\RECOVER\RECOVER_RBS_01.DBF 2
SYSTEM D:\ORACLE\ORADATA\RECOVER\SYSTEM01.DBF 1
TEMP D:\ORACLE\ORADATA\RECOVER\RECOVER_TEMP_01.DBF 5
USERS D:\ORACLE\ORADATA\RECOVER\RECOVER_USERS_01.DBF 3
Get the current log sequence number
SQL> ARCHIVE LOG LIST
Database log mode Archive Mode
Automatic archival Enabled
Archive destination D:\Oracle\oradata\Recover\archive
Oldest online log sequence 216
Next log sequence to archive 218
Current log sequence 218
Now, put the tablespaces in hot backup mode.
Note that if we wanted to just back up a specific
tablespace, we would execute this statement only

for that tablespace.
SQL> ALTER TABLESPACE idx BEGIN BACKUP;
Tablespace altered.
SQL> ALTER TABLESPACE rbs BEGIN BACKUP;
Tablespace altered.
SQL> ALTER TABLESPACE system BEGIN BACKUP;
Tablespace altered.
SQL> ALTER TABLESPACE temp BEGIN BACKUP;
Tablespace altered.
BACKUPS IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
448
SQL> ALTER TABLESPACE users BEGIN BACKUP;
Tablespace altered.
Check the status of all the database datafiles.
SQL> SELECT * FROM v$backup;
FILE# STATUS CHANGE# TIME

1 ACTIVE 176503 28-APR-01
2 ACTIVE 176502 28-APR-01
3 ACTIVE 176505 28-APR-01
4 ACTIVE 176501 28-APR-01

5 ACTIVE 176504 28-APR-01
Now, back up the database datafiles. Notice that we do not back up
the online redo logs or the control file.
SQL> HOST COPY d:\oracle\oradata\recover\*.dbf d:\oracle_backup\hot\*.*
d:\oracle\oradata\recover\SYSTEM01.DBF
d:\oracle\oradata\recover\RECOVER_RBS_01.DBF
d:\oracle\oradata\recover\RECOVER_USERS_01.DBF
d:\oracle\oradata\recover\RECOVER_TEMP_01.DBF
d:\oracle\oradata\recover\RECOVER_IDX_01.DBF
5 file(s) copied.
Now, end the backup status of the tablespaces.
SQL> ALTER TABLESPACE idx END BACKUP;
Tablespace altered.
SQL> ALTER TABLESPACE rbs END BACKUP;
Tablespace altered.
SQL> ALTER TABLESPACE system END BACKUP;
Tablespace altered.
SQL> ALTER TABLESPACE temp END BACKUP;
Tablespace altered.
SQL> ALTER TABLESPACE users END BACKUP;
Tablespace altered.
Check the status of all the database datafiles.
They should all now show not active.
SQL> SELECT * FROM v$backup;
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
449
FILE# STATUS CHANGE# TIME

1 NOT ACTIVE 176503 28-APR-01
2 NOT ACTIVE 176502 28-APR-01
3 NOT ACTIVE 176505 28-APR-01
4 NOT ACTIVE 176501 28-APR-01
5 NOT ACTIVE 176504 28-APR-01
Find out what the active online redo log sequence number
is. We need to make sure this one gets backed up. We want
to make sure we back up from log sequence number 218 to 219.
SQL> ARCHIVE LOG LIST;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination D:\Oracle\oradata\Recover\archive
Oldest online log sequence 217
Next log sequence to archive 219
Current log sequence 219
Now, force a log switch.
SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.
Now, back up the archived redo logs generated during the backup.
Optionally, you can delete the archived redo logs once they are
backed up to save space.
SQL> HOST COPY d:\oracle\oradata\recover\archive\*.*
d:\oracle_backup\hot\archive\*.*
d:\oracle\oradata\recover\archive\RECOVERT001S00215.ARC
d:\oracle\oradata\recover\archive\RECOVERT001S00216.ARC
d:\oracle\oradata\recover\archive\RECOVERT001S00217.ARC
d:\oracle\oradata\recover\archive\RECOVERT001S00218.ARC
d:\oracle\oradata\recover\archive\RECOVERT001S00219.ARC
3 file(s) copied.

The backup is complete. The database is recoverable.
BACKUPS IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
450
Ongoing Backups of Archived Redo Logs
The Achilles heel of hot backups is their dependence on archived redo logs for recov-
ery. You simply must have all of the logs in order to recover the database completely.
If you have a gap in the redo log sequence numbers, recovery to the point of the crash
will not be possible (although you should be able to do an incomplete recovery,
unless you don’t have all the archived redo log files generated during a backup).
Because the archived redo logs are so important, you need to have a good backup
strategy to make sure that they are protected. In some environments, disk space to
store archived redo logs is limited as well. Again, a good backup strategy in such a sit-
uation is critical. A full archive log directory will eventually cause the database to
stall, because ARCH will not be able to process archived redo logs, and therefore it will
not be able to release online redo logs for the database to use.
Recoveries in ARCHIVELOG Mode
One of the huge advantages of using ARCHIVELOG mode is that it offers a wealth of
recovery options. You can perform complete or incomplete recoveries. Complete
recoveries include recovery of datafiles, tablespaces, or the entire database. The three
kinds of incomplete recoveries that Oracle provides are time-based, change-based, and
cancel-based.

Preparing for Recovery
You generally know when you have a problem—the users start calling and your moni-
toring system starts sending out panic e-mail messages. It’s time for you to don your
cape and earn your keep. When presented with a recovery situation, you first need to
figure out what the problem is. This is where understanding the internals of the Oracle
database comes in handy. Sometimes that experience and understanding can make the
difference between a 30-second outage and having the system down for days.
When presented with a problem, you need to proceed through a mental checklist.
Start your checklist with the easiest things to fix and the most likely things to go
wrong, and work your way down to the unlikely. Has the whole database crashed? Are
the users getting any error messages? Has the database really crashed or is it just
stalled? Check the alert log for any messages that might be helpful. Have the users
send you any messages they may be getting (though applications frequently trap
these messages, so the users never send them).
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
451
TIP When presented with a database that will not come up (say, after a power outage
or an aborted shutdown) and says it needs media recovery, your first response should
always be to issue a RECOVER DATABASE command. Just because the database says it
needs media recovery doesn’t mean you need to recover database datafiles.
When your database is troubled, the V$ views are frequently of great help. Table 10.3
lists the V$ views that can be handy to use during backup and recovery operations.
Generally, many of these views become available as the database startup process pro-
ceeds. For example, when the database is mounted, you have access to the V$DATAFILE
view. This view provides you with a wealth of information on the status of the database
datafiles. This same view will let you know if a database datafile has gone AWOL, by
indicating a status of OFFLINE for that datafile. Also, mismatches between the control

file and the FILE$ data dictionary table will be reported in this view. If you see a file
named MISSINGxxx in this view, that’s the problem. We will talk more about this later
in this chapter in our discussion on control file recovery issues.
TABLE 10.3: V$ VIEWS FOR BACKUP AND RECOVERY
View Name Description
V$DATAFILE Provides datafile information from the control file.
V$ARCHIVE_DEST Provides various information on the archive log
destinations.
V$ARCHIVED_LOG Provides information on archived redo logs.
V$ARCHIVE_PROCESSES Provides information on the ARCH processes currently
running on the database.
V$BACKUP Provides status information on database datafiles in hot
backup mode.
V$DATABASE Provides various database information, such as if it is in
ARCHIVELOG mode or NOARCHIVELOG mode.
V$INSTANCE_RECOVERY Provides various information on the different systems
used by Oracle to speed up recovery. These different
recovery processes are influenced by parameters such as
fast_start_io, log_checkpoint_timeout, and log_check-
point_interval.
V$LOG Contains various information on the current redo logs
that comes from the control file.
RECOVERIES IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
452
TABLE 10.3: V$ VIEWS FOR BACKUP AND RECOVERY (CONTINUED)
View Name Description
V$LOGFILE Contains information on the current redo logs.
V$LOG_HISTORY Contains information on the archived redo logs gener-
ated by the database.
V$RECOVER_FILE Contains information on the recovery status of a datafile.
After you’ve identified the problem, you need to determine what it will take to cor-
rect the problem. Sometimes, you just need to get a system administrator to remount
a file system that went away for some odd reason. Other times, it’s a hardware issue
that needs to be resolved. If it turns out to be a problem with lost database datafiles,
recover only those datafiles that have problems. There is no need to recover the entire
database, unless the whole database has problems.
In general, determining what you need to recover requires the following steps:
1. Make sure that all hardware problems are corrected.
2. If the database is still running, recover only the datafiles or tablespaces that
were lost. Check to ensure that you did not lose a redo log member or a control
file copy.
3. If the database has crashed, try to start the database. If it says it needs media
recovery, issue the RECOVER DATABASE command. Often, this will work.
4. If the database instance will not start, check again for hardware problems, par-
ticularly memory and memory configuration issues.
5. If the instance will start but the database complains that it cannot find the con-
trol file, you will need to use a backup control file to recover the database.
6. Once the instance will mount, use the V$ views (see Table 10.3) to determine
which database datafiles need recovery.
7. Proceed with the most expedient type of database recovery (datafile, tablespace,
or entire database) for your situation.

Using the Recover Command
The RECOVER command is used to recover entire databases, specific tablespaces, or
specific datafiles, as well as for the three types of incomplete recoveries. Table 10.4
shows the most common parameters used with the RECOVER command. The
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
453
RECOVER command should be issued from a database account that has DBA privi-
leges such as SYS or SYSTEM, or when connected to the database as INTERNAL.
TABLE 10.4: COMMONLY USED RECOVER COMMAND PARAMETERS
Optional Command Description
USING BACKUP CONTROLFILE Indicates that a backup control file is being used dur-
ing the recovery process
UNTIL CANCEL Indicates a cancel-based recovery
UNTIL TIME <time string> Indicates a time-based recovery
UNTIL CHANGE <scn> Indicates a change-based recovery
FROM <location> Provides an alternate archived redo log location to
use during the recovery.
AUTOMATIC Causes the RECOVER command to generate its own
list of suggested redo logs to apply, and will apply
those logs without stopping for user interaction
FROM Defines an alternate location for the archived redo
logs that are to be applied
PARALLEL [degree] NOPARALLEL Allows for parallel recovery processing or disabling of
parallel processing (this parameter overrides the set-
ting of the RECOVERY_PARALLELISM parameter)
When the database starts its recovery exercise, it will start applying the archived
redo logs to the database datafiles to make them consistent. As the recovery process

cycles through each log file, it will prompt you for an action with a message that
looks like this:
SQL> RECOVER DATAFILE 4
ORA-00279: change 76361 generated at 04/25/2001 19:15:30
needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00206.ARC
ORA-00280: change 76361 for thread 1 is in sequence #206
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
So, what is the meaning of this? Oracle says that it needs a particular log sequence
number to start the recovery process. Oracle will sit and wait for you to respond with
some form of input.
RECOVERIES IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
454
In the example here, it needs log sequence number 206, which contains change
number 76361. Oracle also makes some assumptions about the location of this partic-
ular log file. In this case, it thinks the log file is in the d:\oracle\oradata\RECOVER\
ARCHIVE directory, which just happens to be the directory pointed to by the databases
LOG_ARCHIVE_DEST_1 parameter. Thus, by default, Oracle will look for redo log files
in this directory. However, Oracle gives you several options for specifying the log. If
you press Enter, you accept the suggested directory and filename. However, you may

have restored these log files to another directory. In this case, you would respond with
a new directory and filename for the archived redo logs, as shown in the last line here:
SQL> RECOVER DATABASE
ORA-00279: change 76375 generated at 04/25/2001 19:18:13
needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00207.ARC
ORA-00280: change 76375 for thread 1 is in sequence #207
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
e:\oracle\recover\archive\recovert001s00207.arc
You can also choose to cancel the recovery by issuing the CANCEL command, or
you can instruct Oracle to apply the archived redo logs without any input by using
the AUTO command.
Performing Complete Recovery
Complete recovery is just what it sounds like—the complete recovery of a datafile,
tablespace, or the whole database to the point of the last transaction recorded in the
redo logs. When complete recovery is applied successfully, there will be no loss of
data in the database.
When performing a complete recovery, you generally will recover only the affected
datafiles. You will have the online redo logs, as well as the control file, available. Lack
of either the online redo logs or the current control file may require incomplete
recovery methods to be used, but this is not always the case.
One of the principle benefits of running in ARCHIVELOG mode is the ability to
recover a datafile or even a tablespace while the rest of the database is up and run-
ning. Generally, the process you will follow is to take the datafile or tablespace you
are going to recover offline, recover it, and then bring it online again. If users attempt
to access an object that is contained within that tablespace, they will receive an error.
Users who do not use any objects in that tablespace will not notice any problems
(except possible slowdowns during the recovery process).
C

opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
455
Certain types of recoveries cannot be done with the database up and running.
These include recovering from the loss of the entire database (no surprise there) and
recovering from the loss of a datafile in the SYSTEM tablespace. Recoveries from loss
of a tablespace with an active rollback segment will likely begin with the database
down as well. These special cases are discussed in the sections following the descrip-
tions of how to recover datafiles, tablespaces, and the entire database.
Determining Which Archive Log Files to Recover
Once you have recovered the database datafiles, you will want to know which
archived redo logs you need to recover. Recall that archived redo logs are primarily
tracked by their unique log sequence number. Oracle keeps track of each archived
redo log in the control file, including that log’s sequence number. Also in the control
file, with each archived redo log record, Oracle keeps track of the first and last SCN (or
change number) that is contained in that redo log. This information is available to
the DBA when the database is mounted or opened via the V$ARCHIVED_LOG data
dictionary view.
Once you have identified which datafiles need to be recovered, and once you have
recovered those datafiles, you will use the V$RECOVER_FILE view to determine the
last change number present in that datafile. Using this information, you then look up
the sequence number that is required for the next change number, and that will be the
sequence number of the archived redo log that you will need to start your recovery
with. Here is an example of the type of queries you might run to determine the log
sequence numbers of the archived redo logs you will need to recover:
SELECT a.name, b.change# FROM v$datafile a, v$recover_file b
WHERE a.file#=b.file#;
NAME CHANGE#

D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF 76361
SELECT sequence#, name
FROM v$archived_log
WHERE first_change# >= 76361;
SEQUENCE# NAME

207 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00207.ARC
208 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00208.ARC
209 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00209.ARC
RECOVERIES IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
456
210 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00210.ARC
211 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00211.ARC
In this case, you see that you need to recover five archived redo logs in order to
restore the given datafile. After running this query, you should recover the archived
redo logs from your backup medium in preparation for recovering the database, table-
space, or datafile.
Datafile Recovery
Datafile recoveries generally have the least impact on your system. For the most part,
recovery of a datafile can be completed while the rest of the database is up and run-
ning. Datafile recovery does not need to be a synchronous operation. You can recover

multiple datafiles using multiple sessions to the database, although only one datafile
can be recovered per session at any one time. Typically, datafile recovery will occur in
cases such as the following:
• Some hardware failure occurred that caused the loss of a few database datafiles.
• An administrator accidentally removed the datafile or the directory.
• Database corruption has occurred due to a bug or perhaps faulty memory.
To perform a datafile recovery, follow these steps:
1. If the database is already open, take any affected datafiles offline. (You may find
that Oracle has already taken them offline.) To take a datafile offline, use the
ALTER DATABASE DATAFILE OFFLINE command. If the database was shut down
and is refusing to open because of a missing datafile, take the datafile offline, and
then issue an ALTER DATABASE OPEN command.
2. Recover only the affected datafile(s) from the last backup taken in ARCHIVE-
LOG mode.
3. Recover all archived redo logs created since the start of the last hot backup. (See
the previous section for details on determining which archived redo logs to
recover.)
4. Recover each datafile individually with the RECOVER DATAFILE <datafilename
or datafile number> command.
5. Once the datafiles are recovered, bring the datafiles back online with the ALTER
DATABASE ONLINE command. Make sure you don’t need to also bring the asso-
ciated tablespace online. Once this step is complete, your database has been
recovered.
Listing 10.4 provides an example of a datafile recovery. In this example, we lost a
datafile called recover_idx_01.dbf, which belongs to our IDX tablespace. When we
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
457

tried to start the database, we were alerted to the missing file. In order to get the data-
base up quickly, we first take the file offline, and then open the database. Finally, we
proceed to restore the missing datafile from disk and recover it.
Listing 10.4: Recovering a Datafile
First, we try to start the database. We have a hot backup.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01113: file 4 needs media recovery
ORA-01110: datafile 4: ‘D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF’
Oracle has signaled us here that a datafile is in need of recovery.
Normally, we would first issue a recover database command to see if
that will fix the problem. In this case, let’s assume it’s corrupt
and correct the problem.
Find out what archived redo logs we need.
SQL> SELECT a.name, b.change# FROM v$datafile a, v$recover_file b
2 WHERE a.file#=b.file#;
NAME CHANGE#

D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF 76361
SQL> SELECT sequence#, name
2 FROM v$archived_log
3 WHERE first_change# >= 76361;
SEQUENCE# NAME

207 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00207.ARC
208 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00208.ARC
209 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00209.ARC
210 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00210.ARC
211 D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00211.ARC
RECOVERIES IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
458
Now, take the datafile offline and open the database so users can
use it.
SQL> ALTER DATABASE DATAFILE 4 OFFLINE;
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
Now, copy the last backup of the datafile into its proper place.
This was done on NT.
SQL> HOST COPY recover_idx_01.dbf.backup RECOVER_IDX_01.DBF
1 file(s) copied.
Note the status of the datafile is offline right now.
SELECT file#, name, status FROM v$datafile;
SQL> /
FILE# NAME STATUS

1 D:\ORACLE\ORADATA\RECOVER\SYSTEM01.DBF SYSTEM
2 D:\ORACLE\ORADATA\RECOVER\RECOVER_RBS_01.DBF ONLINE
3 D:\ORACLE\ORADATA\RECOVER\RECOVER_USERS_01.DBF ONLINE
4 D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF OFFLINE
5 D:\ORACLE\ORADATA\RECOVER\RECOVER_TEMP_01.DBF ONLINE
Now that the backup datafile is in place, issue the recover command.
We will apply the redo logs as required.
SQL> RECOVER DATAFILE 4;
ORA-00279: change 76361 generated at 04/25/2001 19:15:30
needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00206.ARC
ORA-00280: change 76361 for thread 1 is in sequence #206
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 76375 generated at 04/25/2001 19:18:13
needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00207.ARC
ORA-00280: change 76375 for thread 1 is in sequence #207
ORA-00278: log file
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.