Oracle8 Recovery: in This Chapter

Oracle8 Recovery
17
C H A P T E R
In This Chapter
nderstanding and applying Oracle8 recovery principles and strategies is an evolutionary process. This chapter explains the following basic concepts: 3 The underlying Oracle8 recovery data structures 3 The restoration and recovery process of a database file 3 Oracle8 database failures 3 Oracle8 recovery methods
The data structures used by the Oracle8 recovery processes The Oracle8 recovery principles and internals Instance recovery operations Media (disk) recovery operations SQL recovery methods Using Recovery Manager Using the NT Recovery Manager
There is a difference between restoring a database file and recovering a database file. Restoring a database file merely means replacing a certain database file, such as a datafile, with a copy from backup. This process usually occurs if the database file is corrupted and needs to be replaced with a backup file. Recovering a database file is the process of making the recovered database file current to a specific time. The first part of this chapter focuses on the Oracle8 data structures used extensively in the recovery process: 3 The Control File 3 Rollback segments 3 Redo entries 3 Online redo log files 3 System Change Number 3 Datafiles 3 Checkpoint These data structures form the plateau on which the Oracle8 recovery process is initiated.
390
Chapter 17 3 Oracle8 Recovery
The second part of this chapter describes the Oracle8 recovery principles. You apply your new data structure knowledge in this section. The third part of this chapter focuses on instance failures and media (disk) failures, which are the two types of Oracle8 failures. The final part of this chapter describes the recovery methods available to a DBA: the SQL RECOVER command, the Recovery Manager, the NT Recovery Manager, and the Oracle8 Import utility (also discussed in Chapter 16, Backups).
Oracle8 Recovery Data Structures

Understanding the following Oracle8 data structures is paramount in understanding how Oracle8 engages and executes its various recovery methods: 3 Control File 3 Rollback Segments 3 Redo Entries 3 Online redo log files 3 System change number 3 Datafiles 3 Checkpoint
Control File
The Oracle8 Control File contains information that describes the database structure and the state of the online database files. Oracle8 needs this critical information to engage in any recovery process. The information in the Control File is divided into five parts: 1. Database information. This part contains information about the datafiles online redo log files, and redo threads used by the Oracle8 instance.
Note
If the parallel option is not used, the Oracle8 instance only uses one redo thread. 2. Redo thread information. This part provides information about the redo threads used by the Oracle8 instance, including the log group to which the Oracle8 log writer background process currently writes.
Chapter 17 3 Oracle8 Recovery Data Structures
391
3. Redo log member information. This part contains the following information about each redo log member of a redo log group: The size of the online redo log file The physical path name of the online redo log file The high and low System Change Number (SCN) values in the redo log file 4. Datafile information. This part contains the following information about the datafiles used by the Oracle8 instance: The physical path name of the datafile The size of the datafile Status of the datafile The stop SCN of the datafile
Note
This section indicates whether media (disk) recovery is required for the datafile. 5. Log history information. This section of the Control File can be configured to contain historical records for every online redo log file used by the Oracle8 instance. Each historical redo log record contains the following information: Redo thread number Log sequence number Low SCN High SCN The V$LOG_HISTORY view contains same historical information. Figure 17-1 shows the V$LOG_HISTORY view. The initialization parameter MAXLOGHISTORY controls the amount of redo log history stored in the Control File.
Note
Redundant copies of the Control File should be kept on different physical disks than the Oracle8 database.
Rollback segments
During database recovery, information in the rollback segment nullifies any uncommitted changes applied from the online redo log file to the datafiles. This operation ensures the Oracle8 database is in a consistent state after the recovery process.
392
Figure 17-1: The V$LOG_HISTORY view shows historical redo log records.
Redo records
A redo record exists in the context of an online redo log file. Each redo record describes a single atomic change to the database. Redo records are created in the online redo log file for all database data block changes.
The online redo log file

Online redo log files store information generated by the modification of data blocks. The first block of the online redo log file doesnt contain any redo records and is the files header. The following information is stored in the redo log: 3 The redo log sequence number 3 The corresponding redo thread number 3 The low SCN value 3 The high SCN value 3 Thread status information
CrossReference
As explained in Chapter 16, the contents of an online redo log file and archive log files are always identical.
Chapter 17 3 Oracle8 Recovery Data Structures
393
System change number

The system change number (SCN) is a crucial element of understanding the Oracle8 recovery process. Each committed transaction is assigned a SCN by an internal Oracle8 clock. As a result, each transaction is uniquely identified. SCN values control transaction concurrency and redo ordering.
Example
The following example discuss how SCN values function. Transaction A executes a SQL INSERT operation that commits successfully. Transaction A is automatically assigned an SCN value of 1001. The next successfully committed transaction is assigned an SCN value of 1002 and so forth. SCN values do not have to be assigned sequentially to transactions. Internal work by Oracle8 may also require SCN values, which are generated and assigned automatically.
Low and high SCN values

Online redo log files are filled in a circular fashion. When an online redo log file becomes filled, the file is closed and another online redo log file is opened and written to. This process is known as log switching.
CrossReference
Log switching is fully described in Chapter 16. Each online redo log file contains a low and a high SCN value. The low SCN value is normally greater than the high SCN value of the previously closed online redo log file. The high SCN value of the current online redo log file is set to infinity, because Oracle8 does not know how many SCNs will be recorded in the current online redo log file. Once the current online redo log file is closed, Oracle8 knows the highest SCN value and the high SCN value is set accordingly. To view the SCN values assigned, execute the following SQL SELECT command:
SELECT * FROM V$LOG_HISTORY WHERE Rownum < 100;
Note
Because this SQL SELECT statement can generate a huge result set, use the Rownum constraint to restrict the number of rows returned.
Stop SCN values

Every datafile has an assigned stop SCN value also stored in the Control File of the Oracle8 instance. When the Oracle8 database is open, the stop SCN value for all online datafiles is set to infinity. When a Tablespace is taken offline, the stop SCN for the datafiles belonging to that Tablespace is set according to the respective high SCN values. Thus, a stop SCN value for a datafile implies no more redo entries will be generated for a respective datafile.
394
The stop SCN value is used by Oracle8 to ensure media recovery, using an offline datafile, ends when the recovery process reaches an SCN value equal to the stop SCN value.
Datafiles
Oracle8 datafiles exist within the context of Tablespaces, which each contain one or more datafiles. Datafiles contain data blocks, which store the organizations data. The first block of any datafile is considered a header that does not contain any organizational data. Instead, it is used to store information on the state of the datafile. The following information about the datafile is stored in its header: 3 Datafile checkpoint information 3 Block size of the datafile 3 Timestamp of when the datafile was created 3 Backup mode status (hot or cold) The datafile is a critical element in all recovery methods because redo entries are applied to a data block in the datafile.
Note
Datafile header information is also replicated in the Control File. This replication applies to all datafiles used by the Oracle8 instance.
Checkpoint
A checkpoint data structure in the Control File is maintained for each thread of the instance. The following section discuss the two most important types of checkpoint operations: 3 Database checkpoints 3 Instance checkpoints A database checkpoint operation flushes any modified data in the buffer cache of the System Global Area (SGA) to disk. This process also updates the checkpoint structure in the Control File and any respective datafile headers.
Note
After a database checkpoint operation, the redo information in the online redo log files is no longer required for any recovery operation because it has already been written to disk. An instance checkpoint is also known as a thread checkpoint. A single instance Oracle8 database only contains one thread. Regardless, instance threads perform checkpoints independently of other threads.
Chapter 17 3 Oracle8 Recovery Principles
395
Once a thread checkpoint occurs, checkpoint information in the Control File and any open online datafile headers are updated. The checkpoint structure in the Control File contains the following information: 3 The current SCN at which the checkpoint occurred 3 The thread that performed the checkpoint 3 All enabled threads 3 The timestamp at which the current SCN is recorded Oracle8 uses checkpoint information in the Control File and the datafile headers to ensure the recovery process starts reading the online redo log threads at the correct point.
Oracle8 Recovery Principles

