Backup and Recovery Components and Strategy Reference

Key Structural Components for Data Recovery

It is important to understand Oracle database structural components that are essential for data recovery.

System Global Area (SGA): The SGA is a shared memory structure that contains data and control information for a given database instance. The SGA contains separate buffer areas, such as the redo log buffer.
Redo Logs: In an Oracle Database, redo logs are the crucial structure for data recovery in case of a failure. A redo log consists of a minimum of two or more preallocated files that maintain logs of database transactions, as they occur, after a backup. Each redo log file is filled with redo records. Redo log entries are generated in the redo log buffer of the SGA. The log writer process (LGWR) is an Oracle background process that is responsible for writing the redo log buffer into redo log files. The database requires that each redo log contains a minimum of two redo log files to guarantee that one is always available for writing while the other is being archived (if the Oracle Database is running in the ARCHIVELOG mode). The LGWR process writes to redo log files in a circular fashion. When the current redo log file is full, LGWR begins writing to the next available redo log file.
Archived Redo Logs: When you cannot afford to lose data, Oracle recommends that you run your Oracle Database instance in the ARCHIVELOG mode. The ARCHIVELOG mode enables the archiving of filled redo logs. When a database is mounted, run the ALTER DATABASE ARCHIVELOG statement to enable the archiving of filled redo log files. You can choose to archive redo logs to more than one chosen destination. For example, you can archive filled redo logs to a local disk, an Oracle Automatic Storage Management (Oracle ASM) disk group, and the fast recovery area (FRA). Define the LOG_ARCHIVE_DEST_n initialization parameter to specify more than one destination to archive the filled redo logs. The database starts multiple archive processes, as needed, to ensure that the archiving of filled redo logs does not fall behind. A copy of each filled redo log file is written to each destination. In the event of a database failure, you can first restore a full database backup and then use the archived redo log files to recover a database to a recent committed transaction that occurred before a specified point in time.

Backup Concepts

Here are some key terms and concepts that concern the backup and recovery scenario for your Oracle Databases.

Recovery Point Objective (RPO): The point in time (in the past) to which you can recover lost data. RPO defines the data-loss tolerance of a business process or an organization. The RPO is often measured in terms of time, for example, five hours or two days worth of data loss.
Recovery Time Objective (RTO): The point in time (in future) at which you will restore your Oracle Database after its failure. RTO predicts the estimated period for database recovery.
Backup Window Time: The scheduled time taken for Oracle Database backups to begin and complete.
Backup Types: Full backup, incremental level 0 (L0) backup, incremental level 1 (L1) backup, and archived redo log backup.
Full Backup: A full backup includes all the allocated data blocks in a database. When you have connected RMAN to a target database, run the BACKUP DATABASE command to create a full backup.
Incremental Level 0 (L0) Backup: An L0 backup forms the base of an incremental backup strategy. An L0 backup also includes all the allocated blocks containing data. The only difference between an incremental L0 backup and a full backup is that a full backup is never included in an incremental strategy. When you have connected RMAN to a target database, run the BACKUP INCREMENTAL LEVEL 0 DATABASE command to create an L0 backup.
Incremental Level 1 (L1) Backup: An incremental L1 backup contains only the changed data blocks since the last incremental L0 or L1 backup was taken. L1 backups are always differential by default. A differential backup includes only the blocks which changed since the most recent L0 or L1 backup was taken. For example, assume that an L0 backup was taken on Sunday. On Monday, the L1 backup will include only the data that changed after the L0 backup was taken. Tuesday's L1 backup will contain only the changed data since Monday's L1 backup. When you have connected RMAN to a target database, run the BACKUP INCREMENTAL LEVEL 1 DATABASE command to create an incremental L1 backup.
Archive Redo Log Backups: In this approach, the database archive redo logs are backed up, typically on an hourly basis, so that the database can be recovered to a specified point in time in the event of a failure. When you have connected RMAN to a target database, run the BACKUP ARCHIVELOG command to backup the archived redo log files.

RMAN Backup Strategy to Recovery a Database After a Failure

You use Recovery Manager (RMAN), an Oracle Database client, to perform backup and recovery operations for your Oracle Databases.

4. Weekly Full, Daily Incremental and Hourly Archived Redo Log Backups: In this strategy, an incremental L0 backup is taken once a week. The subsequent incremental L1 backups can be taken on a daily or an hourly basis. Incremental L1 backups require lesser storage space and have shorter backup windows.

Consider an Oracle Database that is backed up (L0) weekly on Sundays at 11:00 PM. The daily incremental L1 backups are taken at noon everyday starting from Monday to Saturday. Monday's incremental L1 backup will contain all the changes that occurred in the database since Sunday's incremental L0 backup. However, Tuesday's incremental L1 backup will contain only the changed data since Monday's incremental L1 backup. This daily incremental L1 backup trend continues until the next weekly incremental L0 backup is taken. In addition, an hourly archived redo log backup is taken to ensure that the archived redo log files are backed up.

If a database failure occurs, you use RMAN to restore the database using the most recent incremental L0 backup, and recover the database by applying the incremental L1 backups and the most recent archived redo log backup. When RMAN is connected to a target database, run the RESTORE command to restore the data files from a backup. Run the RECOVER command to automatically restore and apply both incremental backups and archived redo logs.

Consider that a disk failure occurs at 3 PM, on Friday. You begin by restoring the L0 backup taken on Sunday, next apply the incremental L1 backups sequentially in the order of Monday through Friday, and finally apply the archive redo logs from the most recent archive redo log backup (taken at 2:45 PM on Friday, minutes before the crash). This ensures that you can recover the database with a recovery point objective that guarantees that you can recover all the committed transactions with minimal data loss and shorter recovery time.

Note: While recovering a database from failure, RMAN always chooses incremental backups over archived redo logs because applying changes at a block level is faster than applying redo logs.

5. In the absence of incremental L1 backups, restoring a database requires a very long recovery time because after you restore the full backup you must sequentially apply a long-chain of redo logs to recover the database to a specified point in time.