将讨论如下的诊断步骤：

　　1) 描述清楚出现的现象问题

　　2) 寻找具体错误

　　3) 收集操作系统级别上的数据

　　4) 获取systemstate和hanganalyze的dump

　　5) 获取STATPACK的输出报告

　　6) 获取PROCESSSTATE的dump

　　注：可能很多时候没有必要关闭数据库来停止hanging，建议如果要关闭数据库之前获取这些诊断信息以便找出错误的原因所在。

　　下面就来具体讨论如何诊断数据库Hanging问题。

　　描述清楚出现的现象问题：

　　先弄清楚运行的数据库版本，需要完整的版本号，例如9.2.0.4。

　　确定当前数据库是否是真的hanging还是处于活动状态但是运行的非常慢?检查下在Alert文件中是否还有日志切换，检查当前的CPU，I/O，内存的利用率。

　　查看数据库hanging的开始时间，持续了多长时间?数据库hanging是否是突然发生还是由于增加的活动事务导致性能的逐步降低?当前有多少的连接用户?最近的系统负载是否是在上升?

　　是否在初始化参数文件中设置了任何event?数据库当前正在做什么类型的事务?数据库的数据量多大?

　　数据库是运行在集群环境吗?如果是集群数据库，那么关闭其他实例就留下一个实例，问题是否还持续存在?这里讨论的某些解决方法适用于集群数据库，但是大部分的方法不适合。例如，一个不大的buffer cache通常对于集群数据库来说意味着较好的性能。关于集群数据库的大部分hanging的问题这里不做讨论，其中包括PCM锁问题，pinging，空间管理问题，节点间并行查询调优，共享磁盘或者虚拟共享磁盘问题，网络问题，DLM问题等。

　　数据库是运行在MTS环境下吗?如果取消MTS，是否问题持续存在?是否使用了Oracle的应用或者工具?最近是否升级了数据库，应用，工具或者操作系统，硬件?问题发生的频率?是否能够重现问题?

　　是否整个数据库都被hanging?

　　所有的实例?所有的连接?所有的操作?所有的节点?

　　首先确认是否能够执行查询select * from dual?日志文件多久切换一次?如果在Alert日志中有归档相关的错误信息，那么可以着手解决归档错误问题，因为归档问题经常会挂起数据库。例如：归档目的地空间满了，或者数据库处于归档模式下但是ARCH进程被停止了。一般可以先以sysdba权限连接到数据库中，执行ARCHIVE LOG LIST，查看数据库是否归档模式，是否启用了自动归档，一般如果没有启用自动归档，就很容易挂起数据库了，这个时候通常的做法就是把数据库改成自动归档模式或者是非归档模式。