Manage redo log files

7.1 What is redo log
The most critical part of the recovery operation is redo logs, which include two or more pre-allocated files to store all the changes in the database. Each database process is associated with the redo log to prevent instance failure.
7.1.1 redo thread
Each data process has its own redo log group. These redo log groups, multiplexing or one file, are called redo threads. In a typical configuration, only one database process is used in an oracle database. In a real cluster environment, two or more instances access one database at the same time, each instance has its own redo thread.
7.1.2 redo log Content
Redo log files are full of redo records. Redo records also become redo entries, which describe the changed individual blocks in the database.
Redo records allow you to fix all changes in the database, including undo segments. Therefore, online redo logs can protect rollback segments. When you use the redo log to restore the database, the database reads the changed values and changed blocks in the redo record.
7.1.3 How to Write redo log files to the database
The redo log file contains two or more redo log files. The database must contain at least two redo log files, one for writing, and the other for archiving (if the database is in archive mode ).
LGWR is written cyclically. When the current data file is full, LGWR will write a set of redo log files. When the last group of files is full, the database will re-write the first group of redo log files.
Whether LGWR can re-write a full log file depends on whether the archive file is enabled.
If the data is in non-archive mode (NOARCHIVELOG), all redo records in the redo log file must be written to the data file.
If the database is in ARCHIVELOG mode, the modification results of all redo records in the redo log file have been written into the data file, the archiving process has archived the redo log file.
7.1.4 active (current) and inactive redo log files
The database uses only one redo log file at a time to store the content in the redo log buffer.
If archiving is enabled, the database cannot be reused or overwrite an active redo log file before ARCn is archived. In non-archive mode, when the last redo log is full, LGWR overwrites an available redo log file.
7.1.5 log switching and log serial number
During log switching, the database stops writing the current log file and starts to write the next redo log file. Generally, the current redo log file is written and the next redo log file is written. You can set a fixed interval for redo logs. You can also manually force switch to redo log files.
Each time the log switches to lgwr and starts writing data, the database assigns a new log serial number to the redo log file. When the database archives online redo log files, the archived log retains its log serial number.
The serial number of each online or archived redo log is unique. When the instance fails or the media is restored, the database uses the necessary archiving and redo log files to sort and redo log files in ascending order.
7.2 redo log Planning
7.2.1 multiplexing of redo logs
Oracle allows you to configure several more redo log files to prevent any single file from being damaged. After multiple data files are reused, LGWR will write the same information to multiple redo log files at the same time to eliminate single point of failure (spof) of the redo log.
Multiplexing logs are called groups. Each log file in a group is called a member (member), and both A_log1 and B _log1 are members of group 1, a_log2 and B _log2 are both members of Group 2. Members in the same group have the same value.
Members in the same group are active at the same time, that is, information is written by LGWR at the same time. They all have the same log serial number. Members in different log groups are never written at the same time.
Response to redo log file failure
When LGWR cannot be written to a group member, the database marks that the member is invalid and sends an error message to the trace file of LGWR, indicating that the file is inaccessible in the database warning file.
Status
LGWR Behavior
LWGR can be successfully written to at least one member of the group.
Normally written, LGWR writes accessible redo log files and ignores inaccessible members.
LGWR cannot be switched to the next group because the group is waiting for archiving
Temporarily shut down the database, knowing that the next log file group can be accessed, or performing log Archiving
Due to media damage, members in the next group cannot access the media.
Oracle will return an error and the database instance is closed. In this case, you may need to restore the lost database log files.
If the database checkpoint has exceeded the lost log file, there is no need to restore the media because the data has been saved to the log file from the restructured log file. You can discard online redo log files that cannot be accessed. If the log file is not archived, use alter database clear unarchived log before the log is discarded.
 
 
Valid and invalid configurations
In most cases, the Members in the log group are symmetric. All log files should have the same members, but they are not required. The only requirement in Oracle databases is that the database must have at least two groups.
7.2.2 redo log files are placed on different Disks
When a reusable log file is set, it must be placed on different physical disks. If a single disk fails, only one member in the group is affected. The instance can continue to play its role.
7.2.3 set the size of the redo log file

Members in the same group must have the same size, and members in different groups can have different sizes. However, there is no benefit when the sizes of different groups are inconsistent. If no checkpoint is set for log switching, each group ensures that the checkpoint has the same interval.
7.2.4 select the number of redo log files
The best way is to test different configurations for a database instance to determine the number of redo logs. The best way is to use the least possible groups without affecting the LGWR write redo log information.
In some cases, a database requires two different groups of redo log files. In other cases, more groups are required for a database instance to ensure LGWR Data Writing. During the test, the simplest way to test whether the redo log group is sufficient is to check the trace file of LGWR and the warning file of oracle. If the message indicates that an LGWR instance has to wait because the checkpoint is not completed or the group is not archived, add a group.
Before creating or modifying a redo log instance, the parameter file limits the number of redo logs. The following parameter files limit the number of redo log files. You can modify them in the database.
1. The Maxlogfiles initialization parameter determines the maximum number of redo log groups for each database when creating a database. The value range of the number of groups is 1-maxlogfiles. The only way to modify this value is to re-create the database or modify the control file. Therefore, it is very important to consider this restriction before creating a database. If maxlogfiles is not specified during database creation, the default oracle value is used.
2. The Maxlogmembers initialization parameter determines the maximum number of members in each redo log group when creating a database. The only way to modify the value of maxlogfiles is to re-create the database or modify the control file. If maxlogmombers is not specified during database creation, the default oracle value is used.
 