This section details the internal mechanisms involved in instance and media recovery processes. A good understanding of these principles helps you, as the DBA, make better decisions on the type of backup and recovery scheme to use. In addition, these principles help you understand the choices available during the recovery process. This section explores redo threads, the stages of an instance startup, recovery intelligence, and the Oracle8 recovery process.
Redo threads
CrossReference
You must understand online redo log files before looking into redo threads. Review the Oracle8 backup elements and concepts section in Chapter 16 for a thorough description. Also refer to the following Data structures section in this chapter. Online redo log files store redo records generated from the modification of database data. As a prerequisite, every Oracle8 instance must have at least two online redo log groups. In turn, an online redo log group must contain at least one online redo log file (also known as a member).
Note
Oracle recommends at least two members exist for each online redo log group to safeguard against online redo log file failures. View the redo thread as a channel used to write redo entries to a group of online redo log files. When a single Oracle8 instance database is created, Oracle8 creates one redo thread. Extra redo threads can be created to serve any additional online redo log files for added efficiency. A thread number uniquely identifies each thread. The first thread created by Oracle8 is conveniently numbered 1.
396
See Reference Section
ALTER DATABASE
Modify the number of redo threads using the ALTER DATABASE command. For example, the following SQL ALTER statements create a new thread (thread number 2) with three online redo log groups. Each log group has one member. By default, the new thread is disabled after creation.
SQLDBA> ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 3 'LOG3.RDO; SQLDBA> ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 4 'LOG4.RDO; SQLDBA> ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 5 'LOG5.RDO;
Note
Every new redo thread needs to be enabled before the Oracle8 instance can use them to serve the respective online redo log files. The following SQL ALTER command enables the newly created thread 2:
SQLDBA> ALTER DATABASE ENABLE PUBLIC THREAD 2;
Using the PUBLIC parameter makes the thread available to all instances. The following SQL ALTER statement disables the same thread 2:
SQLDBA> ALTER DATABASE DISABLE THREAD 2;
Note
A thread must have at least two online redo log files (groups) while it is enabled. Also, an enabled thread always uses one online log file as its current log file. The following two methods close a redo thread: 3 Oracle8 instance shutdown 3 Oracle8 instance recovery When a redo thread is closed, Oracle8 executes an instance checkpoint. The instance checkpoint ensures no more redo records are generated for that thread. In addition, the instance checkpoint ensures all changes in the online redo log files are in the respective datafiles.
The stages of an Oracle8 instance startup

An Oracle8 database goes through various stages before it opens to the external Users and applications. The following steps outline the Oracle8 startup process using Server Manager to start the database.
Stage 1. Starting an Oracle8 instance without mounting the database

In this NOMOUNT state, Oracle8 reads the respective INIT.ORA file to determine the size of the SGA. The SGA is then created. Any Oracle8 background processes that need to run are also initiated at this point. The following SQL statement starts an instance without mounting the database:
Chapter 17 3 Oracle8 Recovery Principles
397
STARTUP NOMOUNT
After executing this SQL command, the DBA sees the following messages on the screen:
SVRMGR> Connect Internal Password: Connected. SVRMGR> Startup Nomount ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers SVRMGR>
Note
12071016 46136 11090992 409600 524288
Bytes Bytes Bytes Bytes Bytes
The database must be shut down before executing the preceding statement. Otherwise, an error message will be displayed.
Stage 2. Mounting an Oracle8 database

The following SQL ALTER statement mounts an Oracle8 database:
ALTER DATABASE MOUNT;
When the database is mounted, the Oracle8 instance opens the Control File. After executing the preceding SQL ALTER command, the DBA sees the following message on the screen, which indicates a successful mount of the database:
Statement processed. SVRMGR>
At this point, the RECOVER or ALTER DATABASE commands can be executed for the Oracle8 recovery methods.
Note
Important database file trace information can be dumped from the respective database files at this stage. Stage 1 and Stage 2 can be combined into one step with the following comand:
STARTUP MOUNT
Stage 3. Opening an Oracle8 database

The following command opens the Oracle8 database:
ALTER DATABASE OPEN;
This stage verifies all appropriate database files are opened and placed online.
398
In addition, Oracle8 recognizes whether crash recovery needs to be performed. Crash recovery is performed every time an Oracle8 instance is started after an instance failure. Crash recovery involves two steps: 1. Redo data in the online redo logs files is applied to the datafiles. 2. Uncommitted transactions are rolled back.
Note
Oracle8 crash recovery is an automatic process and requires no human intervention. At this point, your Oracle8 database is up and running and open for Users.
Oracle8 recovery intelligence

How does Oracle8 know when instance or media recovery is required? The data structures discussed in the preceding section provide Oracle8 with the information to make that decision. The header information in each online datafile stores a checkpoint counter incremented every time Oracle8 checkpoints the respective datafile. This counter is replicated in the Control File of the Oracle8 instance for each datafile. Also, the header of a datafile maintains a specific start SCN value also incremented every time the datafile experiences a checkpoint. When the database shuts down in normal or immediate mode, the stop SCN values in the Control File checkpoint structure for each datafile are set to their corresponding datafiles start SCN. Next, when the Oracle8 instance starts again, Oracle8 verifies two conditions before opening the database: 3 Checkpoint counter verification. Oracle8 first confirms the checkpoint counter information stored in the Control File checkpoint structure matches the respective counters stored in the headers of the datafiles. If a datafile is replaced with a backup copy after the instance is shut down, Oracle8 fails the checkpoint counter verification process. At this point, Oracle8 requests the initiation of media recovery to bring the database to a consistent state. 3 Start and stop SCN value comparison. In this operation, Oracle8 compares the start SCN values in the datafiles to their respective stop SCN values in the Control File checkpoint structure. If the two SCN values match, no database recovery is required. The database is allowed to open and the stop SCN values of the datafiles in the Control File are set to infinity. When the instance shuts down with the ABORT command, the stop SCN values in the Control File for the datafiles are not set to their respective start SCN values; they remain set to infinity. This condition causes the start SCN values in the datafile headers to disagree with their stop SCN values in the Control File.
Chapter 17 3 Oracle 8 Failure
399
At this point Oracle8 starts to automatically perform instance recovery, also known as crash recovery. The online redo log files apply redo records to the datafiles, also known as rolling forward. Next, Oracle8 performs transaction recovery, also known as rolling back. The next section describes the basic steps Oracle8 uses to perform its recovery process.
The Oracle8 recovery process

Whether instance or media recovery is being performed, Oracle8 performs the two following recovery processes sequentially: 3 Roll forward. The roll forward recovery process sequentially applies redo information from the online redo log files to their corresponding datafile data blocks. 3 Roll backward/transaction recovery. In the roll back (or transaction recovery) process, Oracle8 rolls back all uncommitted transactions. The undo$ Table is scanned to find all open and active transactions. These transactions are then rolled back so they do not generate any redo records.
Oracle8 Failure
Oracle8 experiences two types of failures: 3 Instance/thread failure 3 Media (disk) failure Oracle8 instance failures occur when the SGA cannot be assigned or any one of the critical Oracle8 instance background processes cannot be started. Table 17-1 lists the Oracle failure types. If Oracle8 experiences an instance failure, no data stored in the SGA buffers is written to their respective datafiles. Instance recovery is performed automatically by Oracle (as discussed later in this section). Media (disk) failures arise when Oracle8 has difficulty reading or writing data to the physical disk. This type of failure can arise from problems with the disk controller or even corruption on the disk surface.
Note
As with instance failure, media failure does not permit data stored in the SGA buffers to be written to the physical disk.
400
Table 17-1 Oracle Failures and How To Recover

Failure Type Instance failure Media failure Typical Causes Power outages, incorrect memory allocations, operating system crashes Corruption of datafiles, online redo log files, Control Files Recovery Method Automatic SQL recover command, Recovery Manager, or NT Recovery Manager
Media recovery can be performed using three methods (as discussed later in this chapter): 3 The SQL RECOVER command 3 The Oracle8 Recovery Manager 3 The NT Recovery Manager
Oracle8 recovery analysis

