狂郁闷中，求救

HuiYiSky

先看看是什么级别的

cyzhang1983

oad Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:              6,152.96             19,081.41
              Logical reads:              1,971.94              6,115.33
              Block changes:                 43.49                134.88
             Physical reads:                  0.12                  0.39
            Physical writes:                  0.27                  0.85
                 User calls:                 32.56                100.97
                     Parses:                 12.08                 37.45
                Hard parses:                  0.28                  0.88
                      Sorts:                 19.21                 59.58
                     Logons:                  1.93                  5.98
                   Executes:                 14.16                 43.90
               Transactions:                  0.32

   Transactions:                  0.32  这么低，但是TX却59,962.74  ，明显太高了嘛。还是要从应用程序着手，比如一个事物，如果对一个表update,delete 完成后，应该commit;

fulzu

级别已经查不到了……

fulzu

现在比较奇怪，前11个小时正常，11个小时后开始有大量等待；前后环境一样 ，关键是不知道由什么引起的。

cyzhang1983

这种情况我也碰过，觉得也正常啊，开始的时候资源足够，后面抢来抢去 用完了，当然慢了。特别是有ENQUEUE的情况，你看看alert.log有没有死锁  或者 用 SQL_TRACE跟踪   应用程序都在等待什么操作。

fulzu

*** 2008-03-20 07:52:30.000
*** SESSION ID34.1418) 2008-03-20 07:52:30.000
DEADLOCK DETECTED
Current SQL statement for this session:
update WF_ATTRIBUTEINSTANCE set STRVALUE=:1 where NAME=:2 and OWNERID=:3 and OWNERTYPE=:4
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00080034-00000308        23      34     X             19      29           X
TX-00010021-000002ec        19      29     X             23      34           X
session 34: DID 0001-0017-00000002        session 29: DID 0001-0013-00000002
session 29: DID 0001-0013-00000002        session 34: DID 0001-0017-00000002
Rows waited on:
Session 29: obj - rowid = 000070FC - AAAHD8AABAAAEyZABT
  (dictionary objn - 28924, file - 1, block - 19609, slot - 83)
Session 34: obj - rowid = 000070EE - AAAHDuAAIAAAAFAAAZ
  (dictionary objn - 28910, file - 8, block - 320, slot - 25)
Information on the OTHER waiting sessions:
Session 29:
  pid=19 serial=2466 audsid=543436 user: 44/JIC
  O/S info: user: Administrator, term: , ospid: 1234, machine: tanstest2
            program:
  Current SQL Statement:
  update wf_pending set pendingState=-:"SYS_B_0" where workitemid=:"SYS_B_1" and (pendingState in (:"SYS_B_2")
End of information on OTHER waiting sessions.



这个怎么分析呢？怀疑是应用逻辑有问题，导致死锁了。

fulzu

是不是
update WF_ATTRIBUTEINSTANCE set STRVALUE=:1 where NAME=:2 and OWNERID=:3 and OWNERTYPE=:4
导致了
update wf_pending set pendingState=-:"SYS_B_0" where workitemid=:"SYS_B_1" and (pendingState in (:"SYS_B_2")
互相死锁呢？

cyzhang1983

是的，这就是死锁了。需要 修改应用程序。排除死锁的情况。如果是重复执行 类似的操作的话，系统肯定就慢了。

louis_xu

学习了