Oracle records the old value in a rollback segment and the new value in a redo record. Conveniently, RMAN automatically establishes the names and locations of all the files that you need to back up. If your database must be open and available all the time, then inconsistent backups are your only option. As the diagram illustrates, you generate new changes in the new incarnation of the database, eventually reaching SCN 4000. A problem that prevents an Oracle instance, i.e., the SGA and background processes, from continuing to function. Oracle uses rollback segments for a variety of operations. You can perform complete recovery on a database, tablespace, or datafile. For an overview of Recovery Manager features, see Chapter 4, "Recovery Manager Concepts". If you then try to recover the database using the old archived log 100, you run the risk of corrupting your datafiles or generating internal errors. 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. Use the Enterprise Backup Manager (EBU) for Oracle7 databases. Oracle uses the redo log to record all changes made to the database.
If the media manager is capable of making a proxy copy, then it can perform the data transfer in backup and restore operations. 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. It is called complete because Oracle applies all of the redo changes to the backup. Your database contains a wide variety of types of data. See Also: To learn important considerations for an effective backup strategy, see Chapter 3, "Developing a Backup and Recovery Strategy". Examples of structural changes include adding, dropping, or altering datafiles or tablespaces and adding or dropping online redo logs. You cannot restore backups from before SCN 2500 in the old incarnation to the new incarnation. To learn how to perform complete media recovery using O/S methods, see "Performing Complete Media Recovery". Before performing recovery, you need to: If you cannot restore a datafile to its original location, relocate the restored datafile and inform the control file of the new location. In contrast to instance recovery, media recovery requires you to issue recovery commands. : When the primary site fails, the backup site takes over the processing and becomes the new primary site. The most common types of failures causing data loss are: A logical failure in the handling of a statement in an Oracle program. Whenever a transaction modifies a data block, a rollback segment records the state of the information before it changed. The only time you can recover a database while operating in NOARCHIVELOG mode is when you have not already overwritten the online log files that were current at the time of the most recent backup. For example, assume a user updates a column value in a payroll table from 5 to 7. Should You Make Consistent or Inconsistent Backups? You should probably back up this tablespace frequently; in this way, you will not have to apply as much redo data during recovery. Chapter 13, "Performing Operating System Backups", Chapter 14, "Performing Operating System Recovery", "Making Consistent Whole Database Backups", Chapter 3, "Developing a Backup and Recovery Strategy", Chapter 16, "Managing a Standby Database", "Backing Up the Control File After Structural Changes". See Also: To learn more about the mechanics of Oracle recovery, see Oracle8i Concepts.
Oracle records every change in a redo record, which is an entry in the redo buffer describing what has changed. 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. The new version of the reset database is called a new incarnation. After power is restored, the database performs a crash recovery operation: it uses the redo log to roll forward the value from 5 to 7, then uses the rollback segment to undo the uncommitted change from 7 to 5. See Also: To learn more about managing important data structures such as the online redo logs, see Chapter 2, "Managing Data Structures". Oracle performs crash recovery and instance recovery automatically after an instance failure.
To learn how to perform media recovery, see Chapter 14, "Performing Operating System Recovery". The log before the missing log contains SCN 2500, so you recover to this point and open with the RESETLOGS option. There is, however, an exception to the rule: you can restore a pre-RESETLOGS backup only if Oracle does not need to access archived redo logs from before the RESETLOGS to perform recovery.
When you back up the entire database after shutting it down cleanly, it is called a consistent whole database backup. To allow recovery from user errors and accommodate other unique recovery requirements, Oracle provides for database point-in-time recovery (DBPITR) or tablespace point-in-time recovery (TSPITR). For example, you can perform an incomplete recovery of a database up to SCN 1030. You can then use the SCN as an identifier for purposes of recovery. To learn more about developing a backup and recovery strategy, see Chapter 3, "Developing a Backup and Recovery Strategy". As we have seen, basic media recovery involves two parts: restoring a physical backup and updating it with database changes. Oracle enables you to restore an older backup and apply only some redo data, thereby recovering the database to a specified time or SCN. See Also: To learn how to restore database files, see "Restoring Datafiles, Control Files, and Archived Redo Logs". Unfortunately, one of your archived redo logs is corrupted. You can even maintain a standby database in a different city that is a constantly updated replica of your original database. Use the RMAN recover command to perform media recovery and apply incremental backups. Oracle has integrity checks that prevent you from opening the database until all datafiles are consistent with one another. By making frequent backups, you ensure that you can restore at least some of your lost data. You can obtain SCNs in a number of ways, for example, from the alert log. In contrast, logical backups contain data that you extract using the Oracle Export utility and store in a binary file. For example, if the latest log sequence number for your database is 100, and you then recover to log sequence number 50 and do not open RESETLOGS, eventually your database will reach log sequence number 100 again. Every Oracle database has a set of two or more online redo log files. A physical backup is a copy of a datafile, control file, or archived redo log that you store as a safeguard against data loss. You can use logical backups to supplement physical backups. The server session then backs up the specified datafile, control file, or archived log from the target database. In general, backups made before a RESETLOGS operation are not legal in the new incarnation. RMAN completely automates the procedure for recovering and restoring your backups and copies. For more information about the standby database option, see Chapter 16, "Managing a Standby Database". When performing media recovery, you can recover the whole database, a tablespace, or a datafile.
To learn how to perform O/S TSPITR, see Appendix B, "Performing Operating System Tablespace Point-in-Time Recovery". For RMAN syntax, see Chapter 11, "Recovery Manager Command Syntax". Archived redo logs also have these two values in their header. If you use a recovery catalog, RMAN has a record containing all the essential metadata concerning every backup you have taken. You can also restore backup sets containing archived redo logs. In this section we will briefly discuss: This manual will cover these topics in more detail in subsequent chapters. For a general discussion see Oracle8i Administrator's Guide. For information about incremental backups, see "Incremental Backups". The more data that accumulates in memory without being written to disk, the longer the instance recovery time, since a crash or media failure will force Oracle to apply redo data from the current online log to recover those changes. For more information on the syntax of SQL commands, see the Oracle8i SQL Reference. To learn how to maintain a standby database, see Chapter 16, "Managing a Standby Database". If you use SQL*Plus, you can issue the RECOVER or ALTER DATABASE RECOVER statements to apply the archived logs. Before the user can commit the transaction, the power goes out. It is called media recovery because you usually perform it in response to media failure. RMAN is only compatible with Oracle databases of release 8.0 or higher. If you run you database in ARCHIVELOG mode, you can apply redo to restored backups in order to reconstruct all lost changes. 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. When you specify files or archived logs using the RMAN backup command, RMAN creates a backup set as output. To learn how to perform recovery with RMAN, see "Recovering Datafiles". The incremental backup feature allows you to back up only those data blocks that have changed since a previous backup. For example, suppose that a power outage prevents Oracle from permanently writing modified data to the datafiles. In any case, you always use a restored backup to perform the recovery. Instance recovery, which is only possible in an OPS configuration, occurs in an open database when one instance discovers that another instance has crashed. After these steps are completed, issue either the RMAN recover command or the SQL*Plus RECOVER statement. One can achieve wide range availability of data by performing transaction processing at one site, called the primary site, and having a remote backup site where all the data from the primary site are duplicated. : It is important for the remote backup system to detect when the primary has failed. Running the database in ARCHIVELOG mode has the following consequences: Running the database in NOARCHIVELOG mode has the following consequences: Note: TSPITR is most useful when you want to: See Also: To learn how to perform TSPITR using RMAN, see Appendix A, "Performing Tablespace Point-in-Time Recovery with Recovery Manager". For example, if a user accidentally deletes payroll data, you can recover the database to the point in time before the data was deleted. You can make physical backups using either the Oracle8i Recovery Manager utility or O/S utilities.
For example, if a user adds a row to a table, but the server crashes before it can save the change to disk, Oracle can use the redo record for this transaction to update the data block to reflect the new row. A media manager is a vendor-supplied software package that allows you to back up to archival media such as tape. Oracle systematically goes through the redo log to determine which changes it needs to apply to which blocks, and then changes the blocks. Since you are not completely recovering the database to the most current time, you must tell Oracle when to terminate recovery. 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: See Also: To learn how to perform complete recovery with RMAN, see "Performing Complete Recovery".
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.
If the database is mounted during recovery, rollback occurs only when the database is opened. Because Oracle will not apply an archived redo log to a datafile unless the SCN and timestamps match, the RESETLOGS operations prevents you from corrupting your datafiles with old archived logs. The disadvantage is that you may end up losing data or increasing recovery time. In other words, you do not apply all of the redo data generated since the most recent backup. You can make backups of tablespaces, datafiles, control files, and archived redo logs while the database is open. During media recovery, you apply redo records or incremental backups to your latest backup to make the database current again.
Every Oracle database has one or more physical datafiles. See Also: For more information on managing the online redo log for backup and recovery, see "Managing the Online Redo Log". Unlike crash and instance recovery, media recovery is executed on your command. For example, a user changes a row value in a table from 5 to 7. If possible, take the desired tablespace offline and back up the datafiles. Recovers until you issue the CANCEL command.
Whenever you open the database with the RESETLOGS option, all datafiles get a new SCN and timestamp. See Also: For more information about multiplexing and mirroring the control file, see "Maintaining Multiple Control Files".
LGWR cycles through the online redo log files in the database, writing over old redo data. To learn how to perform incomplete media recovery using O/S methods, see "Performing Incomplete Media Recovery".
One crucial advantage to using RMAN is its incremental backup feature. A database's datafiles, which belong to logical structures called tablespaces, contain the database data. See Also: To learn how to make consistent backups using O/S methods, see "Making Consistent Whole Database Backups". The basic procedure for a consistent whole database backup is: If you are operating in NOARCHIVELOG mode, shut down the database cleanly before making a cold backup. For example, in a cumulative level 3 backup, RMAN determines which level 2 or level 1 backup occurred most recently and backs up all blocks used since that backup. The recovery catalog is a central repository containing a variety of information useful for backup and recovery. This type of recovery is called incomplete recovery.
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 destroy your hardware, you can recreate your original database. When statement failure occurs, Oracle automatically undoes any effects of the statement and returns control to the user. You can easily integrate RMAN with a media manager. In media recovery, you use online and archived redo logs and (if using RMAN) incremental backups to make a restored backup current or to update it to a specific time. 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 became unavailable, even for just 5 or 10 minutes. 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.
If you use RMAN, then you issue the recover command to apply archived redo logs or incremental backups to the datafiles.
It is intended as a general overview. Depending on the size and value of the lost information, the results can be devastating. There are three basic types of recovery: instance recovery, crash recovery, and media recovery. a) Detection of failure: It is important for the remote backup system to detect when the primary has failed. RMAN is a powerful and versatile program that allows you to make a backup or image copy of your data. Typically, there is a time lapse between the time when an Oracle server process changes a block in the buffer cache and the time when DBWn writes it to disk. Because the checkpoint in the datafile header of a backup will be older than the checkpoint in the control file, Oracle has to search the archived logs to determine whether changes need to be applied--and the pre-RESETLOGS archived logs are not valid in the new incarnation.