维护计划rebuild index job运行了n久,会是什么原因？

死锁了吗 sp_who  sp_who2看看

解决方案 »

  1.   

    不知道怎么看哎这个事情已经是上周末的事情了，而且job运行完是成功退出的，只是运行时间过长，影响了其他的job我现在用sp_who看了，不知道哪一列反映死锁的信息，但是一共返回1030行，大部分都是从一个application server连接到这个数据库的用户，用户名是同一个，因为我们不管application的情况，不知道这是不是正常的?
      

  2.   

    我还不知道怎么看死锁。。
    返回的1030行，大多是同一个login，而且是sleeping的。。不知道是不是不正常，要么去问问application的人了数据库不大，大概2G多如果这么多login都是sleeping这样连接着，就是说数据库正在运行，所以rebuild index就会这么慢？如果可以找到原因就好了。。
      

  3.   

    sp_who2怎么查看死锁或者阻塞或者任何不正常的情况啊？
      

  4.   

    sp_who2 active 看blkby列是否有值
    这个是看数据库是否有堵塞
      

  5.   

    那这个应该是有问题的,只有2G多的数据,不至于这么慢的.
    尝试单表rebuild 试试,
    找一个数据量小的表试试,
    如果没有问题的话,在尝试逐个单表rebuild,
    看看哪些表比较慢,
    然后检查一下这些表看看是否有异常.
      

  6.   

    今天早上查看了sp_who,比昨天还多了20行可是我查看Activity Monitor里面，发现这些1000多行的同一个login,都是
    Status       Command             Application 
    Sleeping     awaiting command    WebLogic JDBC driver 0329949等一串数字但是我看login time，发现都是发生在rebuild index运行时间过长之后这个这么多进程这样的状态是正常的么？因为我平时没注意这个，不知道以前怎么样的，而且这个进程还一直在增加，从开始发这个回贴到现在已经多了20多条了。
    这些进程的login time都在那次事故之后，是不是说明不是这个引起的？那我还要另找原因
      

  7.   

    今天早上查看了sp_who,比昨天还多了20行可是我查看Activity Monitor里面，发现这些1000多行的同一个login,都是
    Status       Command             Application 
    Sleeping     awaiting command    WebLogic JDBC driver 0329949等一串数字但是我看login time，发现都是发生在rebuild index运行时间过长之后这个这么多进程这样的状态是正常的么？因为我平时没注意这个，不知道以前怎么样的，而且这个进程还一直在增加，从开始发这个回贴到现在已经多了20多条了。
    这些进程的login time都在那次事故之后，是不是说明不是这个引起的？那我还要另找原因
      

  8.   

    今天早上查看了sp_who,比昨天还多了20行可是我查看Activity Monitor里面，发现这些1000多行的同一个login,都是
    Status       Command             Application 
    Sleeping     awaiting command    WebLogic JDBC driver 0329949等一串数字但是我看login time，发现都是发生在rebuild index运行时间过长之后这个这么多进程这样的状态是正常的么？因为我平时没注意这个，不知道以前怎么样的，而且这个进程还一直在增加，从开始发这个回贴到现在已经多了20多条了。
    这些进程的login time都在那次事故之后，是不是说明不是这个引起的？那我还要另找原因