Online Redo Logs- Managing Control Files, Online Redo Logs,and Archivelogs
You are required to have at least two online redo log groups in your database. Each online redo log group must contain at least one online redo log member. The member is the physical file that exists on disk. You can create multiple members in each redo log group, which is known as multiplexing your online redo log group.
Tip Just like the control files are multiplexed, the online redo log groups should be as well and either be taking advantage of highly available storage or be on separate physical devices with separate controllers. Flash is another option for redo logs and can improve performance.
The log-writer log buffer (in the SGA) writes to online redo log files (on disk). The redo record has a system change number (SCN) assigned to it to identify the transaction redo information. There are committed and uncommitted records written to the redo logs. The log writer flushes the contents of the redo log buffer when any of the following
are true:
- A COMMIT is issued.
- A log switch occurs.
- Three seconds go by.
- The redo buffer is one-third full.
Since this is a database process, the container database (CDB) will manage the redo logs. PDBs do not have their own redo logs, which also means that planning for space and sizing the redo logs is at the CDB level and includes all of the PDB transactions.
The online redo log group that the log writer is actively writing to is the current online redo log group. The log writer writes simultaneously to all members of a redo log group. The log writer needs to successfully write to only one member for the database to continue operating. The database ceases operating if the log writer cannot write successfully to at least one member of the current group.
When the current online redo log group fills up, a log switch occurs, and the log write starts writing to the next online redo log group. A log sequence number is assigned to each redo log when a switch occurs to be used for archiving. The log writer writes to the online redo log groups in a round-robin fashion. Because you have a finite number of online redo log groups, eventually the contents of each online redo log group are overwritten. To save the history of the transaction information for recovery purposes, you must place the database in archivelog mode.
When your database is in archivelog mode, after every log switch the archiver background process copies the contents of the online redo log file to an archived redo log file. In the event of a failure, the archived redo log files allow you to restore the complete history of transactions that have occurred since your last database backup.
Figure 5-2 displays a typical setup for the online redo log files. This figure shows three online redo log groups, each containing two members. The database is in archivelog mode. In the figure, group 2 has recently been filled with transactions, a log switch has occurred, and the log writer is now writing to group 3. The archiver process is copying the contents of group 2 to an archived redo log file. When group 3 fills up, another log switch will occur, and the log writer will begin writing to group 1. At the same time, the archive process will copy the contents of group 3 to archive log sequence 3 (and so forth).
Figure 5–2. Online redo log configuration
The online redo log files are not intended to be backed up. These files contain only the most recent redo transaction information generated by the database. When you enable archiving, the archived redo log files are the mechanism for protecting your database transaction history.
The contents of the current online redo log files are not archived until a log switch occurs. This means if you lose all members of the current online redo log file, you lose transactions. Listed next are serval mechanisms of log files:
• Multiplex the groups.
• Consider setting the ARCHIVE_LAG_TARGET initialization parameter to ensure that the online redo logs are switched at regular intervals.
• If possible, never allow two members of the same group to share the same physical disk.
• Ensure that OS file permissions are set appropriately (restrictive, that only the owner of the Oracle binaries has permissions to write and read).
• Use physical storage devices that are redundant.
• Appropriately size the log files, so that they switch and are archived at regular intervals and not waiting for archive processing.
Since the logs are written out to archivelogs and require fast writes, flash drives are a way to improve the performance of redo logs. If flash is not available, the options are to place redo logs on physical disks and based on the previous list to minimize failures. Hard drive disks might not provide faster writes, which does not make them the ideal choice for redo logs.
The online redo logs are not the files that are being backed up. They write to the archive logs, and these files are backed up by RMAN. If you did back up the online redo log files, it would be meaningless to restore them. The online redo log files contain the latest redo generated by the database. You would not want to overwrite them from a backup with old redo information. The redo log files along with other data files should be excluded from other system backup (nondatabase).
