archived redo log

A copy of one of the filled members of an online redo log group made when the database is in ARCHIVELOG mode. After the LGWR process fills each online redo log with redo records, the archiver process copies the log to one or more redo log archiving destinations. This copy is the archived redo log. Note that RMAN does not distinguish between an original archived redo log and an image copy of an archived redo log; both are considered image copies.


The mode of the database in which Oracle copies filled online redo logs to disk. Specify the mode at database creation or with the ALTER DATABASE ARCHIVELOG statement.

See Also: archived redo log, NOARCHIVELOG mode


The operation in which a filled online redo log file is copied to an offline log archiving destination. An offline copy of an online redo logs is called an archived redo log. You must run the database in ARCHIVELOG mode to archive redo logs.

automatic channel allocation

The ability of RMAN to perform backup and restore tasks without requiring the use of the ALLOCATE CHANNNEL command. You can use the CONFIGURE command to specify disk and tape channels. Then, you can issue commands such as BACKUP and RESTORE at the RMAN command prompt without manually allocating channels. RMAN uses whatever configured channels that it needs in order to execute the commands.

automatic undo management mode

A mode of the database in which undo data is stored in a dedicated undo tablespace. The only undo management that you must perform is the creation of the undo tablespace. All other undo management is performed automatically.

auxiliary database

(1) A database created from target database backups with the RMAN DUPLICATE command.

(2) A temporary database that is restored to a new location and then started up with a new instance name during tablespace point-in-time recovery (TSPITR). A TSPITR auxiliary database contains the recovery set and auxiliary set.

See Also: recovery set, auxiliary set, tablespace point-in-time recovery (TSPITR)

auxiliary set

In TSPITR, the set of files that is not in the recovery set but which must be restored in the auxiliary database for the TSPITR operation to be successful.

See Also: auxiliary database, recovery set


(1) A backup copy of data, that is, a database, tablespace, table, datafile, control file, or archived redo log. Backups can be physical (at the database file level) or logical (at the database object level). Physical backups can be created by using RMAN to back up one or more datafiles, control files or archived redo log files. Logical backups can be created using one of the Oracle export utilities (Data Pump Export or Original Export).

(2) An RMAN command that creates a backup set, proxy copy, or disk-based image copy.

See Also: copy, backup set, multiplexing, RMAN

backup, whole database

See whole database backup

backup and recovery

The set of concepts, procedures, and strategies involved in protecting the database against data loss due to media failure or users errors.

backup control file

A backup of the control file. You can back up the control file with the RMAN backup command or with the SQL statement ALTER DATABASE BACKUP CONTROLFILE TO 'filename'.

backup mode

The database mode (also called hot backup mode) initiated when you issue the ALTER TABLESPACE ... BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP command before taking an online backup. You take a tablespace out of backup mode when you issue the ALTER TABLESPACE ... END BACKUP or ALTER DATABASE END BACKUP command.

You must use this command when you make a user-managed backup of datafiles in an online tablespace. RMAN does not require you to put the database in backup mode. In backup mode, updates to the database create more than the usual amount of redo. Each time a block in the buffer cache becomes dirty, Oracle must write an image of the changed block to the redo log file, in addition to recording the changes to the data.

See Also: corrupt block, online backup

backup piece

The physical file format used to store RMAN backup sets.

See Also: backup, backup set, RMAN

backup retention policy

See retention policy

backup set

A backup of one or more datafiles, control files, SPFILEs and archived redo log files. Each backup set consists of one or more binary files called backup pieces. Backup pieces are written in a proprietary format that can only be created or restored by RMAN.

Backup sets are produced by the RMAN BACKUP command. A backup set usually consists of only one backup piece. RMAN divides the contents of a backup set among multiple backup pieces only if you limit the backup piece size using the MAXPIECESIZE option of the ALLOCATE CHANNEL or CONFIGURE CHANNEL command.

See Also: backup piece, unused block compression, multiplexing, RMAN

binary compression

A technique whereby RMAN applies a compression algorithm to data being backed up to backup sets.

block change tracking

