Background to the issue:
Customer feedback applications can not use the normal database after the restart, to assist investigation and the reasons
1> View question period alert log
Thread <number> cannot allocate new log, sequence <number> Checkpoint not complete Thread 1 cannot allocate new log, sequence 279334 Checkpoint not complete Current log# 4 seq# 279333 mem# 0: /u01/oradata/orcl/redo04.log Current log# 4 seq# 279333 mem# 1: /u03/oradata/orcl/redo04.log
There may be due to waiting for the redo log archiving, there is the following type of alarm information
ORACLE Instance <name> - Can not allocate log, archival required Thread <number> cannot allocate new log, sequence <number>
2> Analysis:
In general, because of redo log (redo log) after the log group will switch full, this time the event will trigger a checkpoint (checkpoint),
the checkpoint (checkpoint) will trigger a database writer process (DBWR) is activated , the data buffer in the dirty block is written back to disk data files,
as long as the dirty data is written back to disk event has not ended, then the database will not release the log group.
In archive mode, the ARCH process will be accompanied by the process will be archived redo log. If too fast redo log (redo log) generated when CPK or archive is not yet complete, LGWR has filled the rest of the log group,
but also to the current log group which wrote redo log when this time occurs conflict, the database will be suspended. And always will write an error message similar to the above alert.log in.
Further, in the redo log different periods of different services switching frequency, so this error occurred, or busy usually occurs when a large number of DML operations.
3> Solution:
1: increase in the size of REDO LOG FILE
Increasing the size of the redo log file is easy to operate, but the redo log file to do what is reasonable?
1: Reference V $ INSTANCE_RECOVERY in OPTIMAL_LOGFILE_SIZE field values, but this field has the potential to Null value unless you adjust the parameters of a value greater than 0 FAST_START_MTTR_TARGET
Redo log file size (in megabytes) that is considered optimal based on the current setting of FAST_START_MTTR_TARGET. It is recommended that the user configure all online redo logs to be at least this value.
It recommended that official documents are as follows:
You can use the V$INSTANCE_RECOVERY view column OPTIMAL_LOGFILE_SIZE to determine the size of your online redo logs. This field shows the redo log file size in megabytes that is considered optimal based on the current setting of FAST_START_MTTR_TARGET. If this field consistently shows a value greater than the size of your smallest online log, then you should configure all your online logs to be at least this size.
Note, however, that the redo log file size affects the MTTR. In some cases, you may be able to refine your choice of the optimal FAST_START_MTTR_TARGET value by re-running the MTTR Advisor with your suggested optimal log file size.
SQL> SELECT OPTIMAL_LOGFILE_SIZE FROM V$INSTANCE_RECOVERY;
2: The number of switches and the amount of the redo log generating redo log to determine
Awr_redo_size_history script can be analyzed using statistical moment, each hour, the size of the log file generated every day, then be certain period of time (frequent switching time period) archive log size and 15 to 20 minutes (if certain period of time to switch very frequent, almost impossible to use this rule, because the restructuring log will be very large) switch once calculated redo log size. Of course, this is not a universal rule, according to the actual business judgment, in most cases you can still refer to this
clip_image001
Computing redo log of a script for reference
SELECT (SELECT ROUND(AVG(BYTES) / 1024 / 1024, 2) FROM V$LOG) AS "Redo size (MB)", ROUND((20 / AVERAGE_PERIOD) * (SELECT AVG(BYTES) FROM V$LOG) / 1024 / 1024, 2) AS "Recommended Size (MB)" FROM (SELECT AVG((NEXT_TIME - FIRST_TIME) * 24 * 60) AS AVERAGE_PERIOD FROM V$ARCHIVED_LOG WHERE FIRST_TIME > SYSDATE - 3 AND TO_CHAR(FIRST_TIME, 'HH24:MI') BETWEEN &START_OF_PEAK_HOURS AND &END_OF_PEAK_HOURS );
2: Increase of the number of REDO LOG Group
Increasing the number of log group, in fact, does not solve the "Thread <number> can not allocate new log, sequence <number> Checkpoint not complete" the problem, but he was able to solve the following problem:
ORACLE Instance <name> - Can not allocate log, archival required
Thread <number> cannot allocate new log, sequence <number>
This is because after the ARCH process, not yet complete redo log files to the archive destination (the archive required), but this time due to redo log switch too fast or too little log group, must wait for the process to complete archival ARCR to cycle covered log group.
3: Tune checkpoint
the more difficult, refer to the official document: Note 147468.1 Checkpoint Tuning and Troubleshooting Guide
4：Increase I/O speed for writing online REDO log/Archived REDO
This applies to Thread <number> cannot allocate new log, sequence <number>
Checkpoint not complete
- use ASYNC I/O if not already so
- use DBWR I/O slaves or multiple DBWR processes
Reference:
Oracle Database Performance Tuning Guide
Instance Tuning Using Performance Views
Consider Multiple Database Writer (DBWR) Processes or I/O Slaves
- consider the generic recommendations for REDO log files:
If the high I/O files are redo log files, then consider splitting the redo log files from the other files. Possible configurations can include the following:
1. Placing all redo logs on one disk without any other files. Also consider availability; members of the same group should be on different physical disks and controllers for recoverability purposes.
2. Placing each redo log group on a separate disk that does not store any other files.
3. Striping the redo log files across several disks, using an operating system striping tool. (Manual striping is not possible in this situation.)
4. Avoiding the use of RAID 5 for redo logs.
Reference:
Oracle Database Performance Tuning Guide
Redo Log Files
For
ORACLE Instance <name> - Can not allocate log, archival required
Thread <number> cannot allocate new log, sequence <number
In the above document you may check section "Archived Redo Logs"
5: Find a large amount of redo logs SQL, SQL unreasonable if the business logic or place, it is necessary to modify, or to related tables to NOLOGGING, reduce redo logs
Those on how to localize SQL generated a lot of redo log, you can use LogMiner tool, you can refer to my blog post "How to locate those SQL generated a lot of redo log"
More please pay attention to micro-channel public number: data with others
