ITPub博客

首页 > 数据库 > Oracle > 数据库hang住,分析处理

数据库hang住,分析处理

Oracle 作者:wzhalal 时间:2013-12-12 17:49:23 0 删除 编辑

一、案例说明
最近客户升级数据库,数据库本身不大,并且有足够的停机窗口,所以我们采用了最最安全的方式expdp及impdp的方式,将数据库导出导入。但是在导入的过程中,我们在检查表空间变化时,一直没有动静!
SQL> select tablespace_name,sum(bytes/1024/1024/1024) gbytes from dba_free_space group by tablespace_name;

TABLESPACE_NAME                    GBYTES
------------------------------ ----------
TEST_INDEX1                    20.1948853
SYSAUX                         1.39544678
UNDOTBS1                       15.4883423
USERS                          .003601074
SYSTEM                         2.24859619
TEST_DATA1                     24.4277954

6 rows selected.

SQL> /

TABLESPACE_NAME                    GBYTES
------------------------------ ----------
TEST_INDEX1                    20.1948853
SYSAUX                         1.39544678
UNDOTBS1                       15.4883423
USERS                          .003601074
SYSTEM                         2.24859619
TEST_DATA1                     24.4277954

6 rows selected.

查看系统表间,一直没变化,感觉挺奇怪的,于是,我们又一次查看系统负载情况

[root@testdb ~]# top

top - 08:09:36 up 15:44,  3 users,  load average: 0.23, 0.22, 0.20
Tasks: 662 total,   1 running, 661 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.1%us,  0.1%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  49428444k total, 25010496k used, 24417948k free,   133088k buffers
Swap: 41943032k total,        0k used, 41943032k free,   907668k cached

可以看到没有负载,刚才存在的i/o也没有了,但我们的后台进程并没有结束,怀疑数据库出现了问题,于是我们采用hanganalyze进行分析。
SQL> oradebug setmypid; 
Statement processed.
SQL> oradebug hanganalyze 3;
Hang Analysis in /u01/app/oracle/diag/rdbms/testdb/testdb/trace/testdb_ora_11425.trc

[oracle@testdb ~]$ more /u01/app/oracle/diag/rdbms/testdb/testdb/trace/testdb_ora_11425.trc
Trace file /u01/app/oracle/diag/rdbms/testdb/testdb/trace/testdb_ora_11425.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/db1
System name:    Linux
Node name:      testdb
Release:        2.6.32-358.el6.x86_64
Version:        #1 SMP Fri Feb 22 00:31:26 UTC 2013
Machine:        x86_64
VM name:        VMWare Version: 6
Instance name: testdb
Redo thread mounted by this instance: 1
Oracle process number: 44
Unix process pid: 11425, image: oracle@testdb (TNS V1-V3)


*** 2013-12-05 09:35:21.247
*** SESSION ID:(1283.3) 2013-12-05 09:35:21.247
*** CLIENT ID:() 2013-12-05 09:35:21.247
*** SERVICE NAME:(SYS$USERS) 2013-12-05 09:35:21.247
*** MODULE NAME:(sqlplus@testdb (TNS V1-V3)) 2013-12-05 09:35:21.247
*** ACTION NAME:() 2013-12-05 09:35:21.247
 
Processing Oradebug command 'setmypid'

*** 2013-12-05 09:35:21.256
Oradebug command 'setmypid' console output:

*** 2013-12-05 09:35:31.208
Processing Oradebug command 'hanganalyze 3'

*** 2013-12-05 09:35:31.722
===============================================================================
HANG ANALYSIS:
  instances (db_name.oracle_sid): testdb.testdb
  oradebug_node_dump_level: 3
  analysis initiated by oradebug
  os thread scheduling delay history: (sampling every 1.000000 secs)
    0.000000 secs at [ 09:35:30 ]
      NOTE: scheduling delay has not been sampled for 0.724575 secs    0.000000 secs from [ 09:35:26 - 09:35:32 ], 5 sec avg
    0.000000 secs from [ 09:34:32 - 09:35:32 ], 1 min avg
    0.000000 secs from [ 09:30:32 - 09:35:32 ], 5 min avg
  vktm time drift history
===============================================================================
 