A database option that causes Oracle to track datafile blocks affected by each database update. The tracking information is stored in a new type of file called the change tracking file. When block change tracking is enabled, RMAN uses the record of changed blocks from the change tracking file to improve incremental backup performance by only reading those blocks known to have changed, instead of reading datafiles in their entirety.

block media recovery

The recovery of specified blocks within a datafile with the Recovery Manager BLOCKRECOVER command. Block media recovery leaves the affected datafiles online and restores and recovers only the damaged or corrupted blocks.


A connection between RMAN and the target database. Each allocated channel starts a new Oracle server session; the session then performs backup, restore, and recovery operations. A channel can either be a DISK channnel (used to perform disk I/O) or an sbt channel (used to perform I/O through a third-party media manager).

See Also: media manager, target database


A data structure that defines an SCN in the redo thread of a database. Checkpoints are recorded in the control file and each datafile header, and are a crucial element of recovery.

circular reuse records

Control file records containing information used by RMAN for backups and recovery operations. These records are arranged in a logical ring. When all available record slots are full, Oracle either expands the control file to make room for a new records or overwrites the oldest record. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter controls how many days records must be kept before they can be overwritten. The default for CONTROL_FILE_RECORD_KEEP_TIME is 7 days.

See Also: noncircular reuse records

closed backup

A backup of one or more database files taken while the database is closed. Typically, closed backups are whole database backups. If you closed the database cleanly, then all the files in the backup are consistent. Otherwise, the backups are inconsistent.

See Also: consistent shutdown, consistent backup

cold backup

See closed backup

complete recovery

Recovery of one or more datafiles that applies all redo generated after the restored backup. Typically, you perform complete recovery when media failure damages one or more datafiles or control files. You fully recover the damaged files using all redo generated since the restored backup was taken.

See Also: incomplete recovery, media recovery

consistent backup

A whole database backup that you can open with the RESETLOGS option without performing media recovery. In other words, you do not need to apply redo to this backup for it to be consistent. (Note, however, that unless you apply the redo generated since the consistent backup was created, you lose all transactions since the time of the consistent backup.)

You can only take consistent backups after you have performed a consistent shutdown of the database. The database must not be re-opened until the backup has completed.

See Also: fuzzy file, inconsistent backup

consistent shutdown

A database shut down with the IMMEDIATE, TRASACTIONAL or NORMAL options of the statement. A database shut down cleanly does not require recovery; it is already in a consistent state.

crash recovery

The automatic application of online redo records to a database after either a single-instance database crashes or all instances of an Oracle Real Applications Cluster configuration crash. Crash recovery only requires redo from the online logs: archived redo logs are not required.

See Also: recover

control file autobackup

The automatic backup of the current control file that RMAN makes in the situations:

  • After every BACKUP command run at the RMAN prompt

  • After a BACKUP command within a RUN block that is not followed by another BACKUP command

The control file autobackup has a default filename that allows RMAN to restore it even if the control file and recovery catalog are lost. You can override the default filename if desired.


To back up a bit-for-bit image of an Oracle file (Oracle datafiles, control files, and archived redo logs) onto disk. You can copy in two ways:

  • Using operating system utilities (for example, the UNIX cp or dd)

  • Using the RMAN BACKUP AS COPY command

See Also: backup

corrupt block

An Oracle block that is not in a recognized Oracle format, or whose contents are not internally consistent. Typically, corruptions are caused by faulty hardware or operating system problems. Oracle identifies corrupt blocks as either logically corrupt (an Oracle internal error) or media corrupt (the block format is not correct).

You can repair a media corrupt block by recovering the block, or dropping the database object that contains the corrupt block so that its blocks are reused for another object. If media corruption is due to faulty hardware, neither solution will work until the hardware fault is corrected.

See Also: block media recovery


A check to determine whether files on disk or in the media management catalog correspond to the data in the repository and the control file. Because the media manager can mark tapes as expired or unusable, and because files can be deleted from disk or otherwise become corrupted, the RMAN repository can contain outdated information about backups. Run the CROSSCHECK command to perform a crosscheck. To determine whether you can restore a file, run VALIDATE BACKUPSET or RESTORE ... VALIDATE.

