Skip Headers

Oracle® Database Backup and Recovery Basics
10g Release 1 (10.1)

Part Number B10735-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF


Glossary

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 offline 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.

ARCHIVELOG mode

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. Oracle automatically performs the archiving unless you execute ALTER DATABASE ARCHIVELOG MANUAL.

See Also: archived redo log, NOARCHIVELOG mode

archiving

The operation in which the archiver background process copies filled online redo logs to offline destinations. 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 persistent preconfiguration of RMAN channels. 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 preallocated 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

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 set to be successful.

See Also: auxiliary database, recovery set

backup

(1) A backup of data, that is, a database, tablespace, table, datafile, control file, or archived redo log. You can make a backup by:

(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. In a wider sense, backup and recovery also involves maintenance of backups and their associated metadata.

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. Updates to tablespaces in backup mode create more than the usual amount of redo because each change causes Oracle to write the entire block rather than just the changed data to the redo log.

See Also: corrupt block, online backup

backup piece

A backup piece is a physical file in an RMAN-specific format that belongs to only one backup set. A backup set usually contains only one backup piece. The only time RMAN creates more than one backup piece in a backup set is when you limit the backup piece size using the MAXPIECESIZE option of the ALLOCATE or CONFIGURE command.

See Also: backup, backup set, RMAN

backup retention policy

See retention policy

backup set

A backup of one or more datafiles, control files, archived logs, or backup sets produced by the RMAN BACKUP command. A backup set is a logical grouping of one or more binary files called backup pieces. Backup sets are in a proprietary format and can only be restored by RMAN.

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

block change tracking

An RMAN option that improves incremental backup performance. RMAN maintains a block change tracking file in the flash recovery area. This file logs a record of changed blocks, which RMAN can then read during an incremental backup so that it does not have to perform a full scan of the datafiles.

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.

channel

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. The type of channel (DISK or sbt) determines whether the Oracle server process will attempt to read or write and whether it will work through a third-party media manager.

See Also: media manager, target database

checkpoint

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 non-critical 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 it 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 online and archived 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

unused block compression

How RMAN conserves space by writing only used data blocks into RMAN backup sets. A newly created datafile contains many never-used blocks. When RMAN creates backup sets, it only includes blocks that have been used.

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. You can only take consistent backups after you have made a consistent shutdown of the database. The database must not be opened until the backup has completed.

See Also: fuzzy file, inconsistent backup

consistent shutdown
A database shut down with the IMMEDIATE, TRANSACTIONAL, or NORMAL options of the SHUTDOWN statement. A database shut down cleanly does not require recovery; it is already in a consistent state.
control file autobackup

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

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.

copy

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:

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 only repair a media corrupt block by recovering the block and 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

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

crosscheck

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. Those files to which LGWR is not writing are called inactive.

See Also: redo log, redo log groups

database checkpoint

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

See Also: checkpoint

database identifier

See DBID

database point-in-time recovery (DBPITR)

The recovery of a database to a specified noncurrent 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.

DBID

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

export

The extraction of logical data (that is, not physical files) from a database into a binary file using the Oracle export utility. You can then use the Oracle import utility to import the data into a database.

See Also: logical backups

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, similar to archived redo logs, used by the FLASHBACK command. 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. RMAN resynchronizes as needed when executing certain commands.

fuzzy file

A datafile that contains at least one block with an SCN more recent than 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:

inactive redo log

A redo log file that is not required for crash or instance recovery because the changes contained in its redo records have already been applied to the database. The current online redo log is never inactive. If you operate the database in ARCHIVELOG mode, the archiver process archives inactive redo log files.

See Also: online redo log, redo log, redo log groups

incarnation

A separate version of a physical 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

The recovery of a database in which you do not apply all of the changes generated since you created the restored backup. Is it the same as 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:

Inconsistent backups are only useful if the database is in ARCHIVELOG mode.

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, application error, or SHUTDOWN ABORT statement. Strictly speaking, an instance failure occurs whenever the database is not shut down consistently. 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: recover
LogMiner

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 backups

Backups in which an Oracle export utility extracts database data and then saves it to a binary file at the operating system level. You can then import the data back into a database with the corresponding Oracle import utility.

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 desired time required to perform instance 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

A physical problem that arises when Oracle fails in its attempt to write or read a file that is required to operate the database. Disk failure can affect a variety of files, including the datafiles, redo log files, and control files. Because the database instance cannot continue to function properly, it cannot write to the datafiles.

See Also: media recovery

media manager

A utility provided by a third party vendor that is capable of actions such as loading, labelling and unloading sequential media such as tape drives. Media managers also allow you to configure media expiration and recycling, and may also have the ability to control an ATL (automated tape library).

media recovery

The application of redo or incremental backups to a restored backup datafile or individual data block to bring it to a specified time. Datafile media recovery always begins at the lowest SCN recorded in the datafile headers.

When performing media recovery, you can recover a database, tablespace, datafile, or set of blocks within a datafile. In ARCHIVELOG mode, you have the choice of complete recovery or incomplete recovery. In NOARCHIVELOG mode, the only option is typically to restore from the most recent backup without applying redo.

See Also: block media recovery, recover

mirroring

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.

multiplexing

See Also: mirroring

NOARCHIVELOG mode

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 data.

See Also: archived redo log, ARCHIVELOG mode

noncircular reuse records

Control file records containing critical information needed by the Oracle database. These records do not change often and cannot be overwritten. Some examples of information in non-circular reuse records include datafiles and online redo logs.

See Also: circular reuse records

offline backup

A backup of a tablespace or datafile made when the tablespace or datafile is offline and the database open. Run the ALTER TABLESPACE OFFLINE statement to take a tablespace offline, and the ALTER DATABASE DATAFILE ... OFFLINE statement to take an individual datafile offline.

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. (ALTER DATABASE BEGIN BACKUP is an alternative when your database has many tablespaces, all of which need to be put in backup mode.) When you make an RMAN backup while the database is open, however, you should not put the tablespaces in backup mode.

online redo log

The online redo log is a set of two or more files that record all changes made to Oracle datafiles and control files. 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 the archiver process or processes copy the redo data into an archived redo log.

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 on the operating system 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 backups

See user-managed backups

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 are unusable because they belong to incarnations of the database that are not direct ancestors of 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.

parallelization

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 files

A file created by the ORAPWD command. A database must use password files if you wish to connect using the SYSDBA or SYSOPER roles over a network. For a more comprehensive explanation, 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.

pluggable tablespace

See transportable tablespace

proxy copy

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

recover

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: recover

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 information about Oracle databases. RMAN uses this data to manage the backup, restore, and recovery of Oracle databases. The recovery catalog is optional. If you do not use a recovery catalog, RMAN uses the target control file as the sole repository of metadata.

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)

