Release 2 (8.1.6)
Part Number A76993-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Backup and Recovery Guide Release 2 (8.1.6) Part Number A76993-01 |
|
This chapter introduces database concepts that are fundamental to backup and recovery. It is intended as a general overview. Subsequent chapters explore backup and recovery concepts in greater detail.
This chapter includes the following topics:
A backup is a copy of data. This copy can include important parts of your database such as the control file and datafiles. A backup is a safeguard against unexpected data loss and application errors; if you lose the original data, then you can use the backup to reconstruct it.
Backups are divided into physical backups and logical backups. Physical backups, which are the primary concern of this guide, are copies of physical database files. In contrast, logical backups contain data that you extract using the Oracle Export utility and store in a binary file. You can use logical backups to supplement physical backups. You can make physical backups using either the Oracle8i Recovery Manager utility or operating system utilities.
To restore a physical backup is to reconstruct it and make it available to the Oracle database server. To recover a restored datafile is to update it using redo records, that is, records of changes made to the database after the backup was taken. If you use Recovery Manager (RMAN), then you can also recover restored datafiles using incremental backups, which are backups of a datafile that contain only blocks that changed after the last backup.
Oracle performs crash recovery and instance recovery automatically after an instance failure. Instance recovery is an automatic procedure that involves two distinct operations: rolling forward the backup to a more current time by applying online redo records and rolling back all changes made in uncommitted transactions to their original state.
In contrast to instance recovery, media recovery requires you to issue recovery commands. If you use SQL*Plus, then you can issue the RECOVER or ALTER DATABASE RECOVER statements to apply the archived logs. If you use RMAN, then you issue the recover command to apply archived redo logs or incremental backups to the datafiles.
Figure 1-1 illustrates the basic principle of backing up, restoring, and performing media recovery on a database:
Recovery in general refers to the various operations involved in restoring, rolling forward, and rolling back a backup. Backup and recovery in general refers to the various strategies and operations involved in protecting your database against data loss and reconstructing the data should that loss occur.
|
See Also:
|
To understand the basics of backup and recovery, you need to understand how Oracle records changes to a database. Every time a change is made, Oracle generates a record of both the changed and original value in the redo log buffer in memory. This record is called a redo record. Oracle records both committed and uncommitted changes in redo log buffers.
Oracle frequently writes the redo log buffers to the on-disk online redo log. The online redo log contains at least two online redo log files. Oracle writes to these logs in a circular fashion: first it writes to one log file, then switches to the next available file when the current log is full, then back to the other file, and so forth.
Depending on whether Oracle runs in ARCHIVELOG or NOARCHIVELOG mode, the system begins archiving the redo information in the non-current online redo log file by copying the file to specified locations on disk. The online and archived redo logs are crucial for recovery because they contain records of all changes to the database.
|
See Also:
|
A physical backup is a copy of a datafile, tablespace, or database made at a specific time. If you make periodic backups of a database, then you can perform media recovery using these backups. During media recovery, you apply redo records or incremental backups to a restored backup to bring the database forward in time. If the backup is a consistent backup, then you can also restore the backup without performing recovery.
Oracle enables you to restore an older backup and apply partial redo data, thereby recovering the database to a specified non-current time or SCN. This type of recovery is called incomplete recovery. You must open your database with a RESETLOGS operation after performing incomplete recovery in order to reset the online redo logs.
An example helps illustrate the concept of media recovery. Assume that you make a backup of your database at noon. Starting at noon, one change to the database is made every second. The redo logs switch three times over the next hour, and because the database runs in ARCHIVELOG mode, these redo logs are archived to disk. At 1:00 p.m., your disk drive fails. Fortunately, you can restore your noon whole database backup onto a functional disk drive and, using the archived redo logs to recover the database to 1:00 p.m., apply the changes so that the database is back to its pre-failure state.
|
See Also:
"Making Consistent Whole Database Backups" to learn how to make consistent backups using operating system methods, and Chapter 5, "Performing Media Recovery" to learn how to perform media recovery using SQL*Plus. |
Although backup and recovery operations can sometimes be complicated, the basic principles for developing an effective strategy are simple:
Most backup and recovery techniques are variations on these principles. So long as you have backups of your datafiles, control files, and archived redo logs in safe storage, then even if a fire were to completely destroy your hardware, you can recreate your original database.
A sophisticated and effective disaster prevention technique is to maintain a standby database, which is an exact replicate of your production database that you can update automatically with archived redo logs propagated through a Net8 connection.
|
See Also:
|
Before you can begin thinking seriously about backup and recovery strategy, you need to understand the physical data structures that are relevant for backup and recovery operations. This section addresses the following topics:
This manual covers these topics in more detail in subsequent chapters.
|
See Also:
Oracle8i Concepts for a complete overview of the Oracle8i architecture, and Oracle8i Administrator's Guide to learn how to manage these data structures. |
Every Oracle database has one or more physical datafiles. A database's datafiles, which belong to logical structures called tablespaces, contain the database data. The datafile is divided into smaller units called data blocks. The data of logical database structures such as tables and indexes is physically located in the blocks of the datafiles allocated for a database.
The first block of every datafile is the header. The header includes important control information such as file size, block size, tablespace, creation timestamp, and checkpoint SCN (see "System Change Number (SCN)"). Whenever you open a database, Oracle checks the datafile header information against the information stored in the control file to determine whether recovery is necessary.
Oracle reads the data in a datafile during normal operation and stores it in the in-memory buffer cache. For example, assume that a user wants to access some data in a table. If the requested information is not already in the buffer cache, Oracle reads it from the appropriate datafiles and stores it in memory.
The background process DBWn, known as the database writer or db writer, writes modified buffers to disk. Typically, a time lapse occurs between the time when an Oracle server process changes a block in the buffer cache and the time when DBWn writes it to disk. The more data that accumulates in memory without being written to disk, the longer the instance recovery time, because a crash or media failure forces Oracle to apply redo data from the current online log to recover those changes. Minimizing this time, known as the mean time to recover (MTTR), is an important aspect of backup and recovery strategy.
|
See Also:
Oracle8i Designing and Tuning for Performance for more information on parameters that you can use to influence the MTTR. |
Every Oracle database has a control file. A control file is an extremely important binary file that contains the operating system filenames of all other files constituting the database. It also contains consistency information that is used during recovery, such as:
When multiplexing the control file, you configure Oracle to write multiple copies of it in order to protect it against loss. If your operating system supports disk mirroring, you can also mirror the control file, that is, configure the operating system to write a copy of the control file to multiple disks.
|
See Also:
"Maintaining Multiple Control Files" for more information about multiplexing and mirroring the control file, and Oracle8i Administrator's Guide for general information about managing the control file. |
Every time you mount an Oracle database, its control file is used to identify the datafiles and online redo log files that must be opened for database operation. If the physical makeup of the database changes, for example, a new datafile or redo log file is created, then Oracle modifies the database's control file to reflect the change.
The control file also contains crucial checkpoint information. The checkpoint records the highest SCN of all changes to blocks such that all data blocks with changes below that SCN have been written to disk by DBWn. The control file also contains a record of the checkpoint SCN contained in the header of each datafile in the database. Whenever a discrepancy occurs between the SCN that is actually in a datafile header and the datafile header SCN listed in the control file, Oracle requires media recovery.
The control file is absolutely crucial for database operation. Back up the control file whenever the set of files that makes up the database changes. Examples of structural changes include adding, dropping, or altering datafiles or tablespaces and adding or dropping online redo logs.
|
See Also:
"Backing Up the Control File After Structural Changes" to learn how to back up the control file. |
Every database contains one or more rollback segments, which are logical structures contained in datafiles. Whenever a transaction modifies a data block, a rollback segment records the state of the information before it changed.
Oracle uses rollback segments for a variety of operations. In general, the rollback segments of a database store the old values of data changed by uncommitted transactions. For example, if DBWn writes an uncommitted change to a data block and a session accesses the block in a query, then a rollback segment is used to display the pre-change value to the user.
Oracle can use the information in a rollback segment during database recovery to undo any uncommitted changes applied from the redo log to the datafiles, putting the data into a consistent state.
Every Oracle database has a set of two or more online redo log files. Oracle assigns every redo log file a unique log sequence number to identify it. The set of redo log files for a database is collectively known as the database's redo log. Oracle uses the redo log to record all changes made to the database.
Oracle records every change in a redo record, which is an entry in the redo buffer describing what has changed. For example, assume a user updates a column value in a payroll table from 5 to 7. Oracle records the change to the datafile block (new value of 7) and rollback segment (old value of 5) in a redo record. Because the redo log stores every change to the database, the redo record for this transaction actually contains three parts:
Each atomic change in a redo record is called a change vector. A redo record is composed of all the change vectors involved in a change. For example, if you update all the values in a multi-column row in a table, then Oracle generates a redo record containing change vectors for all the changed blocks corresponding to each updated value.
If you then commit the update, Oracle generates another redo record and assigns the change an SCN. In this way, the system maintains a careful watch over everything that occurs in the database.
The log writer background process (LGWR) writes to online redo log files in a circular fashion: when it fills the current online redo log, LGWR writes to the next available inactive redo log. LGWR cycles through the online redo log files in the database, writing over old redo data. Filled redo log files are available for reuse depending on whether archiving is enabled:
The system change number (SCN) is an ever-increasing internal timestamp that uniquely identifies a committed version of the database. Every time a user commits a transaction, Oracle records a new SCN. You can obtain SCNs in a number of ways, for example, from the alert log. You can then use the SCN as an identifier for purposes of recovery. For example, you can perform an incomplete recovery of a database up to SCN 1030.
Oracle uses SCNs in control files, datafile headers, and redo records. Every redo log file has both a log sequence number and low and high SCN. The low SCN records the lowest SCN recorded in the log file, while the high SCN records the highest SCN in the log file.
Redo logs are crucial for recovery. For example, suppose that a power outage prevents Oracle from permanently writing modified data to the datafiles. In this situation, you can use an old version of the datafiles combined with the changes recorded in the online and archived redo logs to reconstruct what was lost.
To protect against redo log failure, Oracle allows the redo log to be multiplexed. When Oracle multiplexes the online redo log, it maintains two or more copies of the redo log on different disks. Note that you should not back up the online redo log files, nor should you ever need to restore them; you keep redo logs by archiving them.
|
See Also:
|
An archived redo log is an online redo log that Oracle has filled with redo entries, rendered inactive, and copied to one or more destinations specified in the parameter file. You can run Oracle in either of two archive modes:
|
ARCHIVELOG |
Oracle archives the filled online redo log files before reusing them in the cycle. |
|
NOARCHIVELOG |
Oracle does not archive the filled online redo log files before reusing them in the cycle. |
Running the database in ARCHIVELOG mode has the following consequences:
Running the database in NOARCHIVELOG mode has the following consequences:
"Managing the Archived Redo Logs" for more information on archiving redo logs, and Oracle8i Standby Database Concepts and Administration for more information about the standby database option.
See Also:
A physical backup is a copy of a datafile, control file, or archived redo log that you store as a safeguard against data loss. When thinking about a backup strategy, consider these questions:
Imagine the magnitude of lost revenue--not to mention the degree of customer dissatisfaction--if the production database of a catalog company, express delivery service, bank, or airline suddenly becomes unavailable, even for just 5 or 10 minutes. Alternatively, imagine that you lose important payroll datafiles due to a hard disk crash and cannot restore or recover them because you do not have a backup. Depending on the size and value of the lost information, the results can be devastating.
By making frequent backups, you ensure that you can restore at least some of your lost data. If you run you database in ARCHIVELOG mode, then you can apply redo to restored backups in order to reconstruct all lost changes.
You can lose or corrupt data in a variety of ways; you should consider these various possibilities when developing your backup strategy. The most common types of failures causing data loss are:
|
See Also:
"Planning Your Response to Non-Media Failures" and "Planning Your Response to Media Failures" to learn about the most common type of failures affecting the database. |
When developing your backup strategy, you need to know which types of backups you can perform. In each type of physical backup you either back up a file or group of files. This section defines and describes:
Logical backups, also known as exports, are described in detail in Oracle8i Utilities.
A whole database backup should include backups of the control file along with all datafiles. Whole database backups are the most common type of backup.
Whole database backups do not require you to operate the database in a specific archiving mode. Before performing whole database backups, however, be aware of the implications of backing up in ARCHIVELOG and NOARCHIVELOG modes (see "Choosing the Database Archiving Mode").
Figure 1-1 illustrates the various options available to you when performing whole database backups:
Whole database backups can be consistent or inconsistent. Whether or not the backup is consistent determines whether you need to apply redo logs after restoring the backup.
|
See Also:
|
A tablespace backup is a backup of the datafiles that constitute the tablespace. For example, if tablespace TBS_2 contains datafiles 2, 3, and 4, then a backup of tablespace TBS_2 backs up these three datafiles.
Tablespace backups, whether online or offline, are only valid if the database is operating in ARCHIVELOG mode. The reason is that redo is required to make the restored tablespace consistent with the other tablespaces in the database.
The only time a tablespace backup is valid for a database running in NOARCHIVELOG mode is when the tablespace is currently read-only or offline-normal. These cases are exceptions because no redo is required to recover them. For example, take the scenario depicted in Figure 1-3:
Because there were necessarily no changes to the offline tablespace between t + 5 and t + 10, Oracle does not require media recovery. If you make the tablespace read-write at t + 15 and then subsequently attempt to restore the t + 5 backup, however, Oracle requires media recovery for the changes after t + 15. Consequently, you are only be able to open the database if all necessary redo is located in the online redo logs.
A datafile backup is a backup of a single datafile. Datafile backups, which are not as common as tablespace backups, are valid in ARCHIVELOG databases.
The only time a datafile backup is valid for a database in NOARCHIVELOG mode is if every datafile in a tablespace is backed up. You cannot restore the database unless all datafiles are backed up. The datafiles must be read-only or offline-normal.
If the database is mounted, you can make a binary backup up your control file using the ALTER DATABASE statement. You can also back up the control file to a trace file. Note that trace file backups have one major disadvantage: they have no record of any previous backups made with the old control file.
|
See Also:
"Backing Up the Control File After Structural Changes" to learn how to make control file backups using SQL*Plus, and "Performing Control File Backups" to learn how to make control file backups using SQL commands. |
You can use RMAN or operating system commands to make an inconsistent or a consistent backup. An inconsistent backup is a backup of one or more database files that you make while the database is open or after the database has been shut down abnormally. A consistent backup is a backup of one or more database files that you make after the database has been closed cleanly. Unlike an inconsistent backup, a consistent backup does not require instance recovery after it is restored.
Whether you make consistent or inconsistent backups depends on a number of factors. If your database must be open and available all the time, then inconsistent backups are your only option. If there are recurring periods of minimal use, then you may decide to take regular consistent backups of the whole database and supplement them with online backups of often-used tablespaces.
A consistent backup of a database or part of a database is a backup in which all read-write datafiles and control files have been checkpointed with respect to the same SCN. In addition, all the online, read-write datafiles are not fuzzy, that is, do not contain changes beyond the SCN in the header. Oracle determines whether a restore backup is consistent by checking all the datafile headers against the datafile header information contained in the control file.
Oracle makes the control files and datafiles consistent during a database checkpoint. The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to these tablespaces and so no recovery is required. If the offline datafile's checkpoint SCN matches the offline-SCN in the control file, then Oracle know the datafile needs no redo.
The important point is that you can open the database after restoring a consistent whole database backup without applying redo logs because the data is already consistent: no action is required to make the data in the restored datafiles correct. Consequently, you can restore a year-old consistent backup of your database without performing media recovery and without Oracle performing instance recovery.
The only way to make a consistent whole database backup is to shut down the database using the NORMAL or IMMEDIATE options and make the backup while the database is closed. If a database is not shut down cleanly, for example, an instance fails or you issue a SHUTDOWN ABORT statement, the database's datafiles are always inconsistent--unless you opened the database in read-only mode. Instance recovery will be required at open time.
A consistent whole database backup is the only valid backup option for databases running in NOARCHIVELOG mode, because otherwise redo will need to be applied to create consistency--and in NOARCHIVELOG mode Oracle overwrites redo records without archiving them first.
To make a consistent database backup current or to take it to a non-current point in time, perform media recovery. If you use a current control file for recovery, Oracle starts media recovery beginning at the lowest checkpoint SCN in the datafile headers. If you use a backup control file, then Oracle starts media recovery using the lowest of the following: the control file SCN and the lowest SCN in the datafile headers.
To perform media recovery either apply archived redo logs or, if you are using Recovery Manager, apply incremental backups and/or archived logs. All redo data is located in the archived and online redo logs.
An inconsistent backup s a backup in which all read-write datafiles and control files have not been checkpointed with respect to the same SCN. For example, one read-write datafile header may contain an SCN of 100 while others contain an SCN of 95. Oracle cannot open the database until these SCNs are consistent, that is, until all changes recorded in the online redo logs have been made to the datafiles.
If your database must be up and running 24 hours a day, 7 days a week, then you have no choice but to perform inconsistent backups of a whole database. For example, a backup of an offline tablespace in an open database is inconsistent with other tablespaces because portions of the database are being modified and written to disk while the backup of the tablespace is progressing. The datafile headers for the online and offline datafiles may contain inconsistent SCNs. You must run your database in ARCHIVELOG mode to make open backups.
If you run the database in ARCHIVELOG mode, then you can construct a whole database backup using backups of datafiles taken at different times. For example, if your database contains seven tablespaces, and you back up the control file as well as a different tablespace each night, in a week you will back up all tablespaces in the database as well as the control file. You can consider this backup as a whole database backup.
You have the option of making inconsistent closed backups if a database is backed up after a system crash or SHUTDOWN ABORT. This type of backup is valid if the database is running in ARCHIVELOG mode, because both online and archived redo logs are available to make the backup consistent.
If you run your database in NOARCHIVELOG mode, only back it up when you have closed it cleanly using the IMMEDIATE or NORMAL options. Inconsistent whole database backups of databases running in NOARCHIVELOG mode are usable only if the redo logs containing the changes made prior to the backup are available when you restore it--an unlikely occurrence.
The reason that NOARCHIVELOG inconsistent backups are not recommended is that the datafile headers of the backed up files contain different SCNs (a normal shutdown guarantees the consistency of these SCNs), and because the database is in NOARCHIVELOG mode, no archived redo logs are available to apply the lost changes. For this reason, RMAN does not allow you to back up a database that has been running in NOARCHIVELOG mode and shut down abnormally because the backup is not usable for recovery.
The moral is: if you run your database in NOARCHIVELOG mode, always have a backup that is usable without performing any recovery. This aim is defeated if you need to apply redo from logs to recover a backup. If you need redo data to make a database consistent, operate in ARCHIVELOG mode.
After open or inconsistent closed backups, always guarantee that you have the redo necessary to recover the backup by archiving the unarchived redo logs. When the database is open, issue the following SQL statement to force Oracle to switch out of the current log and archive it as well as all other unarchived logs:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
When the database is mounted, open, or closed, issue the following SQL statement to force Oracle to archive all non-current redo logs:
SQL> ALTER SYSTEM ARCHIVE LOG ALL;
When the database is mounted, open, or closed, issue the following SQL statement to archive a specified log group, where integer is the number of the group:
SQL> ALTER SYSTEM ARCHIVE LOG GROUP integer;
After open or inconsistent closed backups, back up all archived redo logs produced since the backup began. This operation ensures that you can use the backup and also allows you to delete the original archived logs from disk. If you do not have all archived redo logs produced during the backup, you cannot recover the backup because you do not have all the redo records necessary to make it consistent.
Also, make a binary backup up your control file using the ALTER DATABASE statement.
|
See Also:
"Performing Control File Backups" for more information about backing up the control file using SQL statements. |
|
See Also:
"Backing Up Online Tablespaces and Datafiles" to learn how to make online backups using operating system methods, and Oracle8i Recovery Manager User's Guide and Reference to learn how to use RMAN to make backups. |
The set of files needed to recover from the failure of a database file--a datafile, control file, or online redo log--is called the redundancy set. The golden rule of backup and recovery is: the set of disks or other media that contain the redundancy set should be separate from the disks that contain the datafiles, online redo logs, and control files. This strategy ensures that the failure of a disk that contains a datafile does not also cause the loss of the backups or redo logs needed to recover the datafile.
|
See Also:
"Obeying the Golden Rule of Backup and Recovery" to learn more the redundancy set and how to maintain it. |
In Oracle8i, you have a choice between these basic methods for making backups:
Table 1-1 describes the version and system requirements for the these methods:
|
See Also:
Oracle8i Recovery Manager User's Guide and Reference for an overview of Recovery Manager features. |
RMAN is a powerful and versatile program that allows you to make a backup or image copy of your data. When you specify files or archived logs using the RMAN backup command, RMAN creates a backup set as output.
A backup set is one or more datafiles, control files, or archived redo logs that are written in an RMAN-specific format; it requires you to use the RMAN restore command for recovery operations. In contrast, when you use the copy command to create an image copy of a file, you do not need to invoke RMAN to restore or recover it.
|
See Also:
Oracle8i Recovery Manager User's Guide and Reference for an introduction to RMAN as well as instructions for making backups and copies. |
If you do not want to use RMAN, you can use operating system commands such as the UNIX cp command to make backups. You can also automate backup operations by writing scripts.
You can make a backup of the whole database at once or supplement a whole database backup with backups of individual tablespaces, datafiles, control files, and archived logs. You can use operating system commands to perform these backups.
|
See Also:
Chapter 4, "Performing Operating System Backups" to learn how to make operating system backups. |
You can supplement physical backups by using the Export utility to make logical backups of your data. Logical backups store information about the schema objects created for a database. The Export utility writes data from a database into Oracle files in a proprietary format. You can then import this data into a database using the Import utility.
Table 1-2 compares the features of the different backup methods:
Tailor your backup strategy to the needs of your business. For example, if you can afford to lose data in the event of a disk failure, then you may not need to perform backups very often. The advantage of taking infrequent backups is that you free Oracle's resources for other operations. The disadvantage is that you may end up losing data or increasing recovery time.
In a different scenario, if your database must be available twenty-four hours a day, seven days a week, then you should make online backups of your database frequently. In this case, you may decide to take daily hot backups, multiplex (that is, have multiple copies of) your online redo logs, and archive your redo logs to several different locations. You can even maintain a standby database in a different city that is a constantly updated replica of your original database.
|
See Also:
Chapter 3, "Developing a Backup and Recovery Strategy" to learn important considerations for an effective backup strategy. |
Basic media recovery involves two parts: restoring a physical backup and updating it with database changes. The most important aspect of recovery is making sure that all datafiles are consistent with respect to the same SCN. Oracle has integrity checks that prevent you from opening the database until all datafiles are consistent with one another.
When preparing a recovery strategy, make sure you understand the answers to these questions:
Media recovery uses redo records or (if you use RMAN) incremental backups to recover restored datafiles either to the present or to a specified non-current time. When performing media recovery, you can recover the whole database, a tablespace, or a datafile. In any case, you always use a restored backup to perform the recovery.
This section contains the follow topics:
Complete recovery involves using redo data or incremental backups combined with a backup of a database, tablespace, or datafile to update it to the most current point in time. It is called complete because Oracle applies all of the redo changes to the backup. Typically, you perform media recovery after a media failure damages datafiles or the control file.
You can perform complete recovery on a database, tablespace, or datafile. If you are performing complete recovery on the whole database, then you must:
If you are performing complete recovery on a tablespace or datafile, then you must:
"Performing Complete Media Recovery" to learn how to perform complete media recovery using operating system methods, and Oracle8i Recovery Manager User's Guide and Reference to learn how to perform complete recovery with RMAN.
See Also:
Incomplete recovery uses a backup to produce a non-current version of the database. In other words, you do not apply all of the redo records generated after the most recent backup. You usually perform incomplete recovery when:
To perform incomplete media recovery, you must restore all datafiles from backups created prior to the time to which you want to recover and then open the database with the RESETLOGS option when recovery completes. The RESETLOGS operation creates a new incarnation of the database--in other words, a database with a new stream of log sequence numbers.
The tablespace point-in-time recovery (TSPITR) feature enables you to recover one or more tablespaces to a point-in-time that is different from the rest of the database. TSPITR is most useful when you want to:
Chapter 7, "Performing Operating System Tablespace Point-in-Time Recovery" to learn how to perform O/S TSPITR, and Oracle8i Recovery Manager User's Guide and Reference to learn how to perform TSPITR using RMAN.
See Also:
Because you are not completely recovering the database to the most current time, you must tell Oracle when to terminate recovery. You can perform the following types of recovery.
|
See Also:
Oracle8i Recovery Manager User's Guide and Reference to learn how to perform incomplete recovery with RMAN, and "Performing Incomplete Media Recovery" to learn how to perform incomplete media recovery using SQL*Plus. |
Whenever you perform incomplete recovery or perform complete or incomplete recovery using a backup control file, you must reset the online redo logs when you open the database. The new version of the reset database is called a new incarnation. All archived redo logs generated after the point of the RESETLOGS on the old incarnation are invalid in the new incarnation.
|
See Also:
"Opening the Database After Media Recovery" to learn how to restart the database in RESETLOGS mode. |
You have a choice between two basic methods for recovering physical files. You can:
Whichever method you choose, you can recover a database, tablespace, or datafile. Before performing media recovery, you need to determine which datafiles to recover. Often you can use the fixed view V$RECOVER_FILE.
|
See Also:
Chapter 5, "Performing Media Recovery" to learn how to perform operating system recovery, and Oracle8i Recovery Manager User's Guide and Reference to learn how to perform recovery with RMAN. |
If you do not use RMAN, follow these basic steps:
If you cannot restore a datafile to its original location, relocate the restored datafile and change the location in the control file.
The basic RMAN recovery commands are restore and recover. Use RMAN to restore datafiles from backup sets or from image copies on disk, either to their current location or to a new location. You can also restore backup sets containing archived redo logs. Use the RMAN recover command to perform media recovery and apply incremental backups. RMAN completely automates the procedure for recovering and restoring your backups and copies.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|