Chains most likely to have caused the hang:
 [a] Chain 1 Signature: 'control file sequential read'<='log file switch (archiving needed)'<='buffer busy waits'
     Chain 1 Signature Hash: 0x2ad21449
 [b] Chain 2 Signature: 'control file sequential read'<='log file switch (archiving needed)'<='buffer busy waits'
     Chain 2 Signature Hash: 0x2ad21449
 [c] Chain 3 Signature: 'control file sequential read'<='log file switch (archiving needed)'
     Chain 3 Signature Hash: 0x7df7ca49
 

可以看到最后,对chain 1进行了总结性的分析,buffer busy的产生,是由于没有归档,而没有归档,况且系统并没有i/o问题,也不存在其它负载。从后面的跟踪日志看,log file switch (archiving needed)等待了15分钟。所以基本上可以肯定是由于日志写不下去了,才导致情况的发生。
检查归档日志目录

SQL> select name,total_mb,free_mb from v$asm_diskgroup;

NAME                             TOTAL_MB    FREE_MB
------------------------------ ---------- ----------
ARCHDG                              51199    938

在这里,可以看到归档日志已经很少了,而我们的日志大小为:
SQL> select group#,bytes/1024/1024 mbytes from v$log;

    GROUP#     MBYTES
---------- ----------
         1       1024
         2       1024
         3       1024
         4       1024
         5       1024
可以看到日志大小为1g,所以是由于归档空间不够导致的。

解决办法:开启备份,将归档日志备份并从归档目录中删除掉后,任务继续!

二、hanganalyze分析说明

1、当前,hanganalyze有三种级别;

1.1、一种是会话级别的:

SQL> alter session set events 'immediate trace name hanganalyze level 3';

Session altered.

SQL> oradebug tracefile_name;
/u01/app/oracle/diag/rdbms/testdb/testdb/trace/testdb_ora_17310.trc

1.2、一种是实例级别:

SQL> oradebug setmypid; 
Statement processed.
SQL> oradebug hanganalyze 3;

1.3、一种是集群范围的:

SQL> oradebug setmypid;
Statement processed.
SQL> oradebug setinst all
Statement processed.
SQL> oradebug -g def hanganalyze 3;
Hang Analysis in /u01/app/oracle/admin/ncerp/bdump/ncerp1_diag_20154.trc

2、hanganalyze的列说明

sid是 Session ID
sess_srno是serial#
proc_ptr是Process Pointer
ospid 是OS Process ID
cnode是Node Id,Oracle9i才用
Nodenum是hanganalyze
自己为了记录这些会话而定制的编号,从0开始排起。
State 是node的状态
Adjlist是临近的node(通常代表一个blocker node)
Predecessor是Predecessor node ,通常代表一个 waiter node

如下所示:

([nodenum]/cnode/sid/sess_srno/session/  ospid/ state/start/finish/[adjlist]/predec
essor):
[780]/    0/    781/    13388/0x7645ac60/15488/  IGN/    1/     2/          /none
[781]/    0/    782/    38575/0x75460770/15494/NLEAF/    3/    4/     [832]/184

从上面的情况来看,NLEAF:通常可以看作这些会话是被阻塞的资源,那么可以看到nodenum为781是阻塞源,阻塞了832

state状态说明:
2.1、IN_HANG:这表示该node处于死锁状态,通常还有其他node(blocker)也处于该状态
2.2、LEAF/LEAF_NW:该node通常是blocker。通过条目的”predecessor”列可以判断这个node是否是blocker。LEAF说明该NODE没有等待其他资源,而LEAF_NW则可能是没有等待其他资源或者是在使用CPU.
2.3、NLEAF:通常可以看作这些会话是被阻塞的资源。发生这种情况一般说明数据库发生性能问题而不是数据库hang
2.4、IGN/IGN_DMP:这类会话通常被认为是空闲会话,除非其adjlist列里存在node。如果是非空闲会话则说明其adjlist里的node正在等待其他node释放资源。
2.5、SINGLE_NODE/SINGLE_NODE_NW:近似于空闲会话

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

请登录后发表评论 登录
全部评论

注册时间:2013-06-06

  • 博文量
    60
  • 访问量
    249789