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.
Log Switches and Log Sequence Numbers
A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.
Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.
Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.
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.
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.
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.
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.
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.
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.
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.
incarnation
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.
RESETLOGS
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.
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.
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.
Checkpoint Process (CKPT)
When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk; DBWn always performs that work.
The statistic DBWR checkpoints displayed by the System_Statistics monitor in Enterprise Manager indicates the number of checkpoint requests completed.
See Also:
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for information about CKPT with Real Application Clusters
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.
Log Switches and Log Sequence Numbers
A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.
Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.
Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.
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.
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.
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.
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.
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.
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.
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.
incarnation
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.
RESETLOGS
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.
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.
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.
Checkpoint Process (CKPT)
When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk; DBWn always performs that work.
The statistic DBWR checkpoints displayed by the System_Statistics monitor in Enterprise Manager indicates the number of checkpoint requests completed.
See Also:
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for information about CKPT with Real Application Clusters
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