The most important factor in any Oracle8 recovery method, regardless of failure type, is all database files must be recovered to exactly the same time. In other words, the Oracle8 database must be brought back to a consistent state. With instance failure, Oracle8 automatically performs the recovery process. Media failure involves DBA intervention with the use of database file backups. To illustrate this important fact, lets use a simple scenario of an Oracle8 instance startup, as illustrated in Figure 17-2.
Time 1
Time 2
Time 3
Time Oracle8 instance started and opened Successful hot backup The current state of the Oracle8 instance
Figure 17-2: A simple scenario of an Oracle8 database
Chapter 17 3 Oracle 8 Failure
401
This scenario indicates the database was started at Time 1 and a hot backup took place at Time 2. The Oracle8 instance is now at Time 3. If the Oracle8 database experiences media failure at Time 3, only files from the backup at Time 2 can be used for recovery. The following two options are available at Time 3 for a DBA: 3 Use the hot backup to restore the database to point Time 2. Then use the SQL RECOVER database command to recover the database to Time 3. 3 Restore any corrupted database files offline and then use the respective SQL RECOVER command to recover the respective database file to Time 3. The syntax for the SQL RECOVERY command follows:
RECOVER [AUTOMATIC] [FROM 'location'] [DATABASE] | [UNTIL CANCEL] | [UNTIL TIME date] | [UNTIL CHANGE integer] [USING BACKUP CONTROLFILE]
The features of the command include: 3 The AUTOMATIC option allows automatic recovery without asking for the names of the archive redo logs file. 3 The FROM location option specifies the location of the archive redo log files. The location should match the specified location in the LOG_ARCHIVE_DEST parameter. 3 If none of the UNTIL options are used, complete database recovery is performed instead of point-in-time recovery. This scenario illustrates the Oracle8 database must be in a consistent state before it is opened.
Instance automatic recovery

Recovery from instance failure is an automatic process and requires no human intervention. Instance recovery is also known as thread recovery. If an instance crashes, Oracle8 performs the following tasks automatically: 1. All redo records for each thread generated since the threads last checkpoint are applied to the respective datafiles. 2. Dirty blocks in the buffer cache are written to disk using the threads checkpoint counter maintained in the Control File. 3. All open redo threads are closed.
402
4. Both sets of checkpoint counters (in the headers of the datafiles and also maintained in the Control File) are compared. This comparison ensures no datafile was replaced during the instance recovery process. If a datafile was replaced, then Oracle8 insists on an immediate initiation of media recovery. 5. Any uncommitted transactions are rolled back.
Note
Oracle8 needs access to all Control Files, online redo logs files, and datafiles during instance recovery.
Media (Disk) Recovery

Oracle8 recognizes when a datafile needs media recovery by comparing the checkpoint counters in the headers of the datafiles with the counterpart Control File checkpoint values. Media recovery restores a database file to a time before disk failure occurred using the respective backup database files. Committed changes in memory are rolled forward and applied to the respective datafiles by using the online redo log files. All redo records of all enabled redo threads are applied to their respective datafiles. An end-of thread record indicates the last redo record Oracle8 reads for a given online redo log file. Oracle8 stops applying redo for the thread at this point. Oracle8 stops performing media recovery when all enabled threads have been recovered to their respective end-of thread records. Without the online redo log files, the Oracle8 database can only be recovered to the time of the last database backup because all database files must be consistent in state. The following three media recovery options are available to a DBA: 1. Database recovery. All database files are restored. The entire database is recovered to the time of the last backup. 2. Tablespace recovery. Datafiles belonging to a specific Tablespace are restored, recovered, and brought online. 3. Datafile recovery. A specific datafile is restored, recovered, and brought online.
Note
The Oracle8 database can be fully operational for Tablespace and datafile recovery operations. Only the files need to be placed offline.
Chapter 17 3 Media (Disk) Recovery
403
Types of media recovery

The two types of media recovery are differentiated by the amount of recoverable data: 3 Complete recovery 3 Incomplete recovery Performing media recovery on an Oracle8 database without losing any data is known as complete recovery. If data is lost during the media recovery operation, the process is known as incomplete recovery.
Guidelines for media recovery

The type of media recovery is dictated by the backup mode of the Oracle8 database. The Oracle8 database can operate in the two following backup modes: 3 NOARCHIVELOG 3 ARCHIVELOG If the database operates in NOARCHIVELOG mode, archived redo log files are unavailable to the recovery process. Thus, the only recovery methods available follow: 3 Restoring from a consistent backup of the entire database 3 Rebuilding the database from a full database export file
Restoring a database in NOARCHIVELOG mode

1. Shutdown the Oracle8 database using the ABORT option of SHUTDOWN command. 2. Restore the most recent backup of the whole database. This backup can be restored to the respective original location. 3. Start up the Oracle8 instance and mount the database. Do not open the database at this point.
STARTUP RESTRICT MOUNT;
4. If the database files were not restored to their original locations, the new location of these database files must be indicated to the Control File.
ALTER DATABASE RENAME FILE 'old_filename' TO 'new_filename'
404
5. Start the Oracle8 database by issuing the ALTER DATABASE OPEN command with the RESETLOGS option.
ALTER DATABASE OPEN RESETLOGS;
The RESETLOGS option resets the current log sequence number. It also invalidates all redo records in the online redo log files, thereby discarding any changes to the database from the point of backup to the point of media failure. If the database is operating in ARCHIVELOG mode, archived redo log files are available to the recovery process, which increases the types of media recovery methods available. Complete and incomplete media recovery can only be performed if the Oracle8 database is operating in the ARCHIVELOG mode.
Complete recovery
Complete media recovery restores the respective database files from a backup and rolls the database forward to the current state by applying archived redo log files. Thus, as a perquisite of complete recovery, the following database files are available to the recovery process: 3 The current Control File 3 All online redo log files 3 Backups of the respective database files Complete media recovery can be further split into the following Oracle8 recovery operations: 3 Closed database recovery 3 Open database, offline Tablespace recovery 3 Open database, offline Tablespace, individual datafile recovery
Note
The Oracle8 database can remain open for complete media recovery involving Tablespaces and datafiles. Three SQL RECOVER commands perform complete media recovery: 3 RECOVER DATABASE 3 RECOVER TABLESPACE 3 RECOVER DATAFILE The usage of the preceding commands depends on the open or closed state of the Oracle8 database, as shown in Table 17-2.
405
Table 17-2 Complete Media Recovery Methods for Open or Closed Databases
Recovery command Database open No Yes Yes Database closed Yes No Yes
RECOVER DATABASE RECOVER TABLESPACE RECOVER DATAFILE
Tip
Regardless of whether the database is open or closed, Tablespaces and datafiles must be offline.
Performing complete recovery

This section describes how to perform the following complete media recovery operations: 3 Closed database recovery 3 Open database, offline Tablespace recovery 3 Open database, offline Tablespace, individual datafile recovery
Closed database recovery

Use the following steps to perform a closed database recovery: 1. Shut down the Oracle8 database using the ABORT option of SHUTDOWN command. 2. Restore the most recent backup of the damaged database files. The files can be restored to their respective original locations. 3. Start the Oracle8 instance and mount the database. Do not open the database at this point.
STARTUP RESTRICT MOUNT;
4. If the database files were not restored to their original locations, the new location of these database files must be indicated to the Control File.
406
5. Confirm all datafiles to be recovered are online. The V$DATAFILE view provides the status information on all Oracle8 datafiles. The following command and results illustrate the contents of the V$DATAFILE view:
SQLWKS> SELECT file#, STATUS, ENABLED, NAME FROM V$DATAFILE; FILE# STATUS ENABLED - - 1 SYSTEM READ WRITE 2 ONLINE READ WRITE 3 ONLINE READ WRITE 4 ONLINE READ WRITE 5 ONLINE READ WRITE 6 ONLINE READ WRITE NAME D:\ORANT\DATABASE\SYS1ORCL.ORA D:\ORANT\DATABASE\USR1ORCL.ORA D:\ORANT\DATABASE\RBS1ORCL.ORA D:\ORANT\DATABASE\TMP1ORCL.ORA D:\ORANT\DATABASE\CHANDI.ORA D:\ORANT\DATABASE\AMYC.ORA
6. Ensure the datafile is online by issuing the ALTER DATABASE command with the DATAFILE ONLINE option.
ALTER DATABASE dataFILE 'amyc' ONLINE;
Note
If Oracle8 finds the datafile already online, the statement is ignored. 7. Start the closed database recovery operation by issuing the RECOVER DATABASE command.
RECOVER DATABASE;
At this stage, Oracle begins rolling forward the archived and online redo log files to bring the database to a consistent state. If the automatic option is added to the RECOVER DATABASE command, Oracle8 does not prompt for the names of the archived redo log file. Otherwise, be prepared to enter the exact names when prompted. All online redo log files are applied automatically to the respective datafiles. Oracle8 provides a prompt when media recovery has been completed. 8. Open the Oracle8 database.
Open database, offline Tablespace recovery