See Also: validation

cumulative incremental backup

An incremental backup that backs up all the blocks changed since the most recent backup at level 0. When recovering with cumulative incremental backups, only the most recent cumulative incremental backup needs to be applied.

See Also: differential incremental backup, incremental backup

current online redo log

The online redo log file in which the LGWR background process is currently logging redo records.

See Also: redo log, redo log group

database checkpoint

The thread checkpoint that has the lowest SCN. All changes in all enabled threads prior to the database checkpoint are guaranteed to have been written to disk.

See Also: checkpoint

database identifier


database point-in-time recovery (DBPITR)

The recovery of an entire database to a specified past target time, SCN, or log sequence number.

See Also: incomplete recovery, tablespace point-in-time recovery (TSPITR)

datafile media recovery

The application of redo records to a restored datafile in order to roll it forward to a more current time. Unless you are doing block media recovery, the datafile must be offline while being recovery.


An internal, uniquely generated number that differentiates databases. Oracle creates this number automatically when you create the database.

differential incremental backup

A type of incremental backup that backs up all blocks that have changed since the most recent backup at level 1 or level 0. For example, in a differential level 1 backup RMAN determines which level 1 or level 0 backup is most recent and then backs up all blocks changed since that backup. Differential backups are the default type of incremental backup. When recovering using differential incremental backups, RMAN must apply all differential incremental level 1 backups since the restored datafile backup.

See Also: cumulative incremental backup, incremental backup

disk controller

A hardware component that is responsible for controlling one or more disk drives.

disk quota

A user-specified limit to the size of the flash recovery area. When the disk quota is reached, Oracle automatically deletes files that are no longer needed.

duplicate database

A database created from target database backups using the RMAN duplicate command.

See Also: auxiliary database


The extraction of logical data (that is, not physical files) from a database into a binary file using one of the Oracle export utilities, such as Data Pump Export. You can then use a corresponding Oracle import utility to import the data into a database.

See Also: logical backup

flash recovery area

An optional disk location that you can use to store recovery-related files such as control file and online redo log copies, archived logs, flashback logs, and RMAN backups. Oracle and RMAN manage the files in the flash recovery area automatically. You can specify the disk quota, which is the maximum size of the flash recovery area.

flashback logs

Oracle-generated logs used to perform flashback database operations. Oracle can only write flashback logs to the flash recovery area. They cannot be backed up to disk.

full backup

A non-incremental RMAN backup. Note that "full" does not refer to how much of the database is backed up, but to the fact that the backup is not incremental. Consequently, you can make a full backup of one datafile.

full resynchronization

An RMAN operation that updates the recovery catalog with all changed metadata in the database's control file. You can initiate a full catalog resynchronization by issuing the RMAN command RESYNC CATALOG. (Note that it is rarely necessary to use RESYNC CATALOG because RMAN automatically performs resynchronizations when needed.)

fuzzy file

A datafile that contains at least one block with an SCN greater than or equal to the checkpoint SCN in its header. For example, this situation occurs when Oracle updates a datafile that is in backup mode. A fuzzy file that is restored always requires recovery.

hot backup

See online backup

hot backup mode

See backup mode

image copy

A bit-for-bit copy of a single datafile, archived redo log file, or control file that is:

  • Usable as-is to perform recovery (unlike a backup set, which uses unused block compression and is in an RMAN-specific format)

  • Generated with the RMAN BACKUP AS COPY command, an operating system command such as the UNIX cp, or by the Oracle archiver process


A separate version of a database. The incarnation of the database changes when you open it with the RESETLOGS option, but you can recover backups from a prior incarnation so long as the necessary redo is available.

incomplete recovery

A synonym for database point-in-time recovery (DBPITR).

See Also: complete recovery, media recovery, recover

inconsistent backup

A backup in which some of the files in the backup contain changes that were made after the files were checkpointed. This type of backup needs recovery before it can be made consistent. Inconsistent backups are usually created by taking online database backups. You can also make an inconsistent backup by backing up datafiles while a database is closed, either:

  • Immediately after the crash of an Oracle instance (or, in a RAC configuration, all instances)

  • After shutting down the database using SHUTDOWN ABORT

