诊断Oracle数据库Hanging问题(2)

大规模的更新操作（例如使用SQLLDR，IMPORT或者批处理操作）？ 

这些操作上的表上存在有哪些索引？是否这些更新操作是在数据库高峰时期运行的？是否在Alert文件中存在有"checkpoint not complete"的错误信息？如果有表明重做日志文件太小了，需要调整它们。是否表空间被置于在热备模式下？(v$backup)如果表空间处于热备模式，那么产生日志”records”而不是“vectors”,在一个大的更新操作中，就可能导致相当多的竞争和性能下降。 

如果是一个SQLLDR操作，是否使用了传统路径方式？是否使用了REPLACE选项？(推荐使用TRUNCATE选项)在SQLLDR的控制文件中是否有sql functions？是否采用了readbuffers，bindsize，rows，parallele方式？ 

如果是一个IMPORT操作，是否使用了commit=y，indexes=y，constraints=y这些参数？是否增大了buffer？

如果在update期间，有很多的用户在操作，那么容易造成资源竞争，导致系统变慢。回滚段，redo latches, i/o和数据缓冲区都可能成为竞争的区域。我们可以从V$session_wait以及statpack中获取更多关于具体竞争的相关信息。

指定的包，存储过程或者PRO*C应用？ 

首先需要查看这些包，存储过程或者PRO*C的具体内容，其中的哪个语句一直在执行？去掉这个语句后相应的程序是否能运行正常？如果是存储过程，那么可以利用DBMS_ALERT查看那里开始挂起了。如果是PRO*C程序，那么可以使用tkprof来识别”parsing”是否是瓶颈？如果是，那么可以使用预编译参数hold_cursor和release_cursor来调整。如果是一个包，那么尝试是否能单独执行每个存储过程？查看是否包和存储过程被刷新出了共享池，如果是，可以尝试把这些包和存储过程pin在共享池中。

SELECT * 

FROM v$db_object_cache 

WHERE name = '<NAME>'; 

仅仅是远程访问？ 

是否可以执行select * from dual@db_link?是否能够连接到远程的机器上执行本地的操作？是否是在做一个分布式的更新操作？初始化参数distributed_lock_timeout设置了多少？是否正在刷新快照？是否使用了对称复制？尝试做一个tkprof输出得到相应的执行计划，执行计划中如果标明是REMOTE的，那么就是远程执行的操作。如果在一个远程的机器上join两张表，那么请尝试在本地节点上生成join视图之后，查询这个视图。在sql操作中设置ARRAYSIZE，多使用pl/sql而不是单独的sql语句，使用显性游标这些都可以减少网络的负载。

使用第三方应用软件的操作 

是否能在sqlplus中重现问题？如果不可以重现，那么就需要联系第三方应用软件供应商寻求帮助。

数据关闭/启动过程中出现挂起

关闭使用的什么参数？数据库是否crash了？如果是数据库启动挂起并且非正常关闭，但是在Alert日志文件中没有任何的错误，那么可能只是一个正常的实例恢复，如果在Alert文件中出现内部错误，系统错误，那么请尝试正常的关闭数据库然后启动。

下面是一个正常实例恢复的时候在Alert日志文件中列出的相关信息：

Starting ORACLE instance (normal)
Starting up ORACLE RDBMS Version: 10.2.0.1.0.

System parameters with non-default values:
Beginning crash recovery of 1 threads

Started redo scan

Completed redo scan

120 redo blocks read, 46 data blocks need recovery

Recovery of Online Redo Log: Thread 1 Group 2 Seq 143 Reading mem 0

Completed redo application

Completed crash recovery at

Thread 1: logseq 143, block 4358, scn 512699

46 data blocks read, 46 data blocks written, 120 redo blocks read

SMON: enabling cache recovery

SMON: enabling tx recovery

Completed: ALTER DATABASE OPEN 

在Unix系统上，还可以寻找正在挂起的启动或者关闭操作，然后trace pid。

寻找错误：

1) 检查AlertSID.log告警日志文件看看是否存在错误信息，此告警日志文件的具体路径位置可以由初始化参数中的background_dump_dest中获得或者在sqlplus中执行show parameter dest获得。

2) 检查上述目录中的在数据库挂起时间生成的跟踪文件。查看里面的错误信息，不用搜索整个跟踪文件，相关的错误信息一般都是在文件的最开始出现。

3) 如果是远程访问的问题，那么还需要检查sql*net跟踪目录下的跟踪文件。

4) 检查系统信息的错误日志，在大多数的Unix下都是在/var/adm目录下。