各位大侠:
    最近我的oracle特别慢,有时候编译一个存储过程需要几分钟,甚至编译就卡死在那里了.而有时候速度还可以
请各位大侠指点数据库为何慢?请指点跟踪和检查方法?

解决方案 »

  1.   


    编译一个存储过程需要几分钟
    是SQL 写的不好,可以把你的SQL 贴出来看一下。 还有可以做个AWR 报告,分析下数据库.Oracle AWR 介绍
    http://blog.csdn.net/tianlesoftware/archive/2009/10/17/4682300.aspx
      

  2.   

    看看session,是不是有死锁出现了。
      

  3.   

    是不是你的sql太长了,我的一条sql有2126行,在编译的时候要编译20分钟。
      

  4.   

    在test窗口中跟踪存储过程,定位存储过程的瓶颈后,优化sql语句
      

  5.   

    重启数据库——————哈哈,这个是绝招——就算是生产库也该停机维护一下了,看来你的数据库服务器是在WIN下的非LINUX的
      

  6.   

    如果是时快时慢,估计不是存储的问题,慢的时候有可能是你的数据正在执行某些任务导致,建议你主要从执行任务的sql语句里来找,在10g的管理界面可以看到哪条语句占用cpu比较多,还有部分辅助优化!
      

  7.   

    编译一个存储过程慢 是因为你编译的存储过程出现了等待(可能是你存储过程依赖的对象正在被锁着)
    而与你存储过程内的sql写的好坏没关系。编译存储过程最好不要在系统繁忙的时候编译,很容易造成系统的HANG住。
      

  8.   

    我的系统在aix下(linux);我觉得是索表的原因,为什么经常会索表呢,这个事情很怪啊.大家爱接着讨论,
      

  9.   

    查查V$lock(锁掉的表,通常TX,TM锁)
    查查V$latch(是不是latch用光了,排队着呢)
      

  10.   

    不要在生产库上业务繁忙的时候编译存储过程,会产生ddl锁。
    获得Library Cache Pin 等待的对象,即查谁在等待library lock
    select addr,kglhdadr,kglhdpar,kglnaown,kglnaobj,kglnahsh,kglhdobj
    from x$kglob
    where kglhdadr in (select p1raw 
                            from v$session_wait
                            where event like 'library%')
      

  11.   

    SQL太长也会溢出的·小心点~
    问题不一定在数据库上面,先查查主机,再看看数据库吧!
      

  12.   

    今天应用系统直接垮掉,说是进程太多,后来自己好了,我估计是应用程序的问题;
    系统的cup和内存占用率都是很高的
      

  13.   

    有这么大的SQL?
    倒是见过 3万行的存储过程