Oracle 在警告日志中报告错误ORA-00338, ORA-00312

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

适用于:

Oracle Database – Enterprise Edition – Version 11.2.0.1 及以上
本文信息适用于任何平台。

症状

以下错误在一个RAC节点的警告日志中反复报告。
注意实际问题适用于RAC 和非RAC 数据库。

ORA-00338: log <Log_Number> of thread <thread_number> is more recent than control file
ORA-00312: online log <Log_Number> thread <thread_number>: ‘redo.log’

原因

The ORA-00338 normally indicates an incorrect control file may be used:

00338, 00000, “log %s of thread %s is more recent than control file”
// *Cause:  The control file change sequence number in the log file is
//         greater than the number in the control file. This implies that
//         the wrong control file is being used. Note that repeatedly causing
//         this error can make it stop happening without correcting the real
//         problem. Every attempt to open the database will advance the
//         control file change sequence number until it is great enough.
// *Action: Use the current control file or do backup control file recovery to
//         make the control file current. Be sure to follow all restrictions
//         on doing a backup control file recovery.

The error is reported when the log sequence number is greater than the sequence number in the control file.
The process that detects this, posts the entries to the alert log.

Given the normal cause of the error, please verify first that the correct control file is being used.

In this particular case the control file updates could not keep up with the rate of log switches, e.g. 5 to 6 per minute.
The difference in log sequence numbers came from the excessive redo log switches that occurred prior to the error.
Note that also “Log file switch (checkpoint incomplete)” messages were reported.

In this case, the customer mentioned that fast log switches were forced by the ‘storage side backup settings’, meaning their backup implementation/application issued fast ‘alter system switch log file’ commands.

解决方案

在验证正确的控制文件被适用，通过减少快速显式重做日志切换，该问题能被解决。

以防日志切换未被手动或由一个应用（如在这个情况中）强制，可以执行以下检查/行为：

• 查看重做日志文件大小，确保足以容纳工作负载。

  以下文档示例如何调整重做日志文件的大小

  Note 1035935.6 – Example of How To Resize the Online Redo Logfiles

  在调整重做日志文件大小后，监控你的数据库警告日志来确定日志切换之间的时间。

Oracle 建议每20~30分钟重做日志切换。

注意:
你能使用V$INSTANCE_RECOVERY 视图列OPTIMAL_LOGFILE_SIZE 来确定对你联机重做日志的建议大小。
该字段根据FAST_START_MTTR_TARGET的当前设置，以MB显示最优的重做日志文件的大小。
如果该字段连续显示高于你最小联机日志的大小的值，则你应至少配置所有的联机日志为该大小。

• 查看哪个会话在生成大量重做。
  以下文档显示如何找出哪个会话生成大量重做或归档数据：

   

  Note 167492.1 – SQL: How to Find Sessions Generating Lots of Redo or Archive logs

获得该错误的另一个可能原因是列出的重做日志无效(如包含0)，验证重做日志来确认它是否是有效重做。如果有0，且它是当前的联机日志，则我们需要查看还原/恢复选项。

例如:

SQL> alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02a.dbf’ validate;
alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02a.dbf’ validate
*
ERROR at line 1:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: ‘/u02/app/oracle/oradata/EBSPROD/redo/log02a.dbf’

…
SQL> alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02b.dbf’ validate;
alter system dump logfile ‘/u02/app/oracle/oradata/EBSPROD/redo/log02b.dbf’ validate
*
ERROR at line 1:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: ‘/u02/app/oracle/oradata/EBSPROD/redo/log02b.dbf’

In a Data Guard environment that uses ASYNC redo transport, if ORA-338 errors occur in NSA trace file, and the connection with the remote database is closed, and will not reopen until the next log switch, then it could be due to
Bug 12770551 – Frequent ORA-338 during controlfile restore with ASYNC Data Guard (Doc ID 12770551.8)