If an open Oracle8 database experiences media failure that causes corruption to any of the datafiles, the corrupted datafiles are automatically taken offline. The Oracle8 database only shuts down if the system Tablespace is corrupted; otherwise, it remains open. Use the following steps to perform an open database, offline Tablespace recovery: 1. Ensure the Tablespace is offline by using the ALTER TABLESPACE command with the OFFLINE option.
ALTER TABLESPACE Tablespace_name Offline;
407
2. Restore all damaged datafiles to their original locations from the most recent database backup. 3. If the datafiles were not restored to their original locations, the new location of these datafiles must be indicated to the Control File.
ALTER DATABASE RENAME FILE 'old_filename' TO 'new_filename';
4. Recover the restored Tablespace by issuing the RECOVER TABLESPACE command.

RECOVER TABLESPACE Tablespace_name;
5. Issue the ALTER TABLESPACE command with the ONLINE option to bring the restored Tablespace online.
ALTER TABLESPACE Tablespace_name ONLINE;
Open database, offline Tablespace, individual datafile recovery

Individual datafile recovery can be performed while the database is online or offline. Use the following steps to perform an open database, offline Tablespace, individual datafile recovery: 1. Start the instance and mount the database.
STARTUP MOUNT
2. Ensure the corrupted datafiles are offline using the ALTER DATAFILE command with the OFFLINE option.
ALTER DATAFILE 'datafile_name' OFFLINE;
3. Open the database using the ALTER DATABASE command with OPEN option.
4. Restore all damaged datafiles to their original locations from the most recent database backup. 5. If the datafiles were not restored to their original locations, the new location of these datafiles must be indicated to the Control File.
ALTER DATABASE RENAME file 'old_filename' to 'new_filename';
6. Recover the restored datafiles by issuing the RECOVER DATAFILE command.

RECOVER DATAFILE 'datafile_name';
408
7. Issue the ALTER DATAFILE command with the ONLINE option to bring the restored datafile online.
ALTER DATAFILE'datafile_name' ONLINE;
Performing incomplete media recovery

Sometimes, such as when the Control File, online, or archived redo log files are either lost or damaged, complete media recovery cannot be performed. In these situations, you can perform incomplete recovery. Incomplete media recovery causes the database to be restored to another time in the past. The recovery process can continue after the incomplete recovery to become a complete recovery or become a new incarnation of the database.
Note
The database must be closed for any incomplete media recovery operations. This section describes how to use the SQL RECOVER command to perform the following incomplete media recovery operations: 3 Cancel-based recovery. Use the UNTIL CANCEL option of the RECOVER command. 3 Time-based recovery. Use the UNTIL TIME option of the RECOVER command. 3 Change-based recovery. Use the UNTIL CHANGE option of the RECOVER command. The syntax for the SQL RECOVERY command follows:
RECOVER [AUTOMATIC] [FROM 'location'] [DATABASE] | [UNTIL CANCEL] | [UNTIL TIME date] | [UNTIL CHANGE integer] [USING backup controlFILE]
Cancel-based recovery
This recovery operation allows redo log data to be applied one log at a time. When the recovery process needs to be stopped, the CANCEL command is issued. The SQL statement for cancel-based recovery follows:
RECOVER DATABASE UNTIL CANCEL;
To stop recovery, the DBA types CANCEL any time the recovery process prompts for an response.
409
Note
The online redo log files are not automatically applied in this recovery operation.
Time-based recovery
This recovery operation allows recovery to a specific time within a redo log file. For example, the SQL statement for incomplete media recovery to 12:00 P.M. on February 20, 1997 follows:
RECOVER DATABASE UNTIL TIME '1997-02-20:12:00:00';
Change-based recovery
This recovery operation uses an SCN value as its stopping point for recovery. Any redo records with an SCN value less than the specified SCN value are applied. The SQL statement for change-based recovery follows:
RECOVER DATABASE UNTIL CHANGE 300168;
Performing incomplete media recovery

Use the following steps to perform an incomplete media recovery operation: 1. Shut down the Oracle8 database. 2. Restore all the damaged datafiles to their original locations from the most recent database backup. 3. If the datafiles were not restored to their original locations, the new location of these datafiles must be indicated to the Control File.
4. Confirm all datafiles to be recovered are online. The V$DATAFILE view provides the status information on all Oracle8 datafiles. The following SQL command shows how to query the V$DATAFILE table.
SQLWKS> SELECT FILE#, STATUS, ENABLED, NAME FROM V$DATAFILE; FILE# - 1 2 3 4 5 6 STATUS SYSTEM ONLINE ONLINE ONLINE ONLINE ONLINE ENABLED NAME READ WRITE D:\ORANT\DATABASE\SYS1ORCL.ORA READ WRITE D:\ORANT\DATABASE\USR1ORCL.ORA READ WRITE D:\ORANT\DATABASE\RBS1ORCL.ORA READ WRITE D:\ORANT\DATABASE\TMP1ORCL.ORA READ WRITE D:\ORANT\DATABASE\CHANDI.ORA READ WRITE D:\ORANT\DATABASE\AMYC.ORA
410
5. Ensure the datafile is online by issuing the ALTER DATABASE command with the DATAFILE ONLINE option.
ALTER DATABASE DATAFILE 'amyc' ONLINE;
Note
If Oracle8 finds the datafile already online, the statement is ignored.
6. Recover the database using one of the following UNTIL options:

RECOVER DATABASE UNTIL CANCEL; RECOVER DATABASE UNTIL TIME '1998-02-20:12:00:00'; RECOVER DATABASE UNTIL CHANGE 300168;
During the recovery operation, Oracle8 prompts for the names of the redo log files. A message is displayed after the completion of media recovery. 7. Start the Oracle8 database by issuing the ALTER DATABASE OPEN command with the RESETLOGS option.
The RESETLOGS option resets the current log sequence number. It also invalidates all redo records in the online redo log files, thereby discarding any changes to the database from the point of backup to the point of media failure. 8. Take an immediate offline or online backup of the Oracle8 database.
User or application failure

Users accidentally deleting data or database Objects accounts for the majority of corrupted or lost database data. Use the following Oracle8 recovery procedure to recover from data or database Object loss: 1. Backup the existing database. 2. Reconstruct a database using point-in-time recovery. 3. Export the lost data or database Objects from the reconstructed database. 4. Import the exported file into the production database.
Note
Avoid giving the DROP ANY TABLE or other DROP ANY system privilege to the User population. Withholding these privileges could greatly decrease the accidental loss of database Tables and clusters that store data.
411
Recovery Manager
The Oracle8 Recovery Manager application performs recovery operations through a GUI interface. Figure 17-3 illustrates the Recovery Manager interface when started from the Oracle8 Enterprise Manager.
Figure 17-3: Oracle8s Recovery Manager
The Recovery Manager is described in detail in Chapter 16. Recovery Manager must be successfully installed before use. In addition, the Recovery Catalog, if used, should be in full sync with the Oracle8 databases Control File before attempting any recovery operation.
Note
At least one channel must be allocated to perform any backup or recovery operation.
Using Recovery Manager

Recovery Manager performs recovery operations depending on the following states of the Oracle8 database: 3 Mounted 3 Mounted and open 3 ARCHIVELOG mode
412
3 NOARCHIVELOG mode The recovery operations of Recovery Manager can be executed in the following ways: 3 Using stored scripts 3 Using the Command Line Interface (CLI) 3 Using the Restore Wizard
Stored Scripts and CLI

Stored scripts are a set of logical Recovery Manager commands to perform a certain operation on the Oracle8 database. The following categories of commands can be used in stored scripts or directly by the CLI to manage the backup and recovery tasks: 3 BACKUP, RESTORE, COPY, and RECOVER commands 3 Recovery Catalog maintenance commands 3 Stored scripts maintenance commands 3 REPORT and LIST commands Stored scripts can be reused by a DBA to plan, develop, and test Recovery Manager commands for restoring and recovering a database. Like stored subprograms, fully tested and functional stored scripts minimize the potential for operational errors. Stored scripts are executed from the Recovery Manager CLI. Stored scripts can either be copied to a text file on disk or stored and executed from the Recovery Catalog. For example, the following statement from the command line executes the operating system stored script file AMYC.rcv:
rman Target Internal/oracle@objectmind.com rcvcat rman/raman@objectmind.com cmdfile amyc.rcv
The following statement from the Recovery Manager CLI executes the same AMYC stored script from the Recovery Catalog:
RMAN>run { RMAN> EXECUTE Script 'AMYC'; RMAN> }
413
The Restore Wizard