Inconsistent backups are only useful if the database is in ARCHIVELOG mode and all archived redo logs created since the backup are available.

See Also: consistent backup, online backup, system change number (SCN), whole database backup

incremental backup

An RMAN backup in which only modified blocks are backed up. Incremental backups are classified by level. An incremental level 0 backup performs the same function as a full backup in that they both back up all blocks that have ever been used. The difference is that a full backup will not affect blocks backed up by subsequent incremental backups, whereas an incremental backup will affect blocks backed up by subsequent incremental backups.

Incremental backups at level 1 back up only blocks that have changed since previous incremental backups. Blocks that have not changed are not backed up. An incremental backup can be either a differential incremental backup or a cumulative incremental backup. A cumulative incremental backup backs up all blocks changed since the last level 1 incremental backup. A differential incremental backup backs up all blocks changed since the last level 0 or level 1 incremental backup.

instance failure

The termination of an Oracle instance due to a hardware failure, Oracle internal error, or SHUTDOWN ABORT statement. Crash or instance recovery is always required after an instance failure.

instance recovery

In a RAC configuration, the application of redo data to an open database by an instance when this instance discovers that another instance has crashed.

See Also: recoverLogMiner


A utility that enables log files to be read, analyzed, and interpreted by means of SQL statements

See Also: archived redo log

log sequence number

A number that uniquely identifies a set of redo records in a redo log file. When Oracle fills one online redo log file and switches to a different one, Oracle automatically assigns the new file a log sequence number.

See Also: log switch, redo log

log switch

The point at which LGWR stops writing to the active redo log file and switches to the next available redo log file. LGWR switches when either the active log file is filled with redo records or you force a switch manually.

See Also: redo log

logical backup

A backup of database schema objects, such as tables. Logical backups are created and restored with the Oracle Data Pump Export utility or Original Export utility. You can restore objects from logical backups using the Oracle import utility that corresponds to the utility used to create the backup.

long-term backup

A backup that you want to exclude from a backup retention policy, but want to record in the recovery catalog. Typically, long-term backups are snapshots of the database that you may want to use in the future for report generation.

Mean Time To Recover (MTTR)

The time required to perform crash or media recovery on the database. A variety of factors influence MTTR for media recovery, including the speed of detection, the method used to perform media recovery, and the size of the database.

media failure

Damage to the disks containing any of the files used by Oracle, such as the datafiles, logfiles, or control file. When Oracle detects media failure, it takes the affected files offline.

See Also: media recovery

media manager

A third-party networked backup system that can be integrated with Recovery Manager so that database backups can be written directly to tertiary storage.

media recovery

The application of redo or incremental backups to a restored backup datafile or individual data block.

When performing media recovery, you can recover a database, tablespace, datafile, or set of blocks within a datafile. Media recovery can be either complete recovery (in which all changes in the redo logs are applied) or incomplete recovery (in which only changes up to a specified point in time are applied). Media recovery is only possible when the database is in ARCHIVELOG mode.

See Also: block media recovery, recover


Maintaining identical copies of data on one or more disks. Typically, mirroring is performed on duplicate hard disks at the operating system level, so that if one of the disks becomes unavailable, the other disk can continue to service requests without interruptions. When mirroring files, Oracle writes once while the operating system writes to multiple disks; when multiplexing files, Oracle writes the same data to multiple files.


  • online redo logs

    The automated maintenance of more than one identical copy of the online redo log.

  • control file

    The automated maintenance of more than one identical copy of a database's control file.

  • backup set

    The RMAN technique of reading database files simultaneously from the disks and then writing the blocks to the same backup piece.

  • archived redo logs

    The Oracle archiver process is able to archive multiple copies of a redo log.

See Also: mirroring


The mode of the database in which Oracle does not require filled online redo logs to be archived before they can be overwritten. Specify the mode at database creation or change it with the ALTER DATABASE NOARCHIVELOG command.

