ORA-16014 与 ORA-00312

Posted 2020-10-01 yxysuanfa

场景：

SQL> alter system archive log current;
alter system archive log current
*
第 1 行出现错误:
ORA-16014: 日志 2 sequence# 34 未归档, 没有可用的目的地
ORA-00312: 联机日志 2 线程 1: ‘+DATA_DG/orcl/onlinelog/group_2.258.885126161‘
ORA-00312: 联机日志 2 线程 1: ‘/orabak/clog/orcl02.log‘

环境是个人的实验环境。

排查：

切日志时发现该日志无法归档了。然后进行下面排查

1. 检查日志格式。确定日志格式log_archive_format正确

2. 检查日志归档文件夹正常。包含位置、权限、可用空间。确定无误

3. 查看错误日志

 cat /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_18338.trc

ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
DDE: Problem Key ‘ORA 313‘ was flood controlled (0x1) (no incident)
ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
Initial buffer sizes: read 1024K, overflow 832K, change 805K
DDE: Problem Key ‘ORA 313‘ was flood controlled (0x1) (no incident)
ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员

能够看到内存有一定溢出

分析：

经过排查能够确定是日志本身出现了问题，比較官方的解释例如以下

    ORA-01624: log string needed for crash recovery of instance string (thread string).

    Cause: A log cannot be dropped or cleared until the thread‘s checkpoint has advanced out of the log..

    Action: If the database is not open, then open it. Crash recovery will advance the checkpoint. If the database is open force a global checkpoint. If the log is corrupted so that the database cannot be opened, it may be necessary to do incomplete recovery until cancel at this log.

大概意思是检查点进程在一直在处理该文件，不能被删除或清除其内容，类似于卡死。能够通过recover来恢复。通过错误日志，我们猜測该问题非常有可能是由于内存溢出造成的。

查看内存：

[[email protected] ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          1878       1736        142          0          6        683
-/+ buffers/cache:       1045        832
Swap:         3999        354       3645

空暇内存不足，而且swap分区发生了交换。确实内存不足。

解决方式：

数据库有rman备份，启动到mount状态进行recover.

SQL>shutdown immediate

SQL>startup mount;

 

SQL>recover

ORA-00283: 恢复会话因错误而取消

ORA-00264: 不要求恢复

SQL>alter database open;

数据库已更改。

SQL>alter system archive log current;

系统已更改。

回想：

recover的时候报错了。但库启动后能够归档，而且是无损恢复，数据没有不论什么的丢失。那么这个过程发生了什么？

recover会读取日志文件、undo等文件，进行数据库事务的回滚前滚等操作，而在open数据库的时候还会对数据库文件的一致进行处理。

查看alert能够看到下面过程

Thread 2 advanced to log sequence 33 (before internal thread enable)
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_18338.trc:
ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_18338.trc:
ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
Archived Log entry 56 added for thread 2 sequence 32 ID 0xb9a2cd8c dest 1:
Thread 2 advanced to log sequence 34 (after internal thread enable)
Wed Jul 22 18:28:47 2015
ARC2 started with pid=35, OS id=18513 
Wed Jul 22 18:28:47 2015
Thread 1 opened at log sequence 39
  Current log# 1 seq# 39 mem# 0: +DATA_DG/orcl/onlinelog/group_1.257.885126161
  Current log# 1 seq# 39 mem# 1: /orabak/clog/orcl01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Jul 22 18:28:47 2015
SMON: enabling cache recovery
Instance recovery: looking for dead threads
Instance recovery: lock domain invalid but no dead threads
ARC1: Archival started

能够看到Oracle进行了缓存的恢复并对死进程进行了处理。