The physical structures of the database and the role each plays in the database recovery process determine the forms of backup and recovery available through user-managed techniques and through RMAN.
The files and other structures that make up an Oracle database store data and safeguard it against possible failures. This discussion introduces each of the physical structures that make up an Oracle database and their role in the reconstruction of a database from backup. This section contains these topics:
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.
See also:Oracle Database Concepts for more detail about the structure and contents of datafiles and data blocks.
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.
See also:Oracle Database Administrator's Guide for more details about the online redo logs, Oracle Database Administrator's Guide for more details about archived redo logs, and "Deciding Between ARCHIVELOG and NOARCHIVELOG Mode" for a discussion of the implications of archiving or discarding your redo log files.
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.
See also:Oracle Database Concepts for more information about control files.
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.
See also:Oracle Database Concepts for detailed information about undo segements.