数据库hang住的情况

本文通过一个实例展示了当Oracle数据库出现hang住情况时,如何利用会话信息和`oradebug hanganalyze`工具进行问题排查。通过分析挂起的会话和系统状态,结合`ass109.awk`工具,可以有效地定位并理解数据库hang住的原因。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

会话1:

SQL> create table test1(id int,name varchar2(20));

Table created.

SQL> insert into test1 values(1,'bing');
1 row created.
SQL> commit
Commit complete.
SQL> select userenv('sid') from dual;
USERENV('SID')
--------------
   147
SQL> select sid from v$mystat where rownum<2;
       SID
----------
       147
SQL> select * from test1;
ID NAME
---------- --------------------
 1 bing
SQL> update test1 set name='zhao' where id=1;------这里不提交

1 row updated.

会话2:

SQL> conn scott/tiger
Connected.
SQL> select sid from v$mystat where rownum<2;
       SID
----------
       138
SQL> select userenv('sid') from dual;
USERENV('SID')
--------------
   138

SQL> update test1 set name='zhao' where id=1;----这里就hang

会话3:

SQL> oradebug hanganalyze 3;
Hang Analysis in /u01/app/oracle/diag/rdbms/ogg2/ogg2/trace/ogg2_ora_5600.trc
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

查看里面的信息

    Oracle session identified by:
    {
                instance: 1 (ogg2.ogg2)
                   os id: 5526
              process id: 27, oracle@ogg5 (TNS V1-V3)
              session id: 138
        session serial #: 9
    and is blocked by
 => Oracle session identified by:
    {
                instance: 1 (ogg2.ogg2)
                   os id: 5453
              process id: 25, oracle@ogg5 (TNS V1-V3)
              session id: 147

        session serial #: 13

    }


SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit
Statement processed.
SQL> oradebug dump systemstate 266
Statement processed.
SQL> oradebug dump systemstate 266
Statement processed.
SQL> oradebug tracefile_name 
/u01/app/oracle/diag/rdbms/ogg2/ogg2/trace/ogg2_ora_5691.trc

SQL> exit

 通过ass109.awk文件,可以很容易将trace文件里的内容理出脉络来,清晰的发现问题所在。

ass109.awk这个要下载的,有系统也有自带。


总结

会话级别:SQL>ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level <level>';  

实例级别:SQL>ORADEBUG hanganalyze <level>  

各个level的含义如下:
1-2:只有hanganalyze输出,不dump任何进程
3:Level2+Dump出在IN_HANG状态的进程
4:Level3+Dump出在等待链里面的blockers(状态为LEAF/LEAF_NW/IGN_DMP)
5:Level4+Dump出所有在等待链中的进程(状态为NLEAF)
Oracle官方建议不要超过level 3,一般level 3也能够解决问题,超过level 3会给系统带来额外负担。

Oracle 数据库“真的”hang住了,可以理解为数据库内部发生死锁。因为普通的DML死锁,oracle服务器会自动监测他们的依赖关系,并回滚其中一个操作,终止这种相互等待的局面。而当这种死锁发生在争夺内核级别的资源(比如说是pins或latches)时,Oracle并不能自动的监测并处理这种死锁。其实很多时候数据库并没有hang住,而只是由于数据库的性能问题,处理的时间比较长而已。

Hanganalyze工具使用内核调用检测会话在等待什么资源,报告出占有者和等待者的相互关系。另外,它还会将一些比较”interesting”的进程状态dump出来,这个取决于我们使用hanganalyze的分析级别。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值