一位老DBA处理问题的方法
在此转摘以为老DBA处理问题的方法，我感觉很有借鉴意义，便在此分享：
上午接到用户的邮件说Oracle 数据库报错,连接数据库后什么都执行不了,错误信息如下:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared
pool","select u.name, o.name, trigg...","sga heap(1,0)","library cache")
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared
pool","select increment$,minvalue,m...","sga heap(1,0)","library cache")
看到错误代号,问题比较明显,ORA-04031,是比较常见的错误,共享池内存不够用了,办法很多,flush等,先不说 ,
还是想先连进去察看一下,于是
sqlplus / as sysdba
但是报错,没法连接进去,
ORA-01075: you are currently logged on
看样子问题比较严重了,共享池内存完全不够用了
于是想用srvctl重新启动
$ srvctl stop instance -d pccdv -i pccdv1
同样也报错,还是无法连接的原因导致的,
由于是RAC数据库,于是先测试另外一个节点会不会有问题
$ srvctl stop instance -d pccdv -i pccdv2
$ srvctl start instance -d pccdv -i pccdv2
发现没有问题可以正常启动关闭,所以基本确实数据库没有问题,instance级的问题
于是在问题节点察看alert_$SID.log文件
还是很多同样ORA-4031的错误
Wed Sep 24 10:26:37 2008
Errors in file /u01/app/oracle/admin/pccdvv/bdump/pccdv1_smon_1499372.trc:
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared pool","select o.name from obj$ o, t...","sga heap(1,0)","library
cache")
Wed Sep 24 10:26:37 2008
Errors in file /u01/app/oracle/admin/pccdvv/bdump/pccdv1_smon_1499372.trc:
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared pool","select o.name from obj$ o, t...","sga heap(1,0)","library
cache")
Wed Sep 24 10:26:47 2008
Errors in file /u01/app/oracle/admin/pccdvv/bdump/pccdv1_smon_1499372.trc:
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared pool","select o.name from obj$ o, t...","sga heap(1,0)","library
cache")
Wed Sep 24 10:26:47 2008
Errors in file /u01/app/oracle/admin/pccdvv/bdump/pccdv1_smon_1499372.trc:
ORA-04031: unable to allocate 4248 bytes of shared memory ("shared pool","select o.name from obj$ o, t...","sga heap(1,0)","library
cache")
Wed Sep 24 10:26:57 2008
由于连接不上出问题的Instance ,所以不能很好的解决问题,也不能安全的关闭/重起
于是从操作系统层面看看有没有办法,用topas,察看发现有一个进程比较异常,时常占用比较多的CPU
1499267 13.7%
$ ps -ef |grep 1499267
oracle 1499267 1 0 10:49:57 - 0:00 ora_cjq0_pccdv1
这个进程是oracle的job调度进程,也许是该进程出现异常了,不是核心的进程,于是kill掉了该进程
再用
sqlplus / as sysdba
可以连接,
于是使用关闭数据库
shutdown immediate
但是依然是错误,所以直接
shutdown abort
然后,先增加了shared pool size
再重新启动,系统恢复正常.
这个问题虽然简单,但处理的过程中还是经常被卡住诊断路径, 有些动作不能继续下去,说明处理这个问题的时候没有一个规范的有序的过程,所以处理问题不论简单复杂,都需要有一个规范的处理过程.而不要简单的看到一个错误代号就断章取义,错误代号仅仅代表结果,不会告诉你原因,而且往往出现问题的时候很多错误代号一起出现的,有时甚至会误导我们的判断.
我认为一个规范基本的处理过程至少包括以下步骤：
1.检查 alert_$SID.log,如果是RAC则每个节点都要检查
2.鉴别问题是database级别,还是Instance 级别
3.结合ORACLE的错误代号和症状,在数据库层面寻找解决办法
4.如果数据库层面无法解决,再辅助利用操作系统命令分析定位问题根源
5.问题确定后,使用数据库dbms或者操作系统层面的,技术和手段,解决问题
6.如果问题仍然无法解决,则收集所有相关的log,error等信息,则寻求技术服务上或软件硬件供应商技术支持