A utility that backs up, restores, and recovers Oracle databases. 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 a media manager 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 a period of time in a retention policy bounded by the current time and the earliest point of recoverability. The point of recoverability is the end time for a hypothetical point-in-time recovery, that is, the point to which you must be able to recover following a media failure. A retention policy states that you must have enough backups and archived redo logs to be able to recover to any point between the current time and the point of recoverability.

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 groups

Each online redo log member (which corresponds to an online redo log file) belongs to a group. A group has one or more identical members. A multiplexed redo log is a redo log in which the redo groups have multiple members.

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.

registration

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

repository

The RMAN metadata about backup and recovery operations on the target database. Either the control file or the recovery catalog can function as the RMAN repository.

See Also: recovery catalog

RESETLOGS option

A method for opening a database that archives any current online redo logs (if using ARCHIVELOG mode), resets the log sequence number to 1, clears the online redo logs, and begins a new database incarnation. A database must be opened with the RESETLOGS keyword after incomplete recovery or recovery with a backup control file.

restore

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.

resynchronization

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. For example, if you need to recover the database to any point within the last 7 days, then at least one backup made 8 days ago or earlier must be retained. Also, you must retain all of the archived redo logs needed to perform the recovery.

RMAN

See Recovery Manager (RMAN)

rollback segments

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

rolling back

The use of rollback segments to undo uncommitted transactions 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

SBT

System Backup to Tape

snapshot control file

A copy of a database's control file taken in an operating system specific location by Recovery Manager. RMAN uses the snapshot control file to read a consistent version of a control file 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 SYSTEM tablespace differs from 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.

tempfile

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.

time-based recovery

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

See Also: incomplete recovery, media recovery, recover

transportable tablespace

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

undo tablespace

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

user-managed backups

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 backups.

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.

validation

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