The Recovery Manager has a GUI recovery expert called the Restore Wizard. The Restore Wizard is an option from the Recovery menu item on the Recovery Manager menu bar. The Restore Wizard guides a User through the recovery of the following: 3 Databases 3 Tablespaces 3 Datafiles Depending on the state of the Oracle8 database, certain recovery options may be disabled to the User. Figure 17-4 illustrates the Restore Wizard interface.
Figure 17-4: The Restore Wizard
The recovery process using Recovery Manager

The Recovery Managers database or database file recovery process involves two steps: 3 Restoring the respective database files to a physical location from backups. 3 Recovering the restored database files and bringing them online.
Restoring database files

Recovery Manager uses the Recovery Catalog or the Control File of the Oracle8 database to select the most recent available backup set or copy. If Recovery Manager has a choice between a backup set or a copy, it selects the copy for the restoration operation. By default, the restoration process copies the backup of the
414
datafiles to their original location. Only the restoration of Control Files needs a destination for the restore process. The Recovery Managers RESTORE command restores a database file. The following database elements can be restored using the RESTORE command: 3 Databases 3 Tablespaces 3 Datafiles 3 Control Files 3 ARCHIVELOGS
Note
The Tablespace and database restore options are translated into their respective datafile numbers. For example, the following statement restores the Tablespace AMYC:
RESTORE (tablespace AMYC);
The following statement restores all datafiles to their current locations:

RESTORE (database);
Note
This operation does not restore the Control File only the respective datafiles are restored to their original locations.
Recovering database files

The recovery of database files involves performing media recovery and applying incremental backups (if they exist) to bring the database to a consistent state. If Recovery Manager has a choice between applying incremental backups or ARCHIVELOGS, it selects the incremental backups. Redo records are applied from the online redo log files as needed. Recovery Manager has three forms of RECOVER commands: 3 RECOVER DATABASE 3 RECOVER TABLESPACE 3 RECOVER DATAFILE Database recovery should only be performed for the following reasons: 3 Media failure has damaged the entire database. 3 The entire database must be recovered to a previous time. 3 The Control File has been corrupted or re-created.
415
Note
If possible, the Oracle8 database should be in a started and mounted but not open state. Otherwise, the database name in the INIT.ORA file must be available to supply the target database name. Tablespace recovery should be performed for the following reasons: 3 All datafiles in a Tablespace have been corrupted by media failure. 3 A Tablespace must be recovered to a previous time. Datafile recovery should be performed when one or more datafiles have been corrupted. For both Tablespace and datafile recovery operations, either of the following conditions must apply: 3 The Oracle8 database must only be started and mounted. 3 The respective datafiles or Tablespaces must be offline. Figure 17-5 illustrates how a Tablespace can be placed offline using the Recovery Manager.
Figure 17-5: Taking a Tablespace offline
Note
The Recovery Catalog or the databases Control File must be available for the recovery process.
416
Complete recovery by example

The following complete recovery scenarios are described in this section: 3 Full database recovery 3 Tablespace recovery 3 Datafile recovery
Full database recovery

The following stored script restores all datafiles to their current locations from the most recent backup. It then recovers all respective datafiles.
replace Script Full_db_restore_recover { allocate Channel OM1 type Disk; setlimit Channel OM1 kbytes 2097150 maxopenfiles 32 readrate 200; restore (database); recover database; release Channel OM1; }
The allocate Channel parameter establishes a connection to the database instance. The type Disk parameter indicates that the backup set is on disk. Leave the parameter off to indicate that the backup set is on type.
Tablespace recovery
The following stored script recovers and restores a corrupted Tablespace while the database is open.
replace Script restore_recover_tbls { sql 'alter Tablespace amyc Offline temporary'; allocate Channel OM1 type Disk; setlimit Channel OM1 kbytes 2097150 maxopenfiles 32 readrate 200; set Archivelog Destination to '/Orant/AMYC/archive_logs'; restore (tablespace amyc); recover tablespace amyc; sql 'alter Tablespace amyc online'; release Channel OM1; }
The setlimit parameter assigns limits to the channel so the process does not use excessive resources.
417
Note
The set Archivelog Destination to statement informs Recovery Manager to restore any archived redo logs necessary for recovery to another location. This location is stored by Recovery Manager and used as the destination of the archived redo log files. The log_ARCHIVE_DEST destination parameter is overridden. The following steps describe the same Tablespace recovery operation using the Restore Wizard: 1. Select the Tablespace option from the Restore Wizard introduction screen. Figure 17-6 illustrates the selection of the Tablespace recovery option in the Restore Wizard Introduction Screen.
Figure 17-6: Selecting the Tablespace option with the Restore Wizard
2. Select the Tablespace to restore from the available Tablespace list. Figure 17-7 illustrates the selection of Tablespaces to restore from the Restore Wizard Tablespace Screen. 3. If the respective datafile(s) to which the Tablespace belongs are restored to a different location than the default, enter the location in the Rename screen of the Restore Wizard. Figure 17-8 illustrates the definition of another location for the restoration of the datafiles.
418
Figure 17-7: Selecting the Tablespace to restore
Figure 17-8: Defining a restoration location for the datafile(s)
4. Select the channel(s) to use for the restoration and recovery process in the Channels screen of the Restore Wizard. Figure 17-9 illustrates selecting a channel to use for the restoration and recovery process.
Datafile recovery
The following stored script example recovers and restores a corrupted datafile while the database is open:
419
Figure 17-9: Selecting the channel(s) to use in the restore and recovery process replace Script restore_recover_df { sql 'alter database datafile 'OMind' Offline'; allocate Channel OM1 type Disk; setlimit Channel OM1 kbytes 2097150 maxopenfiles 32 readrate 200; restore (datafile OMind); recover datafile OMind; sql 'alter database datafile OMind online'; release Channel OM1; }
The following steps describe the same datafile recovery operation using the Restore Wizard: 1. Select the datafile option from the Restore Wizard introduction screen. Figure 17-10 illustrates the selection of the Datafile Recovery option in the Restore Wizard introduction screen.
420
Figure 17-10: Selecting the datafile option
2. Select the datafile(s) to restore from the available datafile list. Figure 17-11 illustrates the selection of datafiles to restore from the Restore Wizard datafiles screen.
Figure 17-11: Selecting the datafile(s) to restore
3. If the respective datafile(s) need to be restored to a different location than the default, enter the location in the Rename screen of the Restore Wizard. Figure 17-12 illustrates the definition of another location for the restoration of the datafiles.
421
Figure 17-12: Defining a restoration location for the datafile(s)
4. Select the channel(s) to use for the restoration and recovery process in the Channels screen of the Restore Wizard. Figure 17-13 illustrates the selection of a channel to use for the restoration and recovery process.
Figure 17-13: Selecting the channel(s) to use in the restore and recovery process
422
Incomplete recovery by example

Recovery Manager performs the following incomplete recovery operations: 3 Time-based recovery 3 Change-based recovery 3 Log sequence recovery
Note
Log sequence recovery replaces cancel-based recovery. The Recovery Manager performs incomplete or point-in-time recovery by issuing the set until command. The set until command specifies a time for the recovery or restoration operation. For the preceding incomplete recovery operations, the set until command is used in conjunction with the following options: 3 Time (string) 3 Log Sequence (integer) thread (integer) 3 SCN (integer)
Note
If time-based recovery is used, the time string must be formatted to the NLS date format set in the NLS_DATE_FORMAT environment variable. For incomplete recovery operations, the database must be started and mounted, but not open. The following Server Manager statement starts and only mounts the database:
SVRMGR> Connect Internal Connected. SVRMGR> Startup mount restrict
The following stored script describes an incomplete recovery operation for the entire database:
Replace Script Incomplete_db { set until time '1998-20-02:12:00:00'; allocate Channel OM1 type Disk; setlimit Channel OM1 kbytes 2097150 maxopenfiles 32 readrate 200; restore (database); recover database; sql 'alter database open resetlogs'; release Channel OM1; }
423
Note
The set until time command is in effect for all commands executed between the { and } braces. This command ensures both the restore and recover commands are relative to a time.
Re-creating damaged database files

