Chapter One 1 Concepts Backup and recovery is not a single, discrete subject, but a collection of methods, strategies, and procedures to protect the data in your database and provide a means of recovery in the event of a disaster. While this book is primarily a reference for those methods and procedures, we should start by making sure we re all talking the same language and have a clear understanding of the basic concepts. BACKUP CONCEPTS Before you can hope to recover or restore a database, you first have to have it backed up in one way or another. There are basically two major types of backups physical backups that make a backup copy of the some or all of the database files, and logical backups that make a backup copy of some or all of the contents of the database. Both types have their strengths and both should probably be part of your overall backup strategy. 1
Backup Concepts 2 Type of Backup In backing up an Oracle database, a number of different techniques can be used. Which one is most appropriate depends upon the goal of the backup. Physical Physical backup should be used for a database that is going to be restored to the same or very similar hardware. This type of backup consists of all the datafiles and all associated support files of an Oracle database. Specifically, all tablespace datafiles, undo datafiles, redo logs, and initialization or SP files should be copied. Temporary tablespace files can and should be ignored. Physical backup types include the following: Cold the database is shutdown and completely quiescent. Hot the database is backed up completely and should be available for restoration and recovery. Individual tablespaces can be recovered, in some circumstances, but individual tables within a tablespace cannot. Cold backups will be consistent if the database was properly shut down and all processes that connect to it are closed. If the database was not correctly shut down, the backup will be inconsistent. Hot backups are always inconsistent.
Logical A logical backup is useful when only the data needs to be backed up. For example, when moving data to a completely different platform or radically different hardware set, it is frequently better and easier to back up only the data and not the structure of the database. Logical backups are generally done using Oracle s import and export utilities, either the traditional import/export, or the new Data Pump utilities of Oracle 10g, but can also be performed with third-party software, or with specially written software. Logical backups are most flexible for recovering individual objects, since they back up each object individually, even down to the row and column level. They cannot be used for point-in-time recovery, other than to the one point in time at which the backup was made. Cold (Closed) A cold backup is a specific type of physical backup, in which the database files are closed, and no Oracle instance processes are running. The database is completely unavailable for the duration of the backup. Cold backups are generally the most reliable type of backup. For a database not running in archive log mode, a cold backup is the only option for physical backups. Online redo logs must be copied for cold backup. Chapter 1 / Concepts 3
Backup Concepts 4 A cold backup is the only backup type which can fully restore an exact, albeit old, copy of a database without needing any additional archived logs or any media recovery. Additionally, a cold backup can be rolled forward to any time in its future for which archived log files are available. It can also be used as a restore point for recovering individual files or tablespaces, provided that archived redo logs are available. A cold backup gives the most flexibility in recovery scenarios. Hot (Open) Technically, a hot backup can be either physical or logical. However, this term is generally used to describe physical backups. A hot physical backup can be made only when the database is in archive log mode and is open. Each tablespace datafile must be placed into backup mode before it is copied to the backup destination. Once each datafile has been copied, it must be taken back out of backup mode. Online redo logs must not be copied for a hot backup, but all archived redo logs must be copied. When recovering from a hot backup, archived log files must be available up to the point in time to which the database is to be recovered. This is essentially the only distinction between recovering from a hot backup and recovering from a cold one. Consistent A consistent backup is one where all tablespaces, redo logs, and control files are in sync. This means they must have the same system change number. A cold backup is consistent only if the database was properly shut down before beginning the backup. A hot backup is never consistent, but can be recovered using archived log files.
Inconsistent Inconsistent backups require recovery on restoration. Only in the direst of circumstances (e.g., failing hardware) should an inconsistent backup be relied upon, unless the database is archiving log files and all archived log files are available on restoration. Without archived log files, full recovery from an inconsistent backup is impossible. If no archived logs are available, the database is probably completely unrecoverable. Oracle s support technicians may be able to help, in this scenario, but chances are high that the entire database will be lost. Backup Schedules A coherent backup schedule is critical for successful and timely disaster recovery. In mission-critical environments with very large databases, often there are resource constraints that prevent nightly full backups. In such situations, a mixed schedule is dictated. Full A full backup is just as it seems. All parts of all files necessary for restoration are backed up. Recovering from a full backup is very simple, since all files needed for recovery are contained within the single backup. Chapter 1 / Concepts 5
Backup Concepts 6 Incremental Oracle s recovery manager has several levels of incremental backup. Before using level 1 or level 2 backup, a level 0 backup must first be taken. A level 0 backup is also known as a baseline incremental backup. A level 1 backup will copy any files or parts of files which have changed since the last level 0 or level 1 backup. Similarly, a level 2 backup will copy all files or parts of files which have changed since the last level 0, level 1, or level 2 backup. If the cumulative qualifier is added to the phrase, the last backup of the same level will be ignored, causing this backup to be cumulative since the last backup of a lower level. For example, a level 2 cumulative backup will copy all files or parts of files which have changed since the last level 0 or level 1 backup. Recovery from any level of incremental backup requires that all backups of the previous appropriate levels be available, including the last full backup. For this reason, recovery from incremental backups is significantly more complex and may take a much longer time. Note In version 10g of Oracle, only level 0 and level 1 are supported. Higher levels have been deprecated. Redo Log Archival In an incremental backup, files or parts of files are backed up only if they have changed since the last backup. For a successful restore from an incremental, the previous full backups and all intervening incremental backups must be available.
Cumulative Cumulative backups are similar to incremental backups in that they back up only files or file parts which have changed since the last backup. The difference is that cumulative backups copy all changes since the last full backup. A successful restore from a cumulative backup would require restoration of the last full backup, plus the last cumulative. Partial A partial backup doesn t attempt to back up the entire database, but only a portion of it. A partial backup may be physical or logical, and it follows the same rules and procedures as a full backup. Partial backups can include specific tablespaces, datafiles, or even just the control files. Redo Log Archival Except in the case of a cold physical backup of a consistent database, restoration and recovery will require the use of redo logs from backed-up database. Chapter 1 / Concepts 7
Backup Concepts 8 Automatic You should almost always use automatic archival of redo logs. With automatic archival, every time a redo log fills and a log switch occurs, Oracle automatically copies the log file to one or more specified archival destinations before the log file is reused. Up to nine destinations can be specified, and a configurable minimum of those must succeed before the log file is considered to be successfully archived. If fewer than the minimum number of destinations succeed, Oracle will halt all operations on the database and refuse new user connections until the condition is corrected. Manual Manual redo log archival should be used only in very special circumstances, such as when an automatic archive of log files has failed due to some problem or where you need to carefully control exactly when an archive log is physically written to the media. In this mode, Oracle will not reuse a redo log until it has been archived, but it will only archive each log as and when directed via the appropriate SQL command. If the redo logs aren t archived in a timely fashion, the database will halt all operations and refuse new user connections until the condition is corrected.
None When redo log archival is turned off completely, the database reuses the online redo logs as soon as it needs to, provided that all the transactions contained in each one have been committed or rolled back. Hot backups are not possible in this mode, and no point-in-time recovery is possible. This mode should be used only on databases containing no information which cannot be quickly and easily recovered through other means. RECOVERY CONCEPTS Oracle makes a distinction between restoring a physical data or control file, and the actual recovery of the database. Recovery Several techniques are available for recovery after a failure. Which one is most appropriate depends upon the backup method used and the failure mode at hand. Chapter 1 / Concepts 9
Recovery Concepts 10 Instance Failure and Crash Recovery Recovery from an instance failure or system crash is generally unnoticeable to the end-user and almost unnoticeable even to the DBA. The Oracle recovery process (RECO) will automatically use the online redo logs to bring all files and objects in the database into a consistent state. No archived log files will be necessary. Media Failure Oracle Corporation uses the term media recovery to refer to any recovery in which one or more datafiles have been lost or corrupted, for any reason, including actual failure of the media on which the files were stored. Recovery can take place at the file or block level. Datafile recovery can be done with any Oracle backup and recovery tool, including manual backups or scripted backups. Each lost or corrupt file is restored, then archived log files are applied to those files, in order to bring them back into consistency with the rest of the database. Unless the files requiring recovery are part of the system tablespace, the rest of the database can be online and in use during such recoveries.
Block recovery can currently be done only with Oracle s Recovery Manager (RMAN) product. This technique is useful if only a small portion of one or more datafiles has been corrupted. In this process, old copies of the file or files in question are used, along with appropriate archived redo logs, and individual blocks are recovered, as needed. The entire database can be open and in use during this process, with only processes that need access to the affected blocks encountering any trouble. Block recovery can be done using RMAN, even if the backup was not performed with RMAN. To do this, the backup files must be cataloged into RMAN before the block recovery can proceed. Complete Recovery In a complete-recovery scenario, the database is completely recovered to the point at which it crashed. Complete recovery does not imply or require that the entire database be recovered, if only a few files were lost. Any affected datafiles should be restored, and then all available archived log files applied, up to the point where the database crashed. This is generally the most desirable form of recovery. Incomplete Recovery Incomplete recovery is useful when some or all online redo logs have been lost, when not all archived log files are available up to the present, or when some logical corruption has occurred. In incomplete recovery, the database is restored, then archived and/or online redo logs are applied to the restored files, up to a specific point in time or transaction number. Recovering from user or DBA error is prob- Chapter 1 / Concepts 11
Recovery Concepts 12 ably the most common, and most valuable, use for this technique. If a table or tablespace is accidentally dropped; if data is erroneously deleted, inserted, or updated; or if some transaction failure leaves the contents in doubt, the database can be restored from an old backup, and then archived log files can be applied to bring the system forward to a point just short of where the logical corruption occurred. Tablespace Point-in-Time Recovery Incomplete recovery is used to recover an entire database to a previous point in time. It is also possible to recover individual tablespaces to an earlier point. This is understandably a much more involved procedure. To perform tablespace point-in-time recovery (TSPITR), you must restore a complete copy of your database to an alternate location, preferably on an alternate host. Once the copy of the database is restored from backup, it should be rolled forward, using incomplete-recovery techniques, up to a point just before the tablespace in question became corrupted. Once that recovery is finished, the tablespace should be taken offline in the original database, and dropped. The newly recovered tablespace is then exported from the database copy and imported into the original, using Oracle s transportable tablespace feature.
EXPORT, IMPORT, AND DATA PUMP Oracle 10g introduces a new, faster, and far more flexible export/import utility, the Oracle Data Pump. While the original import and export utilities are continued, the new Data Pump enables very high-speed movement of data and metadata from one database to another. All operations are server based, with the exception of the parfile, which is located on the initiating client. Exports are made to server-based binary files, so directory objects need to be defined. Parallel processes can be specified for both export or import operations, and the data pump can be used to move data and metadata directly from one instance to another without any intervening files being created. Both exports and imports using Data Pump may be stopped and restarted. Data is not exported in a linear, sequential fashion, as it was in the original export utility, so the position in the file is not necessarily sequential. And the Data Pump cannot be used to write directly to tape. Chapter 1 / Concepts 13