7.2.5 control archiving latency
You can force all redo log threads to switch the current log file at a certain interval. In the master server configuration, archive logs are modified on the master server and then transmitted to the slave server. Changes on the slave server can lag behind the changes on the master server, because the changes on the slave server must wait until the changes on the master server are completed and then transmitted to the slave server. To limit this latency, you can modify the ARCHIVE_LAG_TARGET initialization parameter. This parameter allows you to decide how many seconds to archive.
Set ARCHIVE_LAG_TARGET initialization parameters
When you set this parameter, you must periodically check the current redo log file. If the following conditions occur, the instance will switch the log:
1. The current log was created n seconds ago and is estimated to be archived in m seconds. When the value of n + m exceeds the value of archive_lag_target.
2. When the current log contains a redo record.
 
7.3 create redo log groups and Members
Create Group
You must have the permission to modify the database to add log groups and Members. Determine the value of the maxlogfiles group.
Add group 4
Alter database add logfile ('/u01/app/oracle/oradata/orcl/redo04.log') size 8192 k;
Add group 5
Alter database add logfile group 5'/u01/app/oracle/oradata/orcl/redo05.log 'size 8192 k;
The number of groups must be between 1 and maxlogfiles, and the number of redo logs cannot be jumped.
Create a member
Add a new member redo02a. log to group 2:
Alter database add logfile member '/u01/app/oracle/oradata/orcl/redo02a. log' to group 2;
Note: The file name must be specified, but no size must be specified, because the size of the members in each group is consistent.
Or use
Add a new member redo02b. log to group 2:
Alter database add logfile member '/u01/app/oracle/oradata/orcl/redo02b. log 'to ('/u01/app/oracle/oradata/orcl/redo02.log ','/u01/app/oracle/oradata/orcl/redo02a. log ');
7.4 migrate and rename the redo log group members
1. Shut down the database
Shutdown immediate
2. Copy the redo log file to a new location.
 
Mv/u01/app/oracle/oradata/orcl/redo01.rdo/u01/app/oracle/oradata/orcl/redo01b. rdo
Mv/u01/app/oracle/oradata/orcl/redo02.rdo/u01/app/oracle/oradata/orcl/redo02c. rdo
 
3. Start the database to the mount status.
Connect/as sysdba
Startup mount
4. Rename the redo log Member
 
ALTER DATABASE
 
Rename file '/u01/app/oracle/oradata/orcl/redo01.rdo', '/u01/app/oracle/oradata/orcl/redo02.rdo'
 
TO '/u01/app/oracle/oradata/orcl/redo01b. rdo', '/u01/app/oracle/oradata/orcl/redo02c. rdo ';
5. Open the database
Alter database open;
7.5 Delete redo log groups and Members
You must have the alter database permission to delete data groups and Members. Note that
1. A database must have at least two redo log groups, one containing one or two members.
2. When the redo log group is inactive, you can delete it. If you want to delete a current log group, you need to force switch the redo log file.
3. before deleting the redo log, you must ensure that the data is archived.
Delete Group 4:
Alter database drop logfile group 4;
When you delete the redo log in the database but do not use the oracle-managed file feature, the redo log file is retained on the system. It only changes the control file in the database, you can use the redo system command to delete the redo log file.
If you use the oracle-manager file, the deletion of files on the disk is completed automatically.
Delete a member
1. Each group must contain two members to prevent spof.
2. The instance usually contains at least two redo log groups, regardless of the number of members in each group. If the group contains only one accessible member, you cannot delete it.
3. You can delete a member that is not in the current or active group. If you delete a member from the active group, you must forcibly switch to the redo log group.
4. You must archive the redo log group before deleting a member.
Delete redo02c. log from Group 2
Alter database drop logfile member '/u01/app/oracle/oradata/orcl/redo02c. log ';
When you delete the redo log in the database but do not use the oracle-managed file feature, the redo log file is retained on the system. It only changes the control file in the database, you can use the redo system command to delete the redo log file.
7.6 force log Switching
Force log switching.
Alter system switch logfile;
7.7 verify the redo log Block
 
7.8 clear redo log files
When the database is started, the redo log may be damaged because the database stops the activity because it cannot be archived, in this case, you can use alter database clear logfile to initialize files without shutting down the database.
Clear the log file data in group 3:
Alter database clear logfile group 3;
If data 3 is in use and you want to delete it, use
Alter database clear unarchived logfile group 3;
In this way, the data in the redo log file is not archived.
You may not be able to clear the data in the log group.
1. There are only two groups of log files.
2. The current log group is to be cleared.
7.9 view redo log information
V $ log;
V $ logfile;
V $ log_history