Note that running in NOARCHIVELOG mode severely limits the possibilities for recovery of lost or damaged data.

See Also: archived redo log, ARCHIVELOG mode

noncircular reuse records

Control file records containing critical information needed by the Oracle database. These records are never automatically overwritten. Some examples of information in non-circular reuse records include the locations of datafiles and online redo logs.

See Also: circular reuse records

offline normal

When a tablespace is taken offline normal, it is taken offline using the ALTER TABLESPACE ... OFFLINE NORMAL statement. The datafiles in the tablespace are checkpointed and do not require recovery before being brought online. If a tablespace is not taken offline normal, then its datafiles must be recovered before being brought online.

online backup

A backup of one or more datafiles taken while a database is open and the datafiles are online. When you make a user-managed backup while the database is open, you must put the tablespaces in backup mode by issuing an ALTER TABLESPACE BEGIN BACKUP command. (You can also use ALTER DATABASE BEGIN BACKUP to put all tablespaces in your database into backup mode in one step.)

Note that you should not put tablespaces in backup mode when performing backups with RMAN.

online redo log

The online redo log is a set of two or more files that record all changes made to the database. Whenever a change is made to the database, Oracle generates a redo record in the redo buffer. The LGWR process flushes the contents of the redo buffer into the online redo log.

The current online redo log is the one being written to by LGWR. When LGWR gets to the end of the file, it performs a log switch and begins writing to a new log file. If you run the database in ARCHIVELOG mode, then each filled online redo log file must be copied to one or more archiving locations before LGWR can overwrite them.

See Also: archived redo log

online redo log group

The Oracle online redo log consists of two or more online redo log groups. Each group contains one or more identical online redo log members. An online redo log member is a physical file containing the redo records.

online redo log member

A physical online redo log file within an online redo log group. Each log group must have one or more members. Each member of a group is identical.

operating system backup

See user-managed backup

operating system backup and recovery

See user-managed backup and recovery

Oracle Flashback Database

The return of the whole database to a prior consistent SCN by means of the RMAN FLASHBACK command or SQL*Plus FLASHBACK statement. A database flashback is different from traditional media recovery because it does not involve the restore of physical files, instead restoring your current datafiles to past states using saved images of changed data blocks. The flashback database process uses flashback logs and archived redo logs.

Oracle-managed file

A database file managed by the Oracle Managed Files feature.

Oracle Managed Files (OMF)

A feature of the Oracle database which manages the creation, naming and deletion of Oracle database files within dedicated areas of disk, to minimize the need for DBAs to concern themselves with such specifics.

orphaned backups

Backups that belong to incarnations of the database that are not direct ancestors of the current incarnation, or that were created after the SCN where the ancestor incarnation branched toward the current incarnation. Such backups cannot be used in the current incarnation.

parallel recovery

A form of recovery in which several processes simultaneously apply changes from redo log files. Instance and media recovery can be parallelized automatically with the RECOVERY_PARALLELISM initialization parameter or options to the SQL*Plus RECOVER command.


Allocating multiple channels for RMAN backup and recovery operations.

partial resynchronization

A type of resynchronization in which RMAN transfers data about archived logs, backup sets, and datafile copies from the target control file to the recovery catalog.

password file

A file created by the ORAPWD command, and required if you wish to connect using the SYSDBA or SYSOPER roles over a network. For details on password files, see the Oracle Database Administrator's Guide.

physical schema

The datafiles, control files, and redo logs in a database at a given time. Issue the RMAN REPORT SCHEMA command to obtain a list of tablespaces and datafiles.

point-in-time recovery

The incomplete recovery of database files to a noncurrent time. Time-based recovery is also known as incomplete recovery andtime-based recovery .

See Also: incomplete recovery, incomplete recovery, media recovery, recover

proxy copy

A backup in which the media manager manages the transfer of data between the media storage device and disk during RMAN backup and restore operations.


To recover a database file or a database is typically to perform media recovery, crash recovery or instance recovery. Can also be used generically, as in "recover your data," to refer to reconstructing or re-creating lost data by any means.

