公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2016-07-04 23:47:35 · 原文链接

今天在看一个网友问题的时候，发现我的测试环境有些日子没有碰，竟然有一些问题，虽然说不上来，但是感觉数据库环境很卡，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