科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道诊断Oracle数据库Hanging问题

诊断Oracle数据库Hanging问题

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

适用范围:Oracle任何平台上的企业版数据库 适用对象:所有数据库管理员和数据库支持人员 本文目的:这篇文章主要描述用于诊断数据库hanging和性能问题的方法和 工具,这些问题可能是由于调整问题。

作者:中国IT实验室 来源:中国IT实验室 2007年10月7日

关键字: ORACLE

  • 评论
  • 分享微博
  • 分享邮件

在本页阅读全文(共6页)

   指定的数据库对象?

    在指定对象能是否能做任何操作?做一个select count(*)是否有问题?如果只是update该对象存在问题,那么可能锁了,可以从上面3)、4)中的脚本获取锁的信息。

    是否预先分配好了空间给这个对象?如果是,那么将提高HWM并且导致全表扫描,以至于让数据库看起来像是“挂起”了。全表扫描总是会扫描HWM,即使表只存在很少的数据。解决方案就是尽量避免预分配extents除非马上要执行一个大的并行插入或者常规的装载。千万不要在直接装载的时候预分配extents.

    如果对象是一个表,那么可以尝试

    ANALYZE TABLE <tablename> VALIDATE STRUCTURE CASCADE;

    是否有报错,如果有报错,意味着表或者表上的索引存在坏块了。如果没有报错,那么继续尝试下面的SQL语句得到相应的的信息:

    块级上的空间信息,一个高的chain out,也可能是问题的一部分。

    SELECT *

    FROM sys.dba dba_tables

    WHERE table_name = '<TABLENAME>';

    如果你有很多的更新和删除操作,那么一个不适合的索引也会造成问题,下面的SQL语句能帮你得到相关的索引信息:

    SELECT i.*

    FROM sys.index_stats i, sys.dba_indexes d

    WHERE i.name = d.index_name

    AND d.table_name = '<TABLENAME>';SELECT i.*

    FROM sys.index_stats i, sys.dba_indexes d

    WHERE i.name = d.index_name

    AND d.table_name = '<TABLENAME>';

    如果是一个视图,那么需要查看视图建立在的表的信息:

    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在共享池中。

    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语句,使用显性游标这些都可以减少网络的负载。

 

查看本文来源

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章