See Also: complete recovery, incomplete recovery, instance recovery, crash recovery, media recovery.


When used to refer to a database file or a database, the application of redo data or incremental backups to database files in order to reconstruct lost changes. The three types of recovery are instance recovery, crash recovery, and media recovery. Oracle performs the first two types of recovery automatically using online redo records; only media recovery requires you to restore a backup and issue commands.

See Also: complete recovery, incomplete recovery

recovery catalog

A set of Oracle tables and views used by RMAN to store RMAN repository information about one or more Oracle databases. RMAN uses this data to manage the backup, restore, and recovery of Oracle databases.

Use of a recovery catalog is optional. The primary storage for RMAN repository information for a database is always in the control file of the target database. A recovery catalog is periodically updated with RMAN repository data from the control file. In the event of the loss of your control file, the recovery catalog can provide most or all of the lost information required for restore and recovery of your database. The recovery catalog can also store records of long-term backups and RMAN stored scripts for use with target databases.

See Also: recovery catalog database

recovery catalog database

An Oracle database that contains a recovery catalog schema. You should not store the recovery catalog in the target database.

Recovery Manager (RMAN)

The primary utility for physical backup and recovery of Oracle databases. RMAN keeps records of Oracle databases in its own structure called an RMAN repository, manages storage of backups, validates backups. You can use it with or without the central information repository called a recovery catalog. If you do not use a recovery catalog, RMAN uses the database's control file to store information necessary for backup and recovery operations. You can use RMAN in conjunction with third-party media management software to back up files to tertiary storage.

See Also: backup piece, backup set, copy, media manager, recovery catalog

recovery set

One or more tablespaces that are being recovered to an earlier point in time during tablespace point-in-time recovery (TSPITR). After TSPITR, all database objects in the recovery set have been recovered to the same point in time.

See Also: auxiliary set

recovery window

A recovery window is one type of RMAN backup retention policy, in which the DBA specifies a period of time and RMAN ensures retention of backups and archived redo logs required for point-in-time recovery to any time during the recovery window. The interval always ends with the current time and extends back in time for the number of days specified by the user.

For example, if the retention policy is set for a recovery window of seven days, and the current time is 11:00 AM on Tuesday, RMAN retains the backups required to allow point-in-time recovery back to 11:00 AM on the previous Tuesday.

See Also: retention policy

redo log

A redo log can be either an online redo log or an archived redo log. The online redo log is a set of two or more redo log groups that records all changes made to Oracle datafiles and control files. An archived redo log is a copy of an online redo log that has been written to an offline destination.

See Also: archived redo log, online redo log

redo log group

Each online redo log member (which corresponds to an online redo log file) belongs to a redo log group. Redo log groups contain one or more members. A redo log group with more than one member is called a multiplexed redo log group. The contents of all members of a redo log group are identical.

redo thread

The redo generated by an instance. If the database runs in a single instance configuration, then the database has only one thread of redo.

redundancy set

A set of backups enabling you to recover from the failure or loss of any Oracle database file.


In RMAN, the execution of a REGISTER DATABASE command in order to record the existence of a target database in the recovery catalog. A target database is uniquely identified in the catalog by its DBID. You can register more than one database in the same catalog, and also register the same database in multiple catalogs.

See Also: DBID

RMAN repository

The record of RMAN metadata about backup and recovery operations on the target database. The authoritative copy of the RMAN repository is always stored in the control file of the target database. A recovery catalog can also be used for longer-term storage of the RMAN repository, and can serve as an alternate source of RMAN repository data if the control file of your database is lost.

See Also: recovery catalog, recovery catalog database, resynchronization


A method for opening a database that archives any current online redo logs (if using ARCHIVELOG mode), resets the log sequence number to 1, and clears the online redo logs. An OPEN RESETLOGS operation begins a new database incarnation. The starting SCN for the new incarnation, sometimes called the RESETLOGS SCN, is the incomplete recovery SCN of the media recovery preceding the OPEN RESETLOGS, plus one.

An OPEN RESETLOGS operation is required after incomplete recovery or recovery with a backup control file.