The following files are critical to any restoration or recovery process: 3 Datafiles 3 Control Files If these files become corrupted without an available backup, they must be recreated, either by using SQL or through the NT Recovery Manager. This section focuses on the re-creation process using the SQL language. The NT Recovery Manager is discussed in the next section.
Re-creating datafiles
If a datafile becomes corrupted without an available backup, the datafile can still be recovered if the following criteria are met: 3 All archived redo log files since the creation of the original datafile are available. 3 The original Control File is available because it contains the name of the original datafile. The ALTER DATABASE command is used with CREATE DATAFILE option to create a new empty datafile replacing the corrupted original datafile. The following SQL statement creates a new datafile:
ALTER DATABASE CREATE DATAFILE 'datafile_name';
Note
The Control File and the Data Dictionary Tables can formulate the size of the new datafile. Next, media recovery must be performed on the new datafile. Using the RECOVER DATAFILE command, the following statement initiates media recovery on a datafile:
RECOVER DATAFILE 'datafile_name';
The following example describes re-creating the amyc.dbf datafile through Server Manager:
D:\ORANT\BIN>svrmgr30 Oracle Server Manager release 3.0.3.0.0 - Production (c) Copyright 1997, Oracle Corporation. All Rights reserved. Oracle8 Enterprise Edition release 8.0.3.0.0 - Production
424
With the Partitioning and Objects Options PL/SQL release 8.0.3.0.0 - Production SVRMGR> Connect Internal Password: Connected. SVRMGR> Startup mount ORACLE instance started. Total System Global Area 12071016 Bytes Fixed Size 46136 Bytes Variable Size 11090992 Bytes Database Buffers 409600 Bytes Redo Buffers 524288 Bytes Database mounted. SVRMGR> Alter database create datafile d:\orant\database\amyc.dbf; Statement processed. SVRMGR> recover datafile d:\orant\database\amyc.dbf; Media recovery Complete. SVRMGR>
Note
To re-create the datafiles for the system Tablespace, the database must be created in ARCHIVELOG mode.
Re-creating Control Files

If the current Control File becomes corrupted, the DBA has two options available: 3 Restore the Control File from a backup. 3 Re-create the Control File. The CREATE CONTROLFILE re-creates the Control File. The syntax for this command follows:
CREATE CONTROLFILE[REUSE] [SET] DATABASE [database_name] LOGFILE logfile_information [, logfile_information, .] RESETLOGS | NORESETLOGS DATAFILE datafile_information [, datafile_information, .] [MAXLOGFILES integer] [MAXLOGMEMBERS integer] [MAXLOGHISTORY integer] [MAXDATAFILES integer] [MAXINSTANCES integer] [ARCHIVELOG | NOARCHIVELOG]
Note
This command can only be used if the database has been started with the STARTUP MOUNT command. The following procedures re-create a Control File: 1. Take a backup of the entire database.
425
2. Start the instance but only mount the database:

STARTUP MOUNT
3. Issue the CREATE CONTROL FILE command. 4. Recover the database. 5. Open the database and reset the logs.
Tip
All names of the database files in the recovery process should be known. Without documentation, the recovery process can be mentally challenging. In general, it is hard to remember the names of database files, especially files created many years ago. To avoid such situations, take a dump of the Control File after a structure change to the Oracle8 database. The SQL statement to dump the contents of the Control File follows:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
The output from executing this command follows. Bold lines indicate commands typed by the DBA.
Dump file D:\ORANT\RDBMS80\trace\ORA00107.TRC Wed Jan 14 18:29:45 1998 ORACLE V8.0.3.0.0 - Production vsnsta=0 vsnsql=c vsnxtr=3 Windows NT V4.0, OS V5.101, CPU type 586 Oracle8 Enterprise Edition release 8.0.3.0.0 - Production With the Partitioning and Objects Options PL/SQL release 8.0.3.0.0 - Production Windows NT V4.0, OS V5.101, CPU type 586 Instance Name: orcl Redo thread mounted by this instance: 1 Oracle process number: 11 pid: 6b Wed Jan 14 18:29:45 1998 Wed Jan 14 18:29:45 1998 *** Session ID:(11.8) 1998.01.14.18.29.45.406 # The following commands will create a new control file and use it # to open the database. # data used by the recovery manager will be lost. Additional logs may # be required for media recovery of Offline datafiles. Use this # only if the current version of all online logs are available.
426
STARTUP Nomount CREATE controlFILE REUSE dataBASE ORACLE NORESETLOGS ArchiveLOG MAXLOGFILES 32 MAXLOGMEMBERS 2 MAXDATAFILES 32 MAXINSTANCES 16 MAXLOGHISTORY 1630 LOGFILE GROUP 1 D:\ORANT\DATABASE\LOG2ORCL.ORA SIZE 200K, GROUP 2 D:\ORANT\DATABASE\LOG1ORCL.ORA SIZE 200K DATAFILE D:\ORANT\DATABASE\SYS1ORCL.ORA, D:\ORANT\DATABASE\USR1ORCL.ORA, D:\ORANT\DATABASE\RBS1ORCL.ORA, D:\ORANT\DATABASE\TMP1ORCL.ORA, D:\ORANT\DATABASE\RCVCAT.ORA, D:\ORANT\DATABASE\TEMP.ORA, D:\ORANT\DATABASE\OM.ORA, D:\ORANT\DATABASE\AMYC, D:\ORANT\DATABASE\AMYC.DBF ; # Take files Offline to match current control file. ALTER dataBASE dataFILE D:\ORANT\DATABASE\AMYC.DBF Offline; # Configure Snapshot controlfile filename EXECUTE SYS.DBMS_BACKUP_RESTORE.CFILESETSNAPSHOTNAME(D:\ORANT\DATABASE \SNCFORCL.ORA); # recovery is required if any of the datafiles are restored backups, # or if the last shutdown was not normal or immediate. RECOVER dataBASE # All logs need archiving and a log Switch is needed. ALTER System Archive log ALL; # database can now be opened normally. ALTER dataBASE open;
NT Recovery Manager
The NT Recovery Manager is an easy-to-use Oracle8 recovery tool. It can be used to recover the Oracle8 database after media failure; only DBAs with the internal
427
password can use NT Recovery Manager, however. Figure 17-14 illustrates the resulting dialog after NT Recovery Manager is invoked.
Note
The NT Recovery Manager should not be confused with the Oracle8 Recovery Manager.
Figure 17-14: The initial screen of the NT Recovery Manager
Upon entering the internal password, the NT Recovery Manager console screen is displayed. Figure 17-15 illustrates the NT Recovery Manager console.
Figure 17-15: The NT Recovery Manager console screen
This screen provides every recovery option permitted by the NT Recovery Manager Tool. The following recovery options are available: 3 Automatic recovery 3 Restore from full database backup 3 Restore datafile, then do recovery 3 Restore Control File, then do recovery
428
Automatic recovery
This option performs an automatic recovery of the Oracle8 database. If the database is open, automatic recovery tries to shut down the database and then perform automatic recovery.
Restore from full database backup

This option restores the database from a full database backup file. The following information is required to perform this operation: 3 The location of the database backup 3 The selection of the database backup Figure 17-16 illustrates the full Database Restore dialog screen.
Note
If the database was backed up in NOARCHIVELOG mode, this is the only option available for the recovery process.
Restore datafile, then do recovery

If this option is selected, the datafile list box displays a drop-down list of the available datafiles. Only one datafile can be selected for recovery. After one datafile is selected and the Recover button is clicked, the Datafile Recovery dialog screen appears.
Figure 17-16: The full Database Restore dialog screen
Figure 17-17 illustrates the Datafile Recovery dialog screen.
429
Figure 17-17: The Datafile Recovery dialog screen
The location of the selected datafile backup needs to be entered from this dialog screen. If a backup of the datafile is not available, a new datafile can be created in its place. This operation restores the datafile and then performs automatic recovery for the datafile.
Restore Control File, then do recovery

