诊断Oraacle数据库Hanging问题

核心提示： 如果是一个视图，那么需要查看视图建立在的表的信息：SELECT textFROM sys.dba_viewsWHERE view_name = '<VIEWNAME>';大规模的更新操作（例如使用SQLLDR，诊断Oraacle数据库Hanging问题(4)，I

如果是一个视图，那么需要查看视图建立在的表的信息：SELECT text
FROM sys.dba_views
WHERE view_name = '<VIEWNAME>';

大规模的更新操作（例如使用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在共享池中。