An OPEN RESETLOGS operation does not affect the recoverability of the database. Backups from before the OPEN RESETLOGS operation remain valid and can be used along with backups taken after the OPEN RESETLOGS operation to repair any damage to the database.


The replacement of a lost or damaged file with a backup. You can restore files either with commands such as UNIX cp or the RMAN RESTORE command.


The operation that updates the recovery catalog with current information from the target database control file. You can initiate a full resynchronization of the catalog by issuing a RESYNC CATALOG command. A partial resynchronization transfers information to the recovery catalog about archived redo logs, backup sets and datafile copies. RMAN performs resynchronizations automatically when needed.

retention policy

A user-defined policy for determining how long backups and archived logs need to be retained for media recovery. You can define a retention policy in terms of backup redundancy or a recovery window. RMAN retains the datafile backups required to satisfy the current retention policy, and any archived redo logs required for complete recovery of those datafile backups.

There should be a glossary entry for REDUNDANNCY.

rollback segments

Database segments that record the before-images of changes to the database.

rolling back

The use of rollback segments to undo uncommitted changes applied to the database during the rolling forward stage of recover.

rolling forward

The application of redo records or incremental backups to datafiles and control files in order to recover changes to those files.

See Also: recover, rolling back


System Backup to Tape. Most commonly used to specify a destination for RMAN commands used to back up to tape, such as "BACKUP DEVICE TYPE sbt DATABASE".

snapshot control file

A copy of a database's control file created in an operating system specific location by Recovery Manager. RMAN creates the snapshot control file so that it has a consistent version of a control file to use when either resynchronizing the recovery catalog or backing up the control file.

standby database

A copy of a production database that you can use for disaster protection.

stored script

A sequence of RMAN commands stored in the recovery catalog.

system change number (SCN)

A stamp that defines a committed version of a database at a point in time. Oracle assigns every committed transaction a unique SCN.

SYSTEM tablespace

The tablespace that contains the Oracle data dictionary for a database, which is the metadata that describes the complete contnents of the database. The SYSTEM tablespace is unlike other tablespaces in that all datafiles contained in the tablespace must be online for Oracle to function. If a media failure affects one of the datafiles in SYSTEM, then you must mount the database and recover.

tablespace point-in-time recovery (TSPITR)

The recovery of one or more non-SYSTEM tablespaces to a noncurrent time. You can use either RMAN or user-managed methods to perform TSPITR.

target database

In RMAN, the database that you are backing up or restoring.


A file that belongs to a temporary tablespace, and is created with the TEMPFILE option. Temporary tablespaces cannot contain permanent database objects such as tables, and are typically used for sorting. Because tempfiles cannot contain permanent objects, RMAN does not back them up. However, RMAN does keep track of the locations of tempfiles in the control file, and during recovery the tempfiles will be re-created as needed at those locations.

transportable tablespace

A feature that transports a set of tablespaces from one database to another, or from one database to itself. Transporting a tablespace into a database is like creating a tablespace with preloaded data.

undo tablespace

A dedicated tablespace that stores only undo information when the database is run in automatic undo management mode.

unused block compression

A method by which RMAN reduces the size of backup sets containing datafile backups by skipping some datafile blocks that are not currently in use. More details about when blocks can be skipped are in Oracle Database Backup and Recovery Reference.

user-managed backup

A backups made using a non-RMAN method, for example, using an operating system utility. For example, you can make a user-managed backup by running the cp command on UNIX or the copy command on Windows. A user-managed backup is also called an operating system backup.

user-managed backup and recovery

A backup and recovery strategy for an Oracle database that does not use RMAN. This term is equivalent to operating system backup and recovery. You can back up and restore database files using operating system utilities (for example, the cp command in UNIX), and recover using the SQL*Plus RECOVER command.


A test that checks whether a backup can be restored. RMAN scans the backups and looks at the checksum to verify that the contents can be successfully restored.

See Also: crosscheck, media manager, recovery catalog

whole database backup

A backup of the control file and all datafiles that belong to a database.

See Also: backup