一、案例说明
最近客户升级数据库，数据库本身不大，并且有足够的停机窗口，所以我们采用了最最安全的方式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博客 ” ，链接：https://blog.itpub.net/29371470/viewspace-1062863/ ，如需转载，请注明出处，否则将追究法律责任。
