1.2 Backup and Recovery: Basic Concepts

1.2.1.1 Datafiles and Data Blocks

An Oracle database consists of one or more logical storage units called tablespaces. Each tablespace in an Oracle database consists of one or more files called datafiles, physical files under the host operating system which collectively contain the data stored in the tablespace.The simplest Oracle database would have one tablespace, stored in one datafile.

The database manages the storage space in the datafiles of a database in units called data blocks. Data blocks are the smallest units of storage that the database can use or allocate.

Modified or new data is not written to datafiles immediately. Updates are buffered in memory and written to datafiles at intervals. If a database has not gone through a normal shutdown (that is, if it is open, or exited abnormally, as in an instance failure or a SHUTDOWN ABORT) then there are typically changes in memory that have not been written to the datafiles. Datafiles that were restored from backup, or were not closed during a consistent shutdown, are typically not completely up to date.

Copies of the datafiles of a database are a critical part of any backup.

1.2.1.2 Redo Logs

Redo logs record all changes made to a database's data files. Each time data is changed in the database, that change is recorded in the online redo log first, before it is applied to the datafiles.

An Oracle database requires at least two online redo log groups, and in each group there is at least one online redo log member, an individual redo log file where the changes are recorded.

At intervals, the database rotates through the online redo log groups, storing changes in the current online redo log .

Because the redo log contains a record of all changes to the datafiles, if a backup copy of a datafile from some point in time and a complete set of redo logs from that time forward are available, the database can reapply changes recorded in the redo logs, in order to re-construct the datafile contents at any point between the backup time and the end of the last redo log. However, this is only possible if the redo log has been preserved.

Therefore, preserving the redo logs is a major part of most backup strategies. The first level of preserving the redo log is through a process called archiving. The database can copy online redo log groups that are not currently in use to one or more archive locations on disk, where they are collectively called the archived redo log. Individual files are referred to as archived redo log files. After a redo log file is archived, it can be backed up to other locations on disk or on tape, for long term storage and use in future recovery operations.

Without archived redo logs, your database backup and recovery options are severely limited. Your database must be taken offline before it can be backed up, and if you must restore your database from backup, the database contents are only available as of the time of the backup. Reconstructing the state of the database at a point in time between backups is impossible without the archived log.

1.2.1.3 Control Files

The control file contains the record of the physical structures of the database and their status. Several types of information stored in the control file are related to backup and recovery:

• Database information (RESETLOGS SCN and time stamp)

• Tablespace and datafile records (filenames, datafile checkpoints, read/write status, offline ranges)

• Information about redo threads (current online redo log)

• Log records (log sequence numbers, SCN range in each log)

• A record of past RMAN backups

• Information about corrupt datafile blocks

The recovery process for datafiles is in part guided by status information in the control file, such as the database checkpoints, current online redo log file, and the datafile header checkpoints for the datafiles. Loss of the control file makes recovery from a data loss much more difficult.

1.2.1.4 Undo Segments

In general, when data in a datafile is updated, "before images" of that data are written into undo segments. If a transaction is rolled back, this undo information can be used to restore the original datafile contents.

In the context of recovery, the undo information is used to undo the effects of uncommitted transactions, once all the datafile changes from the redo logs have been applied to the datafiles. The database is actually opened before the undo is applied.

You should not have to concern yourself with undo segments or manage them directly as part of your backup and recovery process.