【正文】 so stores the time that the checkpoint SCN was allocated. This timestamp is only used to print a message to aid a person looking for a log. In addition, the checkpoint structure stores the number of the thread that allocated the checkpoint SCN and the current RBA in that thread when the checkpoint SCN was allocated. Having an explicitlystored thread RBA (as opposed to only having the checkpoint SCN as an implicit thread location pointer) makes the log sequence number (part of the RBA) and archived log name readily available for the singleinstance (. singlethread, non Parallel Server) case. A checkpoint structure for a port that supports up to 1023 threads of redo is 150 bytes long. A VMS checkpoint is 30 bytes and supports up to 63 threads of redo. Log History The controlfile can be configured (using the MAXLOGHISTORY clause of the CREATE DATABASE or CREATE CONTROLFILE mand) to contain a history record for every logfile that is pleted. Log history records are small (24 bytes on VMS). They are overwritten in a circular fashion so that the oldest information is lost. For each logfile, the loghistory controlfile record contains the thread number, log sequence number, low SCN, low SCN timestamp, and next SCN (. low SCN of the next log in sequence). The purpose of the log history is to reconstruct archived logfile names from an SCN and thread number. Since a log sequence number is contained in the checkpoint structure (part of the RBA), single thread (. nonParallel Server) databases do not need log history to construct archived log names. The fields of the log history records are viewable via the V$LOG_HISTORY fixedview (see Section 9 for a description of the recoveryrelated fixedviews). Additionally, V$RECOVERY_LOG, which displays information about archived logs needed to plete media recovery, is derived from information in the log history records. Although log history is not strictly needed for easy administration of singleinstance (non Parallel Server) databases, enabling use of V$LOG_HISTORY and V$RECOVERY_LOG might be a reason to configure it. Thread Checkpoint Structure Each enabled thread39。s controlfile record contains a checkpoint structure called the thread checkpoint. The SCN field in this structure is known as the thread checkpoint SCN. The thread number and RBA fields in this structure refer to the associated thread. The thread checkpoint structure is updated each time an instance checkpoints its thread (see ). During such thread checkpoint events, the instance associated with the thread writes to disk in the online datafiles all dirty buffers modified by redo generated before the thread checkpoint SCN. A thread checkpoint event guarantees that all prethread checkpointSCN redo generated in that thread for all online datafiles has been written to disk. (Note that if the thread is closed, then there is no redo beyond the thread checkpoint SCN。 . the RBA points just past the last redo record in the current log.) It is the job of instance recovery to ensure that all of the thread39。s redo for all online datafiles is applied. Because of the guarantee that all of the thread39。s redo prior to the thread checkpoint SCN has already been applied, instance recovery can make the guarantee that, by starting redo application at the thread checkpoint SCN, and continuing through endofthread, all of the thread39。s redo will have been applied. Database Checkpoint Structure The database checkpoint structure is the thread checkpoint of the thread that has the lowest checkpoint SCN of all the open threads. The number of the database checkpoint thread the number of the thread whose thread checkpoint is the current database checkpoint is recorded in the database info record of the controlfile. If there are no open threads, then the database checkpoint is the thread checkpoint that contains the highest checkpoint SCN of all the enabled threads. Since each instance guarantees that all redo generated before its own thread checkpoint SCN has been written, and since the database checkpoint SCN is the lowest of the thread checkpoint SCNs, it follows that all predatabasecheckpointSCN redo in all instances has been written to all online datafiles. Thus, all predatabasecheckpointSCN redo generated in all threads for all online datafiles is guaranteed to be in the files on disk already. This is described by saying that the online datafiles are checkpointed at the database checkpoint. This is the rationale for using the database checkpoint to update the online datafile checkpoints (see below) when an instance checkpoints its thread (see ). Datafile Checkpoint Structure The header of each datafile contains a checkpoint structure known as the datafile checkpoint. The SCN field in this structure is known as the datafile checkpoint SCN. All precheckpointSCN redo generated in all threads for a given datafile is guaranteed to be in the file on disk already. An online datafile has its checkpoint SCN replicated in its controlfile record. Note: Oracle39。s recovery layer code is designed to tolerate a discrepancy in checkpoint SCN between the file header and the controlfile record. These values could get out of sync should an instance failure occur between the time the file header was updated and the time the controlfile transaction mitted. (Note: A controlfile transaction is an RDBMS internal mechanism, independent of the Oracle transaction layer, that allows an arbitrarily large update to the controlfile to be mitted atomically.) The execution of a datafile checkpoint (see ) for a given datafile updates the checkpoint structure in the file header, and guarantees