|Oracle8 Backup and Recovery Guide
A unit which contains one or more tape drives, a robotic arm, and a shelf of tapes. The ATL is able to load and unload tapes into the tape drive from the shelf without operator intervention. More sophisticated tape libraries are able to identify each tape; for example, the robotic arm may have a bar-code reader which allows it to scan each tape's barcode and identify it. Synonymous with tape silo.
A term used in tablespace point-in-time recovery. The auxiliary set is the set of files not in the recovery set, which must also be restored in the clone database, for the point-in-time recovery set to be successful. These include:
A small amount of space is required by export for sort operations, and if a copy of the temporary tablespace is not included in the auxiliary set then it will be necessary to provide sort space either by creating a new temporary tablespace after the clone has been started up, or by setting autoextend to ON on the system tablespace files. See also recovery set.
A representative copy of data, made by taking a backup. In the context of Oracle, a backup could be made by:
To take an image copy of datafiles, control files and other Oracle database structures.
To backup: To make a representative copy of data. If the original data is lost, the backup can be used to reconstruct the lost information.
A keyword recognized by Recovery Manager. This keyword tells recovery Manager that the user wishes to backup data, and the data should be written out in a backup-set format (compare this to copy (2)).
A backup set is a backup for (one or more) Oracle files, where the files are multiplexed together. The reason for multiplexing is to give performance benefits by:
Files in a backup set must be extracted using a restore command. There are two types of backup sets:
Is created when a user backs up any datafiles, or a control file. This type of backup only contains datafile blocks that have been used; unused blocks are omitted (see never used blocks and compression).
Created when a user backs up archived logs.
A backup set is comprised of one or more physical files, called backup pieces.
A backup piece belongs to only one backup set. Typically, a backup set would consist of only one backup piece. The only time Recovery Manager creates more than one backup piece is when the piece size is explicitly limited by the user-this is by specifying the keyword `KBYTES' in a setlimit command. The only reason to specify KBYTES in a backup command, is when the storage or media manager you are writing your backup to is not able to support writing a file larger than `KBYTES' in size.
A whole backup is a backup of the control file and all datafiles which belong to a database. Whole backups can be taken at any time (i.e. the database can be mounted, open, closed etc.).
The smallest unit of an Oracle database, the size of which is determined by the parameter DB_BLOCK_SIZE at database creation.
A single change to a single data block. A change vector is the smallest unit of change. Also see redo record.
A channel is a Recovery Manager resource allocation. Every channel allocated starts a new Oracle server process, which performs backup restore and recovery actions. The more channels allocated the greater the potential degree of parallelism for backup, restore and recovery. The type of channel specified will determine whether the Oracle server process will attempt to read and write to disk, or through the Media Management Interface e.g.
Channels are always able to read and write datafiles to and from disk, no matter what their type.
When a checkpoint occurs, all modified database buffers in the SGA are written to the datafiles by DBWR. Once the checkpoint completes, the datafiles and control files are modified to reflect the fact that it has successfully completed.
An Oracle internal computed number stored in an Oracle block, which allows Oracle servers to validate the consistency of the block.
A subset of a database which is restored to a new location, and started up with a new instance name. The intended use of a clone database is usually to perform tablespace point-in-time recovery. A clone database consists of the recovery set and auxiliary set. The clone database has various substantive differences from a regular database copy.
A backup of one or more database files taken while the database is closed. Typically, closed backups are also whole database backups. If the database was closed cleanly, it means the all the files in the backup are consistent (see database backups - consistent, for more information). If the database was closed using a shutdown abort or the instance terminated abnormally, the backup must be recovered before it is consistent.
See closed backup
A file associated with a database that maintains the physical structure and timestamps of all files in that database. The control file is updated continuously during database use, and must be available for writing whenever the database is mounted or open.
A backup control file is a backup of the control file. Backup control files are typically restored when all copies of the current control file are damaged, and are sometimes restored before performing certain kinds of point-in-time recovery.
The current control file is the control file on disk - it is the most recently modified control file for that incarnation of the database. For a control file to be considered current during recovery, it must not have been restored from backup.
See database backups-consistent
To make a replica of an original.
It is possible to take copies of Oracle datafiles, control files, and archived redo logs in two ways: 1. using Operating System utilities (on Unix one could use cp, or dd). 2. using the Recovery Manager copy command.
A Recovery Manager keyword, which when used, will make a replica of a database's datafiles, control file or archived redo log. This replica is made by Oracle server process, allocated to a Recovery Manager channel, which reads the Oracle file, and writes a replica out to disk. An open database's datafiles can be copied using Recovery Manager without putting the databases' tablespaces into hot backup mode.
An Oracle block which is not in a recognized Oracle format, or whose internal contents are not consistent. Oracle identifies corrupt blocks as one of two types:
The only way a media corrupt block can be repaired, is:
If the media corruption is due to faulty hardware, neither solution above will work until the hardware fault is rectified.
A datafile that contains one or more corrupt blocks.
A consistent backup is whole database backup (all datafiles and control file) which can be opened with the RESETLOGS option without requiring any recovery (that is, you do not need to apply redo to any files in this backup for it to be consistent). Such a backup would have to be taken after a database has been shutdown cleanly. The database must remain closed until the backup has completed.
All files in a consistent backup (including the control file) must be checkpointed at the same SCN, and must not contain changes past that SCN. The only files in a consistent backup which are allowed to have older SCNs, are files in tablespaces which are read-only or offline normal.
An inconsistent database backup is a backup whereby some of the files in the backup contain changes which were made after the files have been checkpointed. This type of backup needs recovery before it can be made consistent. This type of backup is usually created by taking open-database backups; that is, the database is open while the files are being backed up. An inconsistent backup can also be created by backing up datafiles while a database is closed, either:
A database which is not available to users to query and update. Although the database is closed:
An instance which is started, and has the control file s associated with the database, mounted (that is, the control file s are open). A database is typically put in a mounted (but not opened) state for maintenance, or for restore and recovery.
A database which is available to users to query and update. The database is opened either automatically via a startup command or explicitly, via an alter database open command.
A datafile is a physical Operating System file on disk created by Oracle, which contains data structures such as tables and indexes. A datafile can only belong to one database (and in fact, can only belong to one tablespace).
A datafile which Oracle is attempting to read, but cannot be found. Attempts to access an inaccessible file results in errors. Typically, a file is inaccessible because the media on which it is stored is faulty, or the file has been moved or deleted.
A copy of a datafile on disk produced by either:
See file header
The Oracle archiver process (ARCH) is able to archive two copies of a redo log. This is called duplexing the archived redo log. This is done by setting LOG_ARCHIVE_DUPLEX_DEST in your init.ora file.
The first few blocks of an Oracle datafile. The file header contains bookkeeping information related to that file.
A type of media corruption which could occur when backing up an open database. This phenomenon occurs when DBWR is writing a block, at the same time an Operating System utility is reading the block for backup. The block the Operating System read may be 'split' i.e. the top of the block is written at one point in time, and the bottom of the block is written at another point in time. If this backup were used to restore from, and Oracle were to read the block, the block would be considered to be "corrupt."
This possible timing mismatch between Oracle writing a block, and the Operating System reading the same block is the reason tablespaces must be put in hot-backup mode before initiating Operating System backups. A database in hot backup mode writes whole Oracle data blocks out to the redo log, hence if a block is split in the backup, it will be repaired by rolling forward using the redo. Recovery Manager does not suffer from this problem, as the server process performing the backup (backup set or copy) detects if a block it reads for backup is split, and re-reads the block to get a consistent version.
A Recovery Manager backup set, which is not an incremental. Note that full does not refer to how much of the database, full refers to the fact that the backup was not an incremental backup. Hence it is possible to take a full backup of one datafile. Note it is possible to apply incremental backups of levels > 0 on top of a full backup, if it will roll the datafiles forward to a later time. The only difference between a full backup and an incremental level 0, is the full backup will not affect the number of blocks backed up by any subsequent incrementally. Compare this with backup-whole database.
An export of the whole database.
See resync- full
See open backup
A tablespace is put into "hot backup mode" when the command ALTER TABLESPACE <tablespace name> BEGIN BACKUP is run. This command is executed before taking open-database (that is, hot) backups.
This command is necessary before a user takes an operating system backup of (one or more) datafiles which compose the tablespace being backed up. It is not correct to use hot-backup mode when you use Recovery Manager to take backups. See fractured block
This term is used to identify the different "versions" of the same physical database. The incarnation of the database changes once it has been opened with the RESETLOGS option, to be able to distinguish it from the previous "version."
See database backups-inconsistent.
Incremental backups are a method by which you only backup modified blocks. An incremental level 0 backup, performs the same function as a full backup in that they both backup all blocks that have ever been used. The difference between an incremental level 0 backup and a full backup, is that a full backup will not affect what blocks are backed up by subsequent incremental backups, whereas an incremental backup will affect what blocks are copied out by subsequent incremental backups.
Incremental backups of levels > 0 backup only blocks which have changed since previous incremental backups. Blocks which have not changed will not be backed up.
A set of memory structures and Oracle code (including the background processes) resident in memory. The way an instance becomes created and resident in memory is by issuing a startup command. An instance can become resident in memory by issuing any of the following commands:
A utility provided by a third party vendor which 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 typically have the ability to control Automated Tape Libraries.
(also known as:
An Oracle published interface to which Media Management vendors have written compatible software libraries. This software integrates with Oracle so that an Oracle server process is able to issue commands to the Media Manager to write backup files out to sequential storage, and read files from sequential storage. The media manager will handle the actions required to load, label and unload the correct tape, when Oracle issues a request to backup or restore a file.
A term used to indicate there is more than one exact copy of data. This term is most widely used to indicate that hard disks are mirrored, so that if one of the disks becomes unavailable, the other disk can continue to service requests without interruptions.
To break a mirror is to tell the operating system or hardware managing the mirror that you no longer want the mirror image to be kept up-to-date. This is one method used for creating operating system database backups: all the tablespaces in the database are put in hot backup mode and the mirror is broken. All tablespaces are then taken out of hot-backup mode. A backup to tape is then taken from the broken half of the mirror. After the backup is complete, the mirror can then be resilvered.
To resilver a mirror is to tell the operating system or hardware managing the mirror that you want to refresh the old broken mirror from the half that is up-to-date, and then maintain both sides of the mirror.
See multiplexed control file
See multiplexed online redo log
Oracle is able to maintain more than one copy of the online log automatically: this is called multiplexing the online log. This is controlled by creating multiple members in each redo log group. The degree of multiplexing is directly related to the number of members in each group. Also known as mirrored online redo logs
Oracle is able to maintain more than one copy of a database's control file; this is called multiplexed control files. This is controlled by specifying multiple entries in the init.ora CONTROL_FILES parameter. Also known as mirrored control files.
Datafile blocks included in the same backup set are multiplexed together. This means that blocks from files in this set are interspersed with blocks from the other files in that set.
see duplexed archive redo logs
A never-used block is an Oracle block which has never contained any data. An newly created datafile would contain many never-used blocks. When Oracle writes out backup sets, it only includes blocks which have been used (it does not write out never used blocks) i.e. the datafiles are "compressed."
A tablespace which is not available to users when the database is open. A tablespace can only be taken offline by a DBA while the database is open. If a tablespace is taken offline, all files that comprise the tablespace (that are not already offline) are taken offline.
A tablespace may be taken offline with three different priorities:
All the files in the tablespace are checkpointed, then made offline. If any file belonging to the tablespace is not available, the tablespace cannot be taken offline normal. Files in a tablespace taken offline cleanly do not need to be recovered before the tablespace is brought back online.
All files in the tablespace which are accessible to Oracle are checkpointed, then made offline. Files which were checkpointed by the offline-temporary command do not need recovery, however files which were not checkpointed (because they were not accessible at the time of the offline immediate command) must be recovered before the tablespace is brought back online.
All files in the tablespace are taken offline without any attempt to checkpoint the files first. All files in the tablespace must be recovered before the tablespace is brought online. The database must be open to take a tablespace offline.
This term is no longer used to refer to a closed database backup, as it causes confusion with offline tablespaces and datafiles.
This term is no longer used to refer to a closed database, as it causes confusion with offline tablespaces and datafiles.
A datafile which is not available to users when the database is open. A datafile can be taken offline either as a part of a tablespace offline or a datafile can be taken offline individually. In exceptional circumstances, Oracle will automatically take a datafile offline if it is required.
A datafile may be taken offline either:
A datafile taken offline by the alter database datafile command must be recovered before being brought back online. The offline command can be executed while the database is mounted or open.
A tablespace which is available to users if the database is open. A tablespace is made available for access by users by issuing the command ALTER TABLESPACE <name> ONLINE. The database must be open to alter a tablespace online, and all files in the tablespace must be consistent with the rest of the database before the tablespace can be made online.
This term is no longer used to refer to an open-database backup, as it causes confusion with online tablespaces and datafiles.
This term is no longer used to refer to an open database, as it causes confusion with online tablespaces and datafiles.
A datafile which is made available for access by users. The database can be open or mounted to issue the command ALTER DATABASE DATAFILE <filename> ONLINE. If the database is open, the file must be consistent with the remaining database before the it can be made online. If the database is mounted, the file can be made online without being consistent with the other datafiles (typically this is done before initiating a database recovery).
A backup of one or more datafiles taken while a database is open. This can be an operating system backup (which requires the tablespaces to be in hot backup mode), or a Recovery Manager backup (which does not need the tablespaces to be in hot backup mode).
To parallelize backup and restore using Recovery Manager multiple channels must be allocated.
Backup Set creation
Is parallelized by allocating multiple channels and also specifying filesperset.
File Copy creation
Is parallelized by allocating multiple channels, and by including multiple files to be copied within a single copy command.
Recovery Manager parallelizes restore. The degree of parallelism depends on the number of channels allocated, and also the distinct number of backup sets or file copies which are available to be read from.
Recovery Manager also parallelizes recovery when it is applying incremental backups. The degree of parallelism depends on the number of channels allocated, and also the distinct number of backup sets which are available to read from.
Irrespective of whether you use Recovery Manager or O/S backups, it is possible to use recovery_parallelism to parallelize the application of redo logs.
A file created by orapwd command.
A database must use password files if you wish to connect internal over a network. For a more comprehensive explanation, see <Title>Oracle8 Server Administrator's Guide
See tablespace- read only
To make a restored file current.
To make a restored file current to a specific point in time. In ARCHIVELOG mode, you have the choice of complete or incomplete recovery (see recovery-complete, and recovery -incomplete).
For NOARCHIVELOG mode databases, the only option is to restore from the most recent backup. In exceptional circumstances, it may be possible to recover a datafile or database if the database is not in ARCHIVELOG mode. The only time it is possible to recover a NOARCHIVELOG mode database, is if none of the online logs have been overwritten since the backup
In this case all redo generated since the backup is still available, which means that recovery is possible.
Note that this situation is not typical. If you must be able to recover the database-not just restore it-the database must be in ARCHIVELOG mode. Note that you should not be backing up your online log, so this is *not* an option if you need to be able to recover your database in case of media failure.
A Recovery Manager command which will make a restored datafile newer by the application of incremental backups (if they exist) and then by the application of redo (archived and online redo logs).
A SQL command issued to make a restored file newer by the application of redo (archived and online redo logs).
To restore and recover a database and apply all redo generated (both in archived and online redo logs) since the backup. This type of recovery is typically performed when media failure damages one or more datafiles, or control file s. The damaged files are fully recovered using all redo generated since the restored backup was first made.
To restore a database from backup, and recover the database, but not apply all of the redo information generated since the backup.
Incomplete recovery is usually performed when:
In this case the database is recovered until the last archived log generated before the failure.
The requirement is to recover up until some point in time before an incorrect action occurred in the database. For example, a user mistakenly deletes payroll transactions before the transactions are sent to the payroll agency. In this example, the DBA will need to restore the whole database and then perform incomplete recovery up until the point just before the user deleted the transactions.
An archive log which is needed for complete recovery was not backed up, or the archived log contents are corrupt (e.g. due to media failure). In this case, the only option is to recover up to the missing log.
In all cases above, the database must be opened with the RESETLOGS option.
A recovery catalog is a set of Oracle tables and views which are used by Recovery Manager to store information about Oracle databases. This information is used by Recovery Manager to manage the backup, restoration and recovery of Oracle databases.
An Oracle database which contains a recovery catalog schema.
A tool used by DBAs to backup, restore and recover Oracle databases (datafiles, control files and archived logs). It can be used with a Recovery Catalog, or without. If a recovery catalog is not used, Recovery Manager decides how to backup, restore and recover the database using the database's control file.
A subset of a database's tablespaces that require point-in-time recovery to be performed on them. Also see auxiliary set.
A recovery of all datafiles and control file to a specific time which is not a full recovery.
A recovery of all datafiles in a tablespace to a specific time which is not the full recovery. This recovery is done in a clone database. The tablespace is then re-integrated into the original database. This feature is new to Oracle8.
online redo log
The online redo log is a set of two or more files which record all changes made to Oracle datafiles and control files. They are written to by LGWR. See also multiplexed online redo log.
current online redo log
The online redo log file (or group, in the case of multiplexed logs) which is currently being written to by LGWR.
archived redo log
This is also called the offline redo log. If the database is in ARCHIVELOG mode, as each online redo log is filled, it is copied to one (or more) archive log destination(s). This copy is the archived redo log.
See also duplexed archived redo logs
Each online redo log belongs to a group. A group must have at least one member, but may have more. If a redo log group has more than one member, it is said to be multiplexed.
Each Oracle instance has its own set of online redo log groups. These online redo log groups are called an instance's thread of online redo. In non-Oracle Parallel Server environments, one database has only one thread, belonging to the instance accessing it. In Oracle Parallel Server environments, each instance has a separate thread (i.e. each instance has it's own online redo log). Each thread has its own current log member.
A redo record is a group of change vectors describing a single, atomic change to the database. Redo records are constructed for all data block changes, and saved on disk in the online redo log. Redo records allow multiple database blocks to be changed so that either all changes occur, or no changes occur, despite arbitrary failures.
A Recovery Manager command which registers a database with the recovery catalog. Any resync catalog commands will result in the recovery catalog being updated with the database's current configuration.
A method for opening a database which results in the database incarnation changing, the log sequence number being reset to 1, and the online logs being reformatted (or created, if they do not already exist). Typically, a database is opened with the RESETLOGS keyword:
The reason for opening a database with this option is to prevent database corruption by ensuring that any archived logs created by that database in the past cannot erroneously be applied to this incarnation of the database.
To reconstruct or bring back an original copy of a file from backup.
A full catalog resync is a Recovery Manager operation which refreshes the Recovery Catalog with all changed information in the database's control file. Full resyncs should be initiated by a DBA frequently, by issuing the Recovery Manager command resync catalog. Full resyncs can also be initiated by Recovery Manager if it determines this action is necessary before executing certain commands.
Partial resyncs transfer information to the Recovery Catalog about archived redo logs, backup sets and datafile copies. Partial resyncs will not transfer information such as:
Partial resyncs are initiated by Recovery Manager:
Recovery Manager determines that a resync is necessary
Application of redo logs to datafiles and control files in order to recover them (that is, to recover changes to those files).
Acronym for System Backup to Tape
See Media Management Interface
A database which has been shutdown with the immediate, transactional or normal options. A database shutdown cleanly does not require recovery; it is already in a consistent state.
A copy of a database's control file taken by Recovery Manager. The snapshot control file is used by Recovery Manager to read a consistent version of a control file (either to resync the recovery catalog, or if a recovery catalog is not used, to be read by Recovery Manager to decide what actions to perform). A snapshot control file is created by Recovery Manager using the same Oracle code which creates backup control files (ALTER DATABASE BACKUP CONTROL FILE TO '<location>').
Staging of archived logs is a term used to describe restoring archived logs from tertiary storage (usually tape) to disk, in order to allow recovery to proceed.
A Recovery Manager command which converts a datafile copy into a datafile used by an Oracle database. It performs the equivalent function of the SQL command ALTER DATABASE RENAME DATAFILE FROM '<original name>' TO '<new name>', and also marks the datafile copy as no longer available.
A database is divided into one or more logical storage units called tablespaces. Each tablespace has a number of datafiles exclusively associated with it.
A tablespace whose status has been changed to prevent it from being updated. It is put in read-only mode by executing the SQL statement ALTER TABLESPACE <tablespace> READ ONLY. Typically, the reason for putting a tablespace in read-only mode is to be able to reduce the frequency it is backed up. For example, instead of backing up the tablespace nightly, it may be feasible to reduce the backup frequency, say to once a month, or less.
The longer the duration between backing up any tablespace, the longer you will need to retain your backup media and the larger the risk of failed backup media (as you will have copied it out fewer times).
See recovery-point-in-time tablespace
To write output to a tape drive fast enough to keep the tape constantly busy.
A piece of hardware which reads and writes magnetic tapes.
A term used by many vendors to mean one physical piece of tape media.