一位老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.如果数据库层面无法解决,再辅助利用操作系统命令分析定位问题根源