The current log is the one LGWR is currently writing to. If the media failure is temporary, then correct the problem so that the database can reuse the group when required. Restore the database from a consistent, whole database backup datafiles and control files as described in "Restoring Datafiles Before Performing Incomplete Recovery".
Because online redo logs are not backed up, you cannot restore them with the datafiles and control files. In order to allow the database to reset the online redo logs, you must first mimic incomplete recovery:.
If the media failure is not temporary, then use the following procedure. Ensure that the current name of the lost redo log can be used for a newly created file. If not, then rename the members of the damaged online redo log group to a new location. If you have lost multiple groups of the online redo log, then use the recovery method for the most difficult log to recover.
The order of difficulty, from most difficult to least difficult, follows:. Skip Headers. CURRENT The online redo log is active, that is, needed for instance recovery, and it is the log to which the database is currently writing.
ACTIVE The online redo log is active, that is, needed for instance recovery, but is not the log to which the database is currently writing. Solve the problem by taking one of the following actions: If the hardware problem is temporary, then correct it. Note: The newly added member provides no redundancy until the log group is reused.
Recovering After the Loss of All Members of an Online Redo Log Group If a media failure damages all members of an online redo log group, then different scenarios can occur depending on the type of online redo log group affected by the failure and the archiving mode of the database. If the damaged log group is active, then it is needed for crash recovery; otherwise, it is not. If the group is. And you should. Inactive It is not needed for crash recovery Clear the archived or unarchived group.
Redo log files are filled with redo records. A redo record, also called a redo entry , is made up of a group of change vectors , each of which is a description of a change made to a single block in the database.
For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to the data segment block for the table, the undo segment data block, and the transaction table of the undo segments.
Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.
Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number SCN to identify the redo records for each committed transaction.
Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed. Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed.
If necessary, the database can roll back these changes. The redo log of a database consists of two or more redo log files. See "Managing Archived Redo Logs" for more information. LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure illustrates the circular writing of the redo log file.
The numbers next to each line indicate the sequence in which LGWR writes to each redo log file. Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled. Oracle Database uses only one redo log files at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file. Redo log files that are required for instance recovery are called active redo log files.
Redo log files that are no longer required for instance recovery are called inactive redo log files. 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. This section provides guidelines you should consider when configuring a database instance redo log and contains the following topics:.
To protect against a failure involving the redo log itself, Oracle Database allows a multiplexed redo log, meaning that two or more identical copies of the redo log can be automatically maintained in separate locations. For the most benefit, these locations should be on separate disks. When redo log files are multiplexed, LGWR concurrently writes the same redo log information to multiple identical redo log files, thereby eliminating a single point of redo log failure.
Multiplexing is implemented by creating groups of redo log files. A group consists of a redo log file and its multiplexed copies.
Each identical copy is said to be a member of the group. Each redo log group is defined by a number, such as group 1, group 2, and so on. Figure Multiplexed Redo Log Files. Each member in a group must be exactly the same size. Each member of a log file group is concurrently active—that is, concurrently written to by LGWR—as indicated by the identical log sequence numbers assigned by LGWR. The specific reaction of LGWR when a redo log member is unavailable depends on the reason for the lack of availability, as summarized in the table that follows.
If the database checkpoint has moved beyond the lost redo log, media recovery is not necessary, because the database has saved the data recorded in the redo log to the datafiles.
You need only drop the inaccessible redo log group. In most cases, a multiplexed redo log should be symmetrical: all groups of the redo log should have the same number of members. However, the database does not require that a multiplexed redo log be symmetrical. For example, one group can have only one member, and other groups can have two members.
This configuration protects against disk failures that temporarily affect some redo log members but leave others intact. The only requirement for an instance redo log is that it have at least two groups. Figure shows legal and illegal multiplexed redo log configurations.
The second configuration is illegal because it has only one group. When setting up a multiplexed redo log, place members of a group on different physical disks.
If a single disk fails, then only one member of a group becomes unavailable to LGWR and other members remain accessible to LGWR, so the instance can continue to function. If you archive the redo log, spread redo log members across disks to eliminate contention between the LGWR and ARC n background processes.
You can drop a redo log member only if it is not part of an active or current group. If you want to drop a member of an active group, first force a log switch to occur. Make sure the group to which a redo log member belongs is archived if archiving is enabled before dropping the member. When a redo log member is dropped from the database, the operating system file is not deleted from disk. Rather, the control files of the associated database are updated to drop the member from the database structure.
After dropping a redo log file, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log file.
Skip Headers. Dropping Redo Log Groups and Members In some cases, you may want to drop an entire group of redo log members. Before dropping a redo log group, consider the following restrictions and precautions: An instance requires at least two groups of redo log files, regardless of the number of members in the groups.
Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.
0コメント