This option from the NT Recovery Manager console restores the Control File and performs an automatic recovery. If the Control File is corrupted without a backup, a new Control File can be created by selecting the Create A New Control File option. Figure 17-18 illustrates the Control File recovery dialog screen.
430
Figure 17-18: The Control File recovery dialog screen
Import
Oracle8s Import process provides an additional method for restoring a database. The Import process extracts database Objects and data saved to an Oracle8 Export file and imports them into a specified database. Table Objects are exported and imported in a First In First Out (FIFO) fashion in the following order: 3 Table definition 3 Table data 3 Table Indexes 3 Integrity Constraints This import sequence is important because: 3 Data is not rejected from Tables due to referential integrity Constraints on the Tables. 3 Triggers are prevented from firing twice on the same Import data.
Chapter 17 3 Import
431
Import modes
To balance Oracle8s Export modes, the Import utility also facilitates three modes of Import: 3 Table 3 User 3 Full database
Table
The Table mode specifies Tables to be imported from the Export file. By default, all Tables in the Export file belonging to the User are imported into the Users Schema.
User
The User mode only enables a User to import Objects into the Users own respective Schema. If the User has the IMP_FULL_DATABASE Role, she can import all Objects from the Export file into the respective Schemas.
Full database
The full database mode only applies to Users with the IMP_FULL_DATABASE Role. This mode is analogous with an Oracle8 restore process as it imports every database Object from a full database mode Export file.
Starting the Oracle8 Import utility

Before using Import, the system administrator must run the CATEXP.SQL or the CATALOG.SQL scripts. These scripts create every database Object necessary to support the Import utility and also assign the necessary privileges to the IMP_FULL_DATABASE and DBA Roles. To use Import, you need the CREATE SESSION privilege to log on to the Oracle8 server. This privilege belongs to the CONNECT Role established during database creation. A User can import the Export files created by another User as long as Export User is not privileged. If a privileged User creates an Export file, only a privileged User can import that Export file.
Using the Oracle8 Import utility

The Import utility can be invoked in three ways: 1. Using a parameter file:
Imp80 username/password PARFILE=filename
432
Replace username with your DBA Username and replace password with your DBA password. Replace filename with the name of a file containing parameters you wish to use. 2. Using the command line:
Imp80 username/password Parameter_Options
Replace username with your DBA Username and replace password with your DBA password. Replace Parameter_Options with the parameters you wish to use. 3. Interactively: Start an interactive session at the command prompt with the following command:
Imp80 username/password
Replace username with your DBA Username and replace password with your DBA password.
Getting online Import help

Import provides online help by issuing the following Import command:
Imp80 help=y
This command produces the following output on a Users screen:

D:\ORANT\BIN>imp80 help=y Import: release 8.0.3.0.0 - Production on Fri Dec 5 0:1:52 1997 (c) copyright 1997 Oracle Corporation. All rights reserved. You can let Import prompt you for Parameters by entering the IMP Command followed by your username/Password: Example: IMP SCOTT/TIGER Or, you can control how Import runs by entering the IMP command followed by various arguments. To specify Parameters, you use keyword: Format: IMP KEYWORD=Value or KEYWORD=(value1, value2,...,valueN) Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) Full=N or TABLES=(T1:P1,T1:P2), if T1 is Partitioned Table Keyword Description (Default) Keyword Description (Default) ........................................................... USERID username/Password Full Import entire file (N) BUFFER size of data Buffer FROMUSER List of Owner usernames FILE Output file (EXPDAT.DMP) TOUSER List of usernames SHOW just List file contents (N) TABLES List of Table Names
Chapter 17 3 Import
433
IGNORE ignore create errors (N) RECORDLENGTH length of IO record GRANTS Import grants (Y) INCTYPE Incremental Import Type INDEXES Import Indexes (Y) commit commit array Insert (N) ROWS Import data Rows (Y) PARFILE Parameter filename LOG log file of screen Output DESTROY overwrite Tablespace data file (N) INDEXFILE write Table/Index info to specified file CHARSET character set of Export file (NLS_LANG) POINT_IN_TIME_RECOVER Tablespace point-in-time recovery (N) SKIP_UNUSABLE_INDEXES skip maintenance of unusable Indexes (N) ANALYZE execute ANALYZE Statements in dump file (Y) FEEDBACK display progress every x Rows(0) Import terminated successfully without warnings.
Import parameters
Table 17-3 lists every parameter applicable to the Oracle8 Import utility:
Note
Certain parameters conflict if used together. For example, specifying TABLE and USER for the same Export process causes the Export to fail.
Importing grants
To Import the privileges a User has granted to others, the User initiating the Import must either own the Objects or have Object privileges with the WITH GRANT OPTION.
Importing Objects into another Schema

To import Objects into another Users Schema, a User must have the IMP_FULL_DATABASE Role enabled. The following Import statement imports all Tables belonging to AMC into User
TONYs Schema: Imp80 System/manager file=amyc.dmp fromuser=amyc touser=tony
434
Table 17-3 Import Parameters for the IMP80 command

Parameter Default value Y OS dependent Description Specifies whether to execute the SQL ANALYZE statement found in the Export file. Specifies the byte size of the buffer through which data rows are Imported. In general, this value must be large enough to accommodate the largest row. For Tables containing LONG, LOB, BFILE, REF, or ROWID Columns, the rows are inserted in a singular fashion. Specifies the actual character set used at the time of the Export process. Specifies whether a commit should occur after each array insert. By default, a commit occurs after loading each Table. A rollback occurs when there is an error. Dictates whether datafiles should be reused. Specifies whether Export should display a progress meter indicating n number of rows exported. The name of the Export file to import. A list of User Schemas containing Objects to import. By default, all Objects owned by the User are imported. Specifies whether to import the entire Export file. Specifies if grants on Objects should be imported. Specifies how Object creation errors should be handled. If IGNORE=Y, Import overlooks Object creation errors. Specifies the type of incremental Import. The valid values are COMPLETE, INCREMENTAL, and CUMULATIVE. The SYSTEM option imports the most recent version of the system Objects. The RESTORE option imports all of a users database Objects and data. Specifies whether to import Indexes.
ANALYZE BUFFER
CHARSET COMMIT
None N
DESTROY FEEDBACK
N 0
FILE FROMUSER
EXPDAT.DMP
None
FULL GRANTS IGNORE
N Y N
INCTYPE
None
INDEXES
Chapter 17 3 Heading 1
435
Parameter
Default value None None
Description Specifies a file to receive the Index creation commands. Specifies the file to accumulate information (including any error messages) about the Import. Specifies the file containing the list of Export parameters to be used by Export. Specifies whether the Import process recovers one or more Tablespaces used in a point-in-time recovery strategy. Specifies the byte length of an Export file record. Specifies whether row data is imported into their respective Tables. The contents off the Export files are listed to the display and not imported. The SQL statements contained in the Export file are displayed in the order in which Import executes them. Specifies whether to skip building Indexes set to the Index unusable state. Specifies the list of Table names to import. Use an asterisk to import all Tables (for example, TABLES=(*)). Specifies a list of Usernames whose Schemas are imported. The IMP_FULL_DATABASE Role is required to use this parameter. Specifies the Username and password of the User invoking the Import.
INDEXFILE LOG
PARFILE POINT_IN_ TIME_RECOVER RECORDLENGTH ROWS SHOW
Name N
OS Y N
SKIP_UNUSABLE _INDEXES TABLES
N N
TOUSER
None
USERID
To import system Objects from a database Export file, the IMP_FULL_DATABASE Role must be enabled for the User. The Import parameter FULL=Y specifies the following system Objects included in the Import when the Export file is a full database Export: 3 Profiles 3 Public database links 3 Public Synonyms 3 Roles
436
3 Rollback segment definitions 3 System audit options 3 System privileges 3 Tablespace definitions 3 Tablespace quotas 3 User definitions 3 Directory aliases 3 User privileges
Note
When User definitions are imported into an Oracle database, they are created with the CREATE USER command. As a result, when importing from Export files created by previous versions of Export, Users are not granted CREATE SESSION privileges.
Importing into existing Tables

This section describes important factors to consider when importing data into existing Tables: 3 Using manually created Tables. When a User manually creates Tables to import data from an Export file, the same Table DDL should be used. The width and order of Table Columns can be altered, but their datatype class family should not be changed. 3 Disabling referential Constraints. To avoid dependency problems, switch the order in which the data is imported into the Table and manually disable Constraints and referential integrity Constraints. 3 Manually ordering the data. When the Constraints are reenabled after importing, the entire Table is checked. If the time required for the check is too long, especially for a large Table, the Import should be manually ordered. To accomplish this task, complete several (instead of one) Imports from an Export file. First import the Tables that are the targets of referential checks before importing the Tables referencing the first group. This option succeeds if Tables do not reference each other in circular fashion and if a Table does not reference itself.
Importing complete, incremental, and cumulative Export files

