ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 数据库HANG着

数据库HANG着

原创 Linux操作系统 作者:psufnxk2000 时间:2011-09-06 16:52:14 0 删除 编辑

我想准确的来说,应该是连接的太慢了,因为连接太多了。

环境:aix 5.3  两节点的RAC ,其中B节点的crs监听没有启动。

情况:测试直接访问的B节点,做测试。

现象:B节点几乎登不上去,A节点可以连接。

解决:自己连接的时候发现,B节点连不上,A节点可以连接,看B节点的日志文件

 

Tue Sep  6 14:08:12 2011

MMNL absent for 1203 secs; Foregrounds taking over

Tue Sep  6 14:36:23 2011

>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=189

System State dumped to trace file /oracle/admin/sptdi/udump/sptdi2_ora_377866.trc

Tue Sep  6 14:38:30 2011

>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=118

System State dumped to trace file /oracle/admin/sptdi/bdump/sptdi2_j000_704994.trc

Tue Sep  6 14:42:15 2011

>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=22

System State dumped to trace file /oracle/admin/sptdi/bdump/sptdi2_smon_353140.trc

Tue Sep  6 14:43:33 2011

>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=128

System State dumped to trace file /oracle/admin/sptdi/bdump/sptdi2_pz98_562688.trc

Tue Sep  6 14:51:35 2011

PMON failed to acquire latch, see PMON dump

Tue Sep  6 14:52:12 2011

>>> WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! pid=23

System State dumped to trace file /oracle/admin/sptdi/bdump/sptdi2_reco_488516.trc

Tue Sep  6 14:52:35 2011

PMON failed to acquire latch, see PMON dump

Tue Sep  6 14:53:35 2011

PMON failed to acquire latch, see PMON dump

Tue Sep  6 14:54:35 2011

PMON failed to acquire latch, see PMON dump

Tue Sep  6 14:55:13 2011

MMNL absent for 3965 secs; Foregrounds taking over

第一句没有找到原因,以后找到原因再补上。下面的报错是因为‘等待太长时间的锁’,锁的原因。可是我又上不了B节点,怎么查锁呢?

B点:ps -ef | grep oraclesptdi2 | wc –l 110个连接,

A点:ps -ef | grep oraclesptdi1 | wc –l  60个连接,

我就kill -9 干掉一些B点的连接,然后登上B点,用SELECT RPAD (oracle_username, 10) o_name, session_id SID,

        DECODE (locked_mode,

                0, 'None',

                1, 'Null',

                2, 'Row share',

                3, 'Row Execlusive',

                4, 'Share',

                5, 'Share Row Exclusive',

                6, 'Exclusive'

               ) lock_type,

        object_name, xidusn, xidslot, xidsqn

   FROM v$locked_object, all_objects

WHERE v$locked_object.object_id = all_objects.object_id;查哪些会话补锁,找到之后, 再kill掉。

然后数据库回到正常状态,并把B点监听启动。

可是40分钟后,又一次出现这种情况,因为BCRS监听启动了,所以两个库连的都是很慢,可是这次却没报错。    领导让重启数据库

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25099483/viewspace-706764/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 0905
下一篇: Ora-04030
请登录后发表评论 登录
全部评论

注册时间:2011-05-31

  • 博文量
    215
  • 访问量
    630549