停止数据库没有响应的问题分析(r9笔记第50天)

今天在看一个网友问题的时候，发现我的测试环境有些日子没有碰，竟然有一些问题，虽然说不上来，但是感觉数据库环境很卡，sqlplus登录需要花一些时间，每一个命令都会有卡顿。

这个时候，运行命令还是没有任何问题的。

SQL> show parameter control NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time integer 7 control_files string /U01/app/oracle/oradata/dgtest/control01.ctl, /U01/app/oracle/fast_recovery_area/dgtest/control02.ctl control_management_pack_access string DIAGNOSTIC+TUNING

因为是测试环境，查看没有其它的会话影响，就准备重启一下试试。

但是命令就卡在那里了，没有任何的输出和反应。

SQL> shutdown immediate

当然这是测试环境，也立马引起了我的重视。

通过sqlplus再次登录发现卡顿现象依旧存在。登录竟然要花费近5秒钟的时间。

$ time sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Mon Jul 4 23:05:16 2016 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected. SQL> SQL> exit Disconnected real 0m5.181s user 0m0.017s sys 0m0.009s

登录进去之后运行命令就会抛出异常了。

$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Mon Jul 4 23:05:43 2016 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected. SQL> show parameter back ORA-01012: not logged on Process ID: 0 Session ID: 0 Serial number: 0

我们来看看alert日志的内容，发现了下面这么一段信息：

*********************************************************************** ARCH: Archival stopped, error occurred. Will continue retrying ORACLE Instance dgtest - Archival Error ORA-16038: log 3 sequence# 126 cannot be archived ORA-19809: limit exceeded for recovery files ORA-00312: online log 3 thread 1: '/U01/app/oracle/oradata/dgtest/redo03.log' ARCH: Archival stopped, error occurred. Will continue retrying Archiver process freed from errors. No longer stoppedORACLE Instance dgtest - Archival Error ORA-16014: log 3 sequence# 126 not archived, no available destinations ORA-00312: online log 3 thread 1: '/U01/app/oracle/oradata/dgtest/redo03.log'

从日志可以看出是归档失败了，失败的原因也比较多了。我分析了以下几种可能。

首先查看内存结构依旧是存在的。

$ ipcs -m

------ Shared Memory Segments --------

key shmid owner perms bytes nattch status

0x00000000 4947969 oracle 640 33554432 24 locked

0x00000000 4980738 oracle 640 4982833152 24 locked

0xa9461d10 5013507 oracle 640 2097152 24 locked

通过这个和系统级的进程，发现数据库的进程还没有释放。

是否可能是$ORACLE_HOME的问题导致，因为我这个测试环境非常复杂了，$ORACLE_HOME环境有好几个，排查方法如下：

$ echo $ORACLE_HOME /U01/app/oracle/product/11.2.0.2/db_1 使用如下的方式来查看是否$ORACLE_HOME和设定的是一致的。 $ ps -ef|grep smon oracle 21033 20481 0 23:11 pts/1 00:00:00 grep smon oracle 26667 1 0 May11 ? 00:05:05 ora_smon_dgtest $ cat /proc/26667/environ|xargs -0 -n1 |grep ORACLE_HOME ORACLE_HOME=/U01/app/oracle/product/11.2.0.2/db_1 可以看出ORACLE_HOME是没有问题的。所以这些现象充分说明不是一些很特殊的原因导致的。此时能够排除的就是空间问题了。

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda7 6.0G 5.6G 105M 99% / tmpfs 7.8G 0 7.8G 0% /dev/shm /dev/sda1 124M 53M 65M 45% /boot /dev/sda8 371G 34G 318G 10% /DATA 根目录竟然还剩下近100M的空间，看起来是不够归档所用了。而归档文件是50M,看起来还是勉强可以的，这个地方就可以根据日志来分析了，存在多个归档路径，归档失败则都失败。 这个时候我们就采用了kill进程的方式快速完成这个操作。

$ kill -9 26667 $ ps -ef|grep smon oracle 21575 20481 0 23:14 pts/1 00:00:00 grep smon

原来窗口中就发生了变化：

主库： SQL> shutdown immediate ORA-03113: end-of-file on communication channel Process ID: 20422 Session ID: 190 Serial number: 8965

查看数据库日志如下： Client address: <unknown> Mon Jul 04 23:14:50 2016 PMON (ospid: 26643): terminating the instance due to error 474 Mon Jul 04 23:14:50 2016 System state dump requested by (instance=1, osid=26643 (PMON)), summary=[abnormal instance termination]. System State dumped to trace file /U01/app/oracle/diag/rdbms/dgtest/dgtest/trace/dgtest_diag_26653.trc Dumping diagnostic data in directory=[cdmp_20160704231450], requested by (instance=1, osid=26643 (PMON)), summary=[abnormal instance termination]. Instance terminated by PMON, pid = 26643

明白了我们的操作，再来看日志就发现问题很明显了，pmon因为error 474终止了实例。那么ORA-00474是什么错误呢，就是SMON进程终止。

$ oerr ora 00474 00474, 00000, "SMON process terminated with error" // *Cause: The system cleanup process died // *Action: Warm start instance 带着希望迅速重启数据库实例，发现启动到nomount阶段竟然还是很慢，问题的原因其实就好定位了，我们可以通过alert日志看到lock_sga是true,而默认是false,这个在启动时会相对比较慢，也有一定的适用场景。

SQL> show parameter sga NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ lock_sga boolean TRUE pre_page_sga boolean TRUE sga_max_size big integer 4784M sga_target big integer 0