An incremental Export only extracts Tables changed since the last incremental, cumulative, or complete Export. An Import from an incremental Export file imports the Table definition and all data not just the changed rows. Because importing an incremental Export file imports new versions of existing Objects, the existing Objects are dropped and new Objects imported.
Chapter 17 3 Heading 1
437
The execution order of incremental, cumulative, and complete Exports is extremely important. A set of Objects cannot be restored until a complete Export runs on a database; after completion, cumulative and incremental Imports can be performed. Use the following tasks as a template for importing data from incremental and cumulative Exports: 3 Import the most recent complete Export file.
IMP80 System/manager INCTYPE=RESTORE Full=Y FILE=EXPFULL.DMP
3 Import all cumulative Export files after the last complete Export.
IMP80 System/manager INCTYPE=RESTORE Full=Y FILE=EXPCUM1.DMP IMP80 System/manager INCTYPE=RESTORE Full=Y FILE=EXPCUM2.DMP IMP80 System/manager INCTYPE=RESTORE Full=Y FILE=EXPCUM3.DMP
3 Import all incremental Export files after the last cumulative Export.
IMP80 System/manager INCTYPE=RESTORE Full=Y FILE=EXPINC1.DMP IMP80 System/manager INCTYPE=RESTORE Full=Y FILE=EXPINC2.DMP
Understanding Table -level and partition-level Imports

Table-level Imports have the following characteristics: 3 All Rows are imported for each specified Table. 3 All Tables exported using any Export mode can be Imported. 3 Users can Import partitioned or nonpartitioned Tables into partitioned or nonpartitioned target Tables with the same name. Partition-level Imports have the following characteristics: 3 A set of partitions is imported from a source Table into a target Table. 3 A partition-level Import can be only specified in the Import Table mode. 3 Partition-level Exports and Imports provide a way to merge partitions into the same Table, even though SQL does not allow this procedure. A DBA can use partition-level Imports to merge a Table partition into the next highest partition on the same Table. A list of guidelines for using partition-level Imports follows: 3 A partition-level Import is only legal if the source Table is partitioned. 3 If the Import parameter ROWS is set to Y and the source partition Table does not exist in the Import target database, the partition is created. 3 If the Import parameter ROWS is set to Y and the partition Table exists in the Import target database, the imported rows are inserted according to the partitioning scheme of the target Table.
438
3 If the Import parameter ROWS is set to N, the Import process does not insert data into the target Table. 3 If the target Table is nonpartitioned, the partitions are imported into the entire Table. The Import parameter IGNORE must be set to Y for this action to occur. 3 A partition-level Import cannot import a nonpartitioned exported Table. A partitioned Table can be imported from a nonpartitioned exported Table using a Table-level Import, however.
Example
The following Import statement imports rows from the XROS1 partition of the Table AMYC.STUDENTS into the XROS1 partition of the target Table AMYC.STUDENTS:
Imp80 System/manager FILE=AMYC.DMP FROMUSER amyc TABLE=STUDENTS:XROS1
The following Import statement imports causes data from the XROS1 and XROS2 partitions to be imported into AMYC.STUDENTS:
Imp AMY/CHANDI FILE=AMYC.DMP TABLES=(STUDENTS:XROS1, STUDENTS:XROS2) IGNORE=Y
With the IGNORE parameter set to Y, a STUDENTS Table is created and data inserted into the same Partitions if such a Table does not exist on the Import target system.
Import error handling

The three types of Import utility errors follow: 3 Errors from bad Import data 3 Errors from the database Objects being imported 3 Errors from the depths of the Oracle8 internals If the Import utility experiences bad data errors for a particular Table, it displays a soft error message. The bad Table is skipped and the Import utility starts importing the next Tables data in the Export file. The most common cause of a bad data error is an integrity Constraint violation. If a database Object already exists, an Object creation error is raised. This error is only reported if the Import parameter IGNORE is set to Y; otherwise, the error goes unnoticed. Such an error usually does not stop the Import process. Errors from the Oracle8 internals cause the Import process to abort instantly. A log file can be assigned to the Import process to capture every Import message and error. Assigning a file name to the LOG parameter of the Import command creates a log of the Import process. For example:
Chapter 17 3 Summary
439
IMP80 AMY/CHANDI PARFILE=AMYC.EXP LOG=D:\ORANT\Backup\AMYC.LOG
Summary
It is difficult to separate backup and recovery as two chapters in terms of reading content, as they go hand-in-hand. But, for the ease of reading and referencing, I have presented them separated. Thus, reading through the chapter, you notice Oracle8 data structures common to both of the topic areas. The data structures used in both the Oracle8 Backup and Recovery processes are the supportfor the mechanisms . To master both operartions, you must understand their characteristics, use, and roles. The following key points can summarize this chapter: 3 The terms restoring and recovering a database file are not indentical. 3 The following Oracle8 data structures are used by the recovery process: The Control File Rollback segments Redo entries Online redo log files System Change Number Checkpoint 3 An Oracle8 Server can experience two types of failures throughout its life: Instance Media 3 Regardless of the type of failure, instance or media, the Oracle8 database must be brought back to a consistent state. 3 Oracle8 performs the Instance Recovery process is automatically. 3 There are two types of Media Recovery, Complete and Incomplete that can be performed at the following levels: Database Tablespace Datafile
440
3 The Oracle8 Recovery process can be performed by the following mechanisms: 3 The new Recovery Manager tool 3 The SQL RECOVER command 3 The NT Recovery Manager The Oracle8 Recovery process is a very critical process as in theory it should only be performed when the database experiences an instance or media failure. This theory leads to a misconception to its importance in the production environment. In reality, the Oracle8 Recovery process should be proactive and not reactive. It should be rehearsed as many times as a stage play, leading to a fault free operation upon disaster.

Oracle8 Recovery: in This Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle8 Recovery: in This Chapter

Uploaded by

Copyright:

Available Formats

Oracle8 Recovery

Chapter 17 3 Oracle8 Recovery

Oracle8 Recovery Data Structures

Chapter 17 3 Oracle8 Recovery Data Structures

Chapter 17 3 Oracle8 Recovery

The online redo log file

Chapter 17 3 Oracle8 Recovery Data Structures

System change number

Low and high SCN values

Stop SCN values

Chapter 17 3 Oracle8 Recovery

Chapter 17 3 Oracle8 Recovery Principles

Oracle8 Recovery Principles

Chapter 17 3 Oracle8 Recovery

See Reference Section

The stages of an Oracle8 instance startup

Stage 1. Starting an Oracle8 instance without mounting the database

Chapter 17 3 Oracle8 Recovery Principles

12071016 46136 11090992 409600 524288

Bytes Bytes Bytes Bytes Bytes

Stage 2. Mounting an Oracle8 database

Stage 3. Opening an Oracle8 database

Chapter 17 3 Oracle8 Recovery

Oracle8 recovery intelligence

Chapter 17 3 Oracle 8 Failure

The Oracle8 recovery process

Chapter 17 3 Oracle8 Recovery

Table 17-1 Oracle Failures and How To Recover

Oracle8 recovery analysis

Figure 17-2: A simple scenario of an Oracle8 database

Chapter 17 3 Oracle 8 Failure

Instance automatic recovery

Chapter 17 3 Oracle8 Recovery

Media (Disk) Recovery

Chapter 17 3 Media (Disk) Recovery

Types of media recovery

Guidelines for media recovery

Restoring a database in NOARCHIVELOG mode

Chapter 17 3 Oracle8 Recovery

Chapter 17 3 Media (Disk) Recovery

RECOVER DATABASE RECOVER TABLESPACE RECOVER DATAFILE

Performing complete recovery

Closed database recovery

Chapter 17 3 Oracle8 Recovery

Open database, offline Tablespace recovery

Chapter 17 3 Media (Disk) Recovery

4. Recover the restored Tablespace by issuing the RECOVER TABLESPACE command.

Open database, offline Tablespace, individual datafile recovery

6. Recover the restored datafiles by issuing the RECOVER DATAFILE command.

Chapter 17 3 Oracle8 Recovery

Performing incomplete media recovery

Chapter 17 3 Media (Disk) Recovery

Performing incomplete media recovery

Chapter 17 3 Oracle8 Recovery

If Oracle8 finds the datafile already online, the statement is ignored.

6. Recover the database using one of the following UNTIL options:

User or application failure

Chapter 17 3 Media (Disk) Recovery

Figure 17-3: Oracle8s Recovery Manager

Using Recovery Manager

Chapter 17 3 Oracle8 Recovery

Stored Scripts and CLI

Chapter 17 3 Media (Disk) Recovery