DeadLocks on e_waitPipeNewRow Wait type

Hi Experts,
We are receiving hundread deadlocks daily with WaitType = "e_waitPipeNewRow". I am not sure why these deadlock occuring on prod server. I suspect this is reated to something to SSIS packages that are running on machine plus some latest
updates are missing on servers. Can you guys please throw some light on this and provide the solution to get rid of this.
Shivraj Patil.

Hi experts,
Which kind of this deadlock is normal or Intra para query dead lock , beacuse i see Page Lock keyword in Graph.
<deadlock>
<victim-list>
<victimProcess id="process2b41ce08" />
</victim-list>
<process-list>
<process id="process2b41ce08" taskpriority="0" logused="360" waitresource="PAGE: 10:5:451520" waittime="3255" ownerId="13432730290" transactionname="UPDATE" lasttranstarted="2014-11-25T19:26:25.777" XDES="0xe8b07d970" lockMode="IU" schedulerid="23" kpid="250372" status="suspended" spid="281" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-11-25T19:26:25.327" lastbatchcompleted="2014-11-25T19:26:25.327" clientapp=".Net SqlClient Data Provider" hostname="LDNPSM032220" hostpid="2240" loginname="INTRANET\sysCWBASPNET" isolationlevel="read committed (2)" xactid="13432730290" currentdb="10" lockTimeout="4294967295" clientoption1="538970208" clientoption2="128056">
<executionStack>
<frame procname="" line="259" stmtstart="27128" stmtend="29648" sqlhandle="0x03000a00c67da66c2575ac0051a300000100000000000000" />
</executionStack>
<inputbuf>
Proc [Database Id = 10 Object Id = 1822850502] </inputbuf>
</process>
<process id="process3243bb88" taskpriority="0" logused="10000" waittime="3156" schedulerid="36" kpid="281440" status="suspended" spid="277" sbid="0" ecid="2" priority="0" trancount="0" lastbatchstarted="2014-11-25T19:26:25.287" lastbatchcompleted="2014-11-25T19:26:25.287" clientapp=".Net SqlClient Data Provider" hostname="LDNPSM032220" hostpid="2240" isolationlevel="read committed (2)" xactid="13432730596" currentdb="10" lockTimeout="4294967295" clientoption1="538970208" clientoption2="128056">
<executionStack>
<frame procname="" line="279" stmtstart="29650" stmtend="30242" sqlhandle="0x03000a00c67da66c2575ac0051a300000100000000000000" />
</executionStack>
<inputbuf />
</process>
<process id="process32458bc8" taskpriority="0" logused="10000" waittime="3181" schedulerid="39" kpid="277808" status="suspended" spid="277" sbid="0" ecid="3" priority="0" trancount="0" lastbatchstarted="2014-11-25T19:26:25.287" lastbatchcompleted="2014-11-25T19:26:25.287" clientapp=".Net SqlClient Data Provider" hostname="LDNPSM032220" hostpid="2240" isolationlevel="read committed (2)" xactid="13432730596" currentdb="10" lockTimeout="4294967295" clientoption1="538970208" clientoption2="128056">
<executionStack>
<frame procname="" line="279" stmtstart="29650" stmtend="30242" sqlhandle="0x03000a00c67da66c2575ac0051a300000100000000000000" />
</executionStack>
<inputbuf />
</process>
<process id="process32431b88" taskpriority="0" logused="10000" waittime="3166" schedulerid="35" kpid="253808" status="suspended" spid="277" sbid="0" ecid="4" priority="0" trancount="0" lastbatchstarted="2014-11-25T19:26:25.287" lastbatchcompleted="2014-11-25T19:26:25.287" clientapp=".Net SqlClient Data Provider" hostname="LDNPSM032220" hostpid="2240" isolationlevel="read committed (2)" xactid="13432730596" currentdb="10" lockTimeout="4294967295" clientoption1="538970208" clientoption2="128056">
<executionStack>
<frame procname="" line="279" stmtstart="29650" stmtend="30242" sqlhandle="0x03000a00c67da66c2575ac0051a300000100000000000000" />
</executionStack>
<inputbuf />
</process>
<process id="process32445708" taskpriority="0" logused="10000" waittime="3203" schedulerid="37" kpid="277024" status="suspended" spid="277" sbid="0" ecid="1" priority="0" trancount="0" lastbatchstarted="2014-11-25T19:26:25.287" lastbatchcompleted="2014-11-25T19:26:25.287" clientapp=".Net SqlClient Data Provider" hostname="LDNPSM032220" hostpid="2240" isolationlevel="read committed (2)" xactid="13432730596" currentdb="10" lockTimeout="4294967295" clientoption1="538970208" clientoption2="128056">
<executionStack>
<frame procname="" line="279" stmtstart="29650" stmtend="30242" sqlhandle="0x03000a00c67da66c2575ac0051a300000100000000000000" />
</executionStack>
<inputbuf />
</process>
<process id="process5c4ee08" taskpriority="0" logused="10000" waittime="3136" schedulerid="18" kpid="261740" status="suspended" spid="277" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-11-25T19:26:25.287" lastbatchcompleted="2014-11-25T19:26:25.287" clientapp=".Net SqlClient Data Provider" hostname="LDNPSM032220" hostpid="2240" loginname="INTRANET\sysCWBASPNET" isolationlevel="read committed (2)" xactid="13432730596" currentdb="10" lockTimeout="4294967295" clientoption1="538970208" clientoption2="128056">
<executionStack>
<frame procname="" line="279" stmtstart="29650" stmtend="30242" sqlhandle="0x03000a00c67da66c2575ac0051a300000100000000000000" />
</executionStack>
<inputbuf>
Proc [Database Id = 10 Object Id = 1822850502] </inputbuf>
</process>
<process id="process32444988" taskpriority="0" logused="1138880" waitresource="PAGE: 10:12:435718" waittime="3258" ownerId="13432730596" transactionname="UPDATE" lasttranstarted="2014-11-25T19:26:25.800" XDES="0x18cb1136e0" lockMode="U" schedulerid="37" kpid="261676" status="suspended" spid="277" sbid="0" ecid="8" priority="0" trancount="0" lastbatchstarted="2014-11-25T19:26:25.287" lastbatchcompleted="2014-11-25T19:26:25.287" clientapp=".Net SqlClient Data Provider" hostname="LDNPSM032220" hostpid="2240" isolationlevel="read committed (2)" xactid="13432730596" currentdb="10" lockTimeout="4294967295" clientoption1="538970208" clientoption2="128056">
<executionStack>
<frame procname="" line="279" stmtstart="29650" stmtend="30242" sqlhandle="0x03000a00c67da66c2575ac0051a300000100000000000000" />
</executionStack>
<inputbuf />
</process>
</process-list>
<resource-list>
<pagelock fileid="5" pageid="451520" dbid="10" objectname="" id="lock178f827f80" mode="UIX" associatedObjectId="72057604489740288">
<owner-list>
<owner id="process5c4ee08" mode="IX" />
<owner id="process5c4ee08" mode="U" />
</owner-list>
<waiter-list>
<waiter id="process2b41ce08" mode="IU" requestType="wait" />
</waiter-list>
</pagelock>
<exchangeEvent id="Pipe149719eb00" WaitType="e_waitPipeGetRow" nodeId="8">
<owner-list>
<owner id="process32444988" />
</owner-list>
<waiter-list>
<waiter id="process3243bb88" />
</waiter-list>
</exchangeEvent>
<exchangeEvent id="Pipe149719eb80" WaitType="e_waitPipeGetRow" nodeId="8">
<owner-list>
<owner id="process32444988" />
</owner-list>
<waiter-list>
<waiter id="process32458bc8" />
</waiter-list>
</exchangeEvent>
<exchangeEvent id="Pipe149719ec00" WaitType="e_waitPipeGetRow" nodeId="8">
<owner-list>
<owner id="process32444988" />
</owner-list>
<waiter-list>
<waiter id="process32431b88" />
</waiter-list>
</exchangeEvent>
<exchangeEvent id="Pipe149719ea80" WaitType="e_waitPipeGetRow" nodeId="8">
<owner-list>
<owner id="process32444988" />
</owner-list>
<waiter-list>
<waiter id="process32445708" />
</waiter-list>
</exchangeEvent>
<exchangeEvent id="Pipe149719e300" WaitType="e_waitPipeGetRow" nodeId="3">
<owner-list>
<owner id="process32445708" />
<owner id="process3243bb88" />
<owner id="process32458bc8" />
<owner id="process32431b88" />
</owner-list>
<waiter-list>
<waiter id="process5c4ee08" />
</waiter-list>
</exchangeEvent>
<pagelock fileid="12" pageid="435718" dbid="10" objectname="" id="lockdfda7ef80" mode="IX" associatedObjectId="72057604489740288">
<owner-list>
<owner id="process2b41ce08" mode="IX" />
</owner-list>
<waiter-list>
<waiter id="process32444988" mode="U" requestType="wait" />
</waiter-list>
</pagelock>
</resource-list>
</deadlock>
Shivraj Patil.

Similar Messages

  • Database error"ORA-00060: deadlock detected while waiting for resource"

    Hi All,
    I got dump as
    Database error text........: "ORA-00060: deadlock detected while waiting for
      resource"
    Internal call code.........: "[RSQL/RDUP/NRIV ]"
    Please check the entries in the system log (Transaction SM21).
    An exception occurred that is explained in detail below.
    The exception, which is assigned to class 'CX_SY_OPEN_SQL_DB', was not caught
    in
    procedure "READ_NRIV" "(FORM)", nor was it propagated by a RAISING clause.
    Can u ppl tell me how to get correct this?
    Edited by: Bala Chandar on Jul 20, 2009 11:01 AM

    Hi Bala,
    Same type of dump we got when we trigger the DTP which in process chain to load data from DSO to Info cube. And the load had processed with 225 data package and at 164th data package we got this error and except 164th data package all data package processed successfully
    And the request was red. So we had done processed manually by clicking the icon. So all its been green and successfully loaded.
    So when you do process manual the particular data package which got failed will be process successfully  

  • Getting deadlock detected while waiting for resource error for select Query.....

    Hi all,
    i am getting a below error whenever executing the below select query....
    some times it will show dead lock detected while waiting for resource and terminated...
    some times it executes and gives result..
    but all the time it writes an alert to alert log
    Plesae suggest how to resolve the issue..........
    Thanks in advance
    Env: Linux / Oracle 11.2.0.3.3
    Error from alert log:
    Errors in file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc:
    ORA-00060: deadlock detected while waiting for resource
    ORA-10387: parallel query server interrupt (normal)
    Trace file info... bdrdb_p017_6076.trc:
    Trace file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    ORACLE_HOME = /u01/oracle/oracle/product/11.2.0/dbhome_1
    System name:    Linux
    Node name:      bdrdb.cteplindia.com
    Release:        2.6.18-308.el5PAE
    Version:        #1 SMP Fri Jan 27 17:40:09 EST 2012
    Machine:        i686
    Instance name: bdrdb
    Redo thread mounted by this instance: 1
    Oracle process number: 92
    Unix process pid: 6076, image: [email protected] (P017)
    *** 2013-11-04 23:18:57.915
    *** SESSION ID:(423.59970) 2013-11-04 23:18:57.915
    *** CLIENT ID:() 2013-11-04 23:18:57.915
    *** SERVICE NAME:(bdrdb) 2013-11-04 23:18:57.915
    *** MODULE NAME:() 2013-11-04 23:18:57.915
    *** ACTION NAME:() 2013-11-04 23:18:57.915
    *** 2013-11-04 23:18:57.915
    DEADLOCK DETECTED ( ORA-00060 )
    [Transaction Deadlock]
    Deadlock graph:
                           ---------Blocker(s)--------  ---------Waiter(s)---------
    Resource Name          process session holds waits  process session holds waits
    PS-00000001-00000011        92     423     S             33     128     S     X
    BF-2ed08c01-00000000        33     128     S             92     423     S     X
    session 423: DID 0001-005C-00081126     session 128: DID 0001-0021-00067D23
    session 128: DID 0001-0021-00067D23     session 423: DID 0001-005C-00081126
    DEADLOCK DETECTED ( ORA-00060 )
    [Transaction Deadlock]
    Deadlock graph:
                           ---------Blocker(s)--------  ---------Waiter(s)---------
    Resource Name          process session holds waits  process session holds waits
    PS-00000001-00000011        92     423     S             33     128     S     X
    BF-2ed08c01-00000000        33     128     S             92     423     S     X
    session 423: DID 0001-005C-00081126     session 128: DID 0001-0021-00067D23
    session 128: DID 0001-0021-00067D23     session 423: DID 0001-005C-00081126
    Rows waited on:
      Session 423: no row
      Session 128: obj - rowid = 00021DC1 - AAAh3BAAVAAAQL/AAA
      (dictionary objn - 138689, file - 21, block - 66303, slot - 0)
    ----- Information for the OTHER waiting sessions -----
    Session 128:
      sid: 128 ser: 46176 audsid: 1836857 user: 102/DBLOCAL
        flags: (0x8000041) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
        flags2: (0x40009) -/-/INC
      pid: 33 O/S info: user: oracle, term: UNKNOWN, ospid: 31611
        image: [email protected]
      client details:
        O/S info: user: masked, term: masked, ospid: 5924:568
        machine: masked program: Toad.exe
        application name: TOAD background query session, hash value=526966934
      current SQL:
        application name: TOAD background query session, hash value=526966934
      current SQL:
      SELECT  DISTINCT B_FP_TEST.TEST_ID
      FROM B_FP_TEST,
           B_USER_INFO,
           J_FP_INVESTIGATOR,
           L_TEST_STATUS,
           L_ATMS_TEST_TYPE,
           j_op_test_anml
    WHERE     B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
           AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
           AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
           AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
           AND B_FP_TEST.IS_DELETED = :"SYS_B_00"
           AND B_FP_TEST.TEST_NUM NOT IN (:"SYS_B_01", :"SYS_B_02", :"SYS_B_03")
           AND L_ATMS_TEST_TYPE.IS_DELETED = :"SYS_B_04"
           AND J_FP_INVESTIGATOR.is_pi = :"SYS_B_05"
           AND L_TEST_STATUS.STATUS IN (:"SYS_B_06", :"SYS_B_07", :"SYS_B_08")
           AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
    ----- End of information for the OTHER waiting sessions -----
    *** 2013-11-04 23:18:57.916
    dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
    ----- Error Stack Dump -----
    ORA-00060: deadlock detected while waiting for resource
    ORA-10387: parallel query server interrupt (normal)
    ----- SQL Statement (None) -----
    Current SQL information unavailable - no cursor.
    ----- Call Stack Trace -----
    calling              call     entry                argument values in hex
    location             type     point                (? means dubious value)
    More......
    Query:
    SELECT DISTINCT B_FP_TEST.TEST_ID
      FROM B_FP_TEST,
           B_USER_INFO,
           J_FP_INVESTIGATOR,
           L_TEST_STATUS,
           L_ATMS_TEST_TYPE,
           j_op_test_anml
    WHERE     B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
           AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
           AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
           AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
           AND B_FP_TEST.IS_DELETED = 0
           AND B_FP_TEST.TEST_NUM NOT IN (1, 2, 99)
           AND L_ATMS_TEST_TYPE.IS_DELETED = 0
           AND J_FP_INVESTIGATOR.is_pi = 1
           AND L_TEST_STATUS.STATUS IN ('Scheduled', 'In-Progress', 'Completed')
           AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
           AND (   (j_op_test_anml.end_date BETWEEN TO_DATE ('28-Oct-2013') - 1
                                                AND TO_DATE ('04-Nov-2013') + 1)
                OR (j_op_test_anml.start_date BETWEEN TO_DATE ('28-Oct-2013') - 1
                                                  AND TO_DATE ('04-Nov-2013') + 1)
                OR (TO_DATE ('28-Oct-2013') BETWEEN j_op_test_anml.start_date
                                                AND j_op_test_anml.end_date)
                OR (TO_DATE ('04-Nov-2013') BETWEEN j_op_test_anml.start_date
                                                AND j_op_test_anml.end_date))
           AND L_ATMS_TEST_TYPE.IS_DELETED = 0
           AND B_FP_TEST.DATASOURCE_ID = 9
    Query Exp plan:
    Plan hash value: 3398228788
    | Id  | Operation                                          | Name                | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT                                   |                     |  1501 |   102K|  1929   (1)| 00:00:24 |       |       |        |      |            |
    |   1 |  HASH UNIQUE                                       |                     |  1501 |   102K|  1929   (1)| 00:00:24 |       |       |        |      |            |
    |   2 |   CONCATENATION                                    |                     |       |       |            |          |       |       |        |      |            |
    |   3 |    PX COORDINATOR                                  |                     |       |       |            |          |       |       |        |      |            |
    |   4 |     PX SEND QC (RANDOM)                            | :TQ30005            |   241 | 16870 |   800   (1)| 00:00:10 |       |       |  Q3,05 | P->S | QC (RAND)  |
    |*  5 |      HASH JOIN                                     |                     |   241 | 16870 |   800   (1)| 00:00:10 |       |       |  Q3,05 | PCWP |            |
    |   6 |       PX RECEIVE                                   |                     |   246 | 15990 |   797   (1)| 00:00:10 |       |       |  Q3,05 | PCWP |            |
    |   7 |        PX SEND HASH                                | :TQ30004            |   246 | 15990 |   797   (1)| 00:00:10 |       |       |  Q3,04 | P->P | HASH       |
    |*  8 |         HASH JOIN                                  |                     |   246 | 15990 |   797   (1)| 00:00:10 |       |       |  Q3,04 | PCWP |            |
    |   9 |          PX RECEIVE                                |                     |   573 | 29223 |   793   (1)| 00:00:10 |       |       |  Q3,04 | PCWP |            |
    |  10 |           PX SEND HASH                             | :TQ30003            |   573 | 29223 |   793   (1)| 00:00:10 |       |       |  Q3,03 | P->P | HASH       |
    |* 11 |            HASH JOIN                               |                     |   573 | 29223 |   793   (1)| 00:00:10 |       |       |  Q3,03 | PCWP |            |
    |  12 |             BUFFER SORT                            |                     |       |       |            |          |       |       |  Q3,03 | PCWC |            |
    |  13 |              PX RECEIVE                            |                     |       |       |            |          |       |       |  Q3,03 | PCWP |            |
    |  14 |               PX SEND BROADCAST                    | :TQ30000            |       |       |            |          |       |       |        | S->P | BROADCAST  |
    |  15 |                NESTED LOOPS                        |                     |       |       |            |          |       |       |        |      |            |
    |  16 |                 NESTED LOOPS                       |                     |   485 | 20855 |   781   (0)| 00:00:10 |       |       |        |      |            |
    |  17 |                  TABLE ACCESS BY GLOBAL INDEX ROWID| J_OP_TEST_ANML      |   485 | 10185 |   296   (0)| 00:00:04 | ROWID | ROWID |        |      |            |
    |* 18 |                   INDEX RANGE SCAN                 | IDX$$_2D190001      |   485 |       |     4   (0)| 00:00:01 |       |       |        |      |            |
    |* 19 |                  INDEX UNIQUE SCAN                 | FT_TEST_ID_PK       |     1 |       |     0   (0)| 00:00:01 |       |       |        |      |            |
    |* 20 |                 TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST           |     1 |    22 |     1   (0)| 00:00:01 | ROWID | ROWID |        |      |            |
    |  21 |             PX BLOCK ITERATOR                      |                     | 70382 |   549K|    11   (0)| 00:00:01 |       |       |  Q3,03 | PCWC |            |
    |* 22 |              TABLE ACCESS FULL                     | J_FP_INVESTIGATOR   | 70382 |   549K|    11   (0)| 00:00:01 |       |       |  Q3,03 | PCWP |            |
    |  23 |          BUFFER SORT                               |                     |       |       |            |          |       |       |  Q3,04 | PCWC |            |
    |  24 |           PX RECEIVE                               |                     |     3 |    42 |     3   (0)| 00:00:01 |       |       |  Q3,04 | PCWP |            |
    |  25 |            PX SEND HASH                            | :TQ30001            |     3 |    42 |     3   (0)| 00:00:01 |       |       |        | S->P | HASH       |
    |* 26 |             TABLE ACCESS FULL                      | L_TEST_STATUS       |     3 |    42 |     3   (0)| 00:00:01 |       |       |        |      |            |
    |  27 |       BUFFER SORT                                  |                     |       |       |            |          |       |       |  Q3,05 | PCWC |            |
    |  28 |        PX RECEIVE                                  |                     |    30 |   150 |     3   (0)| 00:00:01 |       |       |  Q3,05 | PCWP |            |
    |  29 |         PX SEND HASH                               | :TQ30002            |    30 |   150 |     3   (0)| 00:00:01 |       |       |        | S->P | HASH       |
    |* 30 |          TABLE ACCESS FULL                         | L_ATMS_TEST_TYPE    |    30 |   150 |     3   (0)| 00:00:01 |       |       |        |      |            |
    |  31 |    NESTED LOOPS                                    |                     |       |       |            |          |       |       |        |      |            |
    |  32 |     NESTED LOOPS                                   |                     |     3 |   210 |   329   (1)| 00:00:04 |       |       |        |      |            |
    |  33 |      NESTED LOOPS                                  |                     |     3 |   195 |   329   (1)| 00:00:04 |       |       |        |      |            |
    |* 34 |       HASH JOIN                                    |                     |     2 |   114 |   325   (1)| 00:00:04 |       |       |        |      |            |
    |  35 |        NESTED LOOPS                                |                     |       |       |            |          |       |       |        |      |            |
    |  36 |         NESTED LOOPS                               |                     |     6 |   258 |   322   (1)| 00:00:04 |       |       |        |      |            |
    |  37 |          PARTITION RANGE SINGLE                    |                     |     6 |   126 |   316   (1)| 00:00:04 |     7 |     7 |        |      |            |
    |* 38 |           TABLE ACCESS FULL                        | J_OP_TEST_ANML      |     6 |   126 |   316   (1)| 00:00:04 |     7 |     7 |        |      |            |
    |* 39 |          INDEX UNIQUE SCAN                         | FT_TEST_ID_PK       |     1 |       |     0   (0)| 00:00:01 |       |       |        |      |            |
    |* 40 |         TABLE ACCESS BY GLOBAL INDEX ROWID         | B_FP_TEST           |     1 |    22 |     1   (0)| 00:00:01 | ROWID | ROWID |        |      |            |
    |* 41 |        TABLE ACCESS FULL                           | L_TEST_STATUS       |     3 |    42 |     3   (0)| 00:00:01 |       |       |        |      |            |
    |* 42 |       TABLE ACCESS BY INDEX ROWID                  | J_FP_INVESTIGATOR   |     1 |     8 |     2   (0)| 00:00:01 |       |       |        |      |            |
    |* 43 |        INDEX RANGE SCAN                            | FI_TEST_ID_PK       |     1 |       |     1   (0)| 00:00:01 |       |       |        |      |            |
    |* 44 |      INDEX UNIQUE SCAN                             | L_ATMS_TEST_TYPE_PK |     1 |       |     0   (0)| 00:00:01 |       |       |        |      |            |
    |* 45 |     TABLE ACCESS BY INDEX ROWID                    | L_ATMS_TEST_TYPE    |     1 |     5 |     1   (0)| 00:00:01 |       |       |        |      |            |
    |  46 |    PX COORDINATOR                                  |                     |       |       |            |          |       |       |        |      |            |
    |  47 |     PX SEND QC (RANDOM)                            | :TQ20003            |       |       |            |          |       |       |  Q2,03 | P->S | QC (RAND)  |
    |  48 |      NESTED LOOPS                                  |                     |       |       |            |          |       |       |  Q2,03 | PCWP |            |
    |  49 |       NESTED LOOPS                                 |                     |    33 |  2310 |   399   (2)| 00:00:05 |       |       |  Q2,03 | PCWP |            |
    |* 50 |        HASH JOIN                                   |                     |    33 |  2145 |   397   (2)| 00:00:05 |       |       |  Q2,03 | PCWP |            |
    |  51 |         PX RECEIVE                                 |                     |    78 |  3978 |   393   (1)| 00:00:05 |       |       |  Q2,03 | PCWP |            |
    |  52 |          PX SEND HASH                              | :TQ20002            |    78 |  3978 |   393   (1)| 00:00:05 |       |       |  Q2,02 | P->P | HASH       |
    |* 53 |           HASH JOIN                                |                     |    78 |  3978 |   393   (1)| 00:00:05 |       |       |  Q2,02 | PCWP |            |
    |  54 |            BUFFER SORT                             |                     |       |       |            |          |       |       |  Q2,02 | PCWC |            |
    |  55 |             PX RECEIVE                             |                     |       |       |            |          |       |       |  Q2,02 | PCWP |            |
    |  56 |              PX SEND BROADCAST                     | :TQ20000            |       |       |            |          |       |       |        | S->P | BROADCAST  |
    |  57 |               NESTED LOOPS                         |                     |       |       |            |          |       |       |        |      |            |
    |  58 |                NESTED LOOPS                        |                     |    66 |  2838 |   382   (1)| 00:00:05 |       |       |        |      |            |
    |  59 |                 PARTITION RANGE SINGLE             |                     |    66 |  1386 |   316   (1)| 00:00:04 |     7 |     7 |        |      |            |
    |* 60 |                  TABLE ACCESS FULL                 | J_OP_TEST_ANML      |    66 |  1386 |   316   (1)| 00:00:04 |     7 |     7 |        |      |            |
    |* 61 |                 INDEX UNIQUE SCAN                  | FT_TEST_ID_PK       |     1 |       |     0   (0)| 00:00:01 |       |       |        |      |            |
    |* 62 |                TABLE ACCESS BY GLOBAL INDEX ROWID  | B_FP_TEST           |     1 |    22 |     1   (0)| 00:00:01 | ROWID | ROWID |        |      |            |
    |  63 |            PX BLOCK ITERATOR                       |                     | 70382 |   549K|    11   (0)| 00:00:01 |       |       |  Q2,02 | PCWC |            |
    |* 64 |             TABLE ACCESS FULL                      | J_FP_INVESTIGATOR   | 70382 |   549K|    11   (0)| 00:00:01 |       |       |  Q2,02 | PCWP |            |
    |  65 |         BUFFER SORT                                |                     |       |       |            |          |       |       |  Q2,03 | PCWC |            |
    |  66 |          PX RECEIVE                                |                     |     3 |    42 |     3   (0)| 00:00:01 |       |       |  Q2,03 | PCWP |            |
    |  67 |           PX SEND HASH                             | :TQ20001            |     3 |    42 |     3   (0)| 00:00:01 |       |       |        | S->P | HASH       |
    |* 68 |            TABLE ACCESS FULL                       | L_TEST_STATUS       |     3 |    42 |     3   (0)| 00:00:01 |       |       |        |      |            |
    |* 69 |        INDEX UNIQUE SCAN                           | L_ATMS_TEST_TYPE_PK |     1 |       |     0   (0)| 00:00:01 |       |       |  Q2,03 | PCWP |            |
    |* 70 |       TABLE ACCESS BY INDEX ROWID                  | L_ATMS_TEST_TYPE    |     1 |     5 |     1   (0)| 00:00:01 |       |       |  Q2,03 | PCWP |            |
    |  71 |    PX COORDINATOR                                  |                     |       |       |            |          |       |       |        |      |            |
    |  72 |     PX SEND QC (RANDOM)                            | :TQ10003            |       |       |            |          |       |       |  Q1,03 | P->S | QC (RAND)  |
    |  73 |      NESTED LOOPS                                  |                     |       |       |            |          |       |       |  Q1,03 | PCWP |            |
    |  74 |       NESTED LOOPS                                 |                     |    33 |  2310 |   399   (2)| 00:00:05 |       |       |  Q1,03 | PCWP |            |
    |* 75 |        HASH JOIN                                   |                     |    34 |  2210 |   397   (2)| 00:00:05 |       |       |  Q1,03 | PCWP |            |
    |  76 |         PX RECEIVE                                 |                     |    78 |  3978 |   393   (1)| 00:00:05 |       |       |  Q1,03 | PCWP |            |
    |  77 |          PX SEND HASH                              | :TQ10002            |    78 |  3978 |   393   (1)| 00:00:05 |       |       |  Q1,02 | P->P | HASH       |
    |* 78 |           HASH JOIN                                |                     |    78 |  3978 |   393   (1)| 00:00:05 |       |       |  Q1,02 | PCWP |            |
    |  79 |            BUFFER SORT                             |                     |       |       |            |          |       |       |  Q1,02 | PCWC |            |
    |  80 |             PX RECEIVE                             |                     |       |       |            |          |       |       |  Q1,02 | PCWP |            |
    |  81 |              PX SEND BROADCAST                     | :TQ10000            |       |       |            |          |       |       |        | S->P | BROADCAST  |
    |  82 |               NESTED LOOPS                         |                     |       |       |            |          |       |       |        |      |            |
    |  83 |                NESTED LOOPS                        |                     |    66 |  2838 |   382   (1)| 00:00:05 |       |       |        |      |            |
    |  84 |                 PARTITION RANGE SINGLE             |                     |    66 |  1386 |   316   (1)| 00:00:04 |     7 |     7 |        |      |            |
    |* 85 |                  TABLE ACCESS FULL                 | J_OP_TEST_ANML      |    66 |  1386 |   316   (1)| 00:00:04 |     7 |     7 |        |      |            |
    |* 86 |                 INDEX UNIQUE SCAN                  | FT_TEST_ID_PK       |     1 |       |     0   (0)| 00:00:01 |       |       |        |      |            |
    |* 87 |                TABLE ACCESS BY GLOBAL INDEX ROWID  | B_FP_TEST           |     1 |    22 |     1   (0)| 00:00:01 | ROWID | ROWID |        |      |            |
    |  88 |            PX BLOCK ITERATOR                       |                     | 70382 |   549K|    11   (0)| 00:00:01 |       |       |  Q1,02 | PCWC |            |
    |* 89 |             TABLE ACCESS FULL                      | J_FP_INVESTIGATOR   | 70382 |   549K|    11   (0)| 00:00:01 |       |       |  Q1,02 | PCWP |            |
    |  90 |         BUFFER SORT                                |                     |       |       |            |          |       |       |  Q1,03 | PCWC |            |
    |  91 |          PX RECEIVE                                |                     |     3 |    42 |     3   (0)| 00:00:01 |       |       |  Q1,03 | PCWP |            |
    |  92 |           PX SEND HASH                             | :TQ10001            |     3 |    42 |     3   (0)| 00:00:01 |       |       |        | S->P | HASH       |
    |* 93 |            TABLE ACCESS FULL                       | L_TEST_STATUS       |     3 |    42 |     3   (0)| 00:00:01 |       |       |        |      |            |
    |* 94 |        INDEX UNIQUE SCAN                           | L_ATMS_TEST_TYPE_PK |     1 |       |     0   (0)| 00:00:01 |       |       |  Q1,03 | PCWP |            |
    |* 95 |       TABLE ACCESS BY INDEX ROWID                  | L_ATMS_TEST_TYPE    |     1 |     5 |     1   (0)| 00:00:01 |       |       |  Q1,03 | PCWP |            |
    Predicate Information (identified by operation id):
       5 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
       8 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
      11 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
      18 - access("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
      19 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
      20 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
                  "B_FP_TEST"."TEST_NUM"<>99)
      22 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
      26 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
      30 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
      34 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
      38 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
                  LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
      39 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
      40 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
                  "B_FP_TEST"."TEST_NUM"<>99)
      41 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
      42 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
      43 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
      44 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
      45 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
      50 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
      53 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
      60 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
                  LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
      61 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
      62 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
                  "B_FP_TEST"."TEST_NUM"<>99)
      64 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
      68 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
      69 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
      70 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
      75 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
      78 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
      85 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-10-28
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
                  LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND
                  (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
      86 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
      87 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
                  "B_FP_TEST"."TEST_NUM"<>99)
      89 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
      93 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
      94 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
      95 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)

    Excellent piece of follow-up on my first suggestion.
    I nearly made a comment about how the plan doesn't show Bloom filter pruning either - and then I realised why not. The plan you've shown us comes from Explain Plan with literal values present; the trace file shows bind variables with names that are generated when cursor_sharing is set to force or similar - so the run-time plan and the plan from explain plan are almost guaranteed to be different.
    Oracle support will need you to supply the plan you get from trying to run the query and then making a call to dbms_xplan.display_cursor() - dbms_xplan in 10g | Oracle Scratchpad If you do this I think you'll find that the pstart/pstop columns contain entries like :BF0000, and you may even find operations link PX JOIN FILTER CREATE / PX JOIN FILTER USE
    A couple of generic notes:
    if a query does sufficient work to merit parallel execution, then it's usually better to supply the best possible information to the optimizer, which means using literals rather than bind variables - you could try executing the query with the hint /*+ cursor_sharing_exact */ to stop Oracle from turning your literals into binds; it might be the presence of bind variables that's making the optimizer choose a path that has to include bloom filter pruning in your case.
    Where you have the to_date() call you've used a four-digit year - which is a very good thing and helps the optimizer - but it's also a good idea to include an explicit format string as well: with a four-digit year this probably won't make any difference, but it avoids any risk of ambiguity for the optimizer.
    I made a comment about the P->S stage and bottlenecks - I spent a couple more minutes looking at the plan, and I see the optimizer has used concatentation: in effect it has run three query blocks one after the other and fed the results to the query co-ordinator - in this case the P->S would make no difference to the end-user response time there's always a final P->S to the coordinator, you just happen to have three of them.
    Regards
    Jonathan Lewis

  • ORA-00060: deadlock detected while waiting for resource with Tbs Read-only

    Hi all,
    We're using Oracle 10.2.0.1 and 9.2.0.4.
    I'm testing the performing of a procedure that inserts, like this:
    CREATE OR REPLACE PROCEDURE P$TAD_TEST
    IS
    TYPE T_T1_C1          IS TABLE OF T1.C1%TYPE INDEX BY PLS_INTEGER;
    TYPE T_T1_DT           IS TABLE OF T1.DT%TYPE INDEX BY PLS_INTEGER;
    P_C1 T_T1_C1;
    P_DT T_T1_DT;
    P_RESULT NUMBER;
    BEGIN
    FOR j IN 1..4032 LOOP
    P_C1(j) := j;
    P_DT(j) := SYSDATE + (j/24/60);
    END LOOP;
    FORALL i IN P_C1.FIRST..P_C1.LAST SAVE EXCEPTIONS
    INSERT INTO T1 VALUES (P_C1(i), P_DT(i));
    EXCEPTION
    WHEN OTHERS THEN
    P_RESULT := SQLCODE;
    END;
    The table T1 is partitioned across 10 tablespaces. The test consist to take
    these tablespace read-only and perform the procedure, and analyze the results,
    like erros.
    but when I perform the procedure, The alert.log indicates the error
    ORA-00060: deadlock detected while waiting for resource.
    Why this occurs only the tablespaces are read-only?
    thank you!!!!

    Hi,
    yesterday we got this error again(in fact twice) and we were able to get the trace file. It says this is NOT oracle error. i was wrong in suspecting Oracle. This is the trace file details. i dont know how to debug this. Any help appreciated.
    *** 2010-06-15 16:24:29.243
    *** ACTION NAME:() 2010-06-15 16:24:29.231
    *** MODULE NAME:(JDBC Thin Client) 2010-06-15 16:24:29.231
    *** SERVICE NAME: 2010-06-15 16:24:29.231
    *** SESSION ID:(482.4266) 2010-06-15 16:24:29.231
    DEADLOCK DETECTED ( ORA-00060 )
    [Transaction Deadlock]
    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-00300021-0000b52d 209 482 X 247 474 S
    TX-002a0009-00011b24 247 474 X 209 482 S
    session 482: DID 0001-00D1-0000000A session 474: DID 0001-00F7-00000008
    session 474: DID 0001-00F7-00000008 session 482: DID 0001-00D1-0000000A
    Rows waited on:
    Session 474: obj - rowid = 0000CED4 - AAAM7UAAxAAAVgSAAA
    (dictionary objn - 52948, file - 49, block - 88082, slot - 0)
    Session 482: obj - rowid = 0000D8BF - AAANi/AAuAAB+z/AAA
    (dictionary objn - 55487, file - 46, block - 519423, slot - 0)
    Information on the OTHER waiting sessions:
    Session 474:
    pid=247 serial=31796 audsid=25502259 user: 62/USER
    O/S info: ....
    program: JDBC Thin Client
    application name: JDBC Thin Client, hash value=2546894660
    Current SQL Statement:
    INSERT QUERY1
    End of information on OTHER waiting sessions.
    Current SQL statement for this session:
    INSERT QUERY2
    Thanks,
    AK

  • Trigger error -deadlock detected while waiting for resource

    with table1 as (
    select '1' no,'1' id, 'N' flag,'' result from dual union all
    select '2' no,'1' id, 'N' flag,'B' result from dual union all
    select '3' no,'1' id, '' flag,'B' result from dual union all
    select '4' no,'2' id, 'N' flag,'B' result from dual union all
    select '5' no,'2' id, 'N' flag,'B' result from dual
    select * from table1
    I need to write a trigger with the condition that if Flag is set to 'Y', then all the values for the field 'result' for that particular ID should set a 'A'.
    For the above table if I run the below query
    update table1
    set flag= 'Y' where no =1
    The trigger result should be
    with table1 as (
    select '1' no,'1' id, 'Y' flag,'A' result from dual union all
    select '2' no,'1' id, 'N' flag,'A' result from dual union all
    select '3' no,'1' id, '' flag,'A' result from dual union all
    select '4' no,'2' id, 'N' flag,'B' result from dual union all
    select '5' no,'2' id, 'N' flag,'B' result from dual
    select * from table1
    I wrote the trigger as below...
    CREATE OR REPLACE TRIGGER test
    BEFORE UPDATE
    ON table1 for each row
    DECLARE
    PRAGMA AUTONOMOUS_TRANSACTION;
    BEGIN
    if :new.flag = 'Y' then
    update table1
    set result = 'A'
    where id = :new.id ;
    commit;
    end if;
    end;
    but giving follwing error.
    ORA-00060: deadlock detected while waiting for resource
    ORA-06512: at "test"
    ORA-04088: error during execution of trigger 'test'
    Please help to correct my trigger.

    # Firstly you cannot define trigger using on subquery clause - WITH. e.g. table1.
    # You might have used a trick to use PRAGMA AUTONOMOUS TRANSACTION to isolate trigger transaction from the main transaction but the deadlock will certainly going to occur as the main transaction already hold the row level lock which you are trying to update in trigger code.
    # We will try to use common technique to capture all the ID whose flag is set as 'Y' in row level trigger and then in statement level trigger after update will update the column - "resut" for the ID.
    This is very simple test code for demonostration.
    CREATE TABLE T
      NO      NUMBER,
      ID      NUMBER,
      FLAG    VARCHAR2(1),
      RESULT  VARCHAR2(1)
    INSERT INTO  T VALUES (1,1,'N',NULL);
    INSERT INTO  T VALUES (2,1,'N','B');
    INSERT INTO  T VALUES (3,1,'','B');
    INSERT INTO  T VALUES (4,2,'N','B');
    INSERT INTO  T VALUES (5,2,'N','B');
    CREATE OR REPLACE PACKAGE PKG_T_MUTATING AS
    TYPE IDTABTYPE IS TABLE OF T.ID%TYPE;
    T_ID IDTABTYPE := IDTABTYPE();
    PROCEDURE GET_UPDATE_ID(P_ID T.ID%TYPE);
    PROCEDURE UPD_T;
    END PKG_T_MUTATING;
    CREATE OR REPLACE PACKAGE BODY PKG_T_MUTATING AS
    PROCEDURE GET_UPDATE_ID(P_ID T.ID%TYPE) IS
    BEGIN
      T_ID.EXTEND;
      T_ID(T_ID.COUNT) := P_ID;
      DBMS_OUTPUT.PUT_LINE('T_ID ' || T_ID(T_ID.COUNT));
    END GET_UPDATE_ID;
    PROCEDURE UPD_T IS
    V_ID PKG_T_MUTATING.IDTABTYPE := PKG_T_MUTATING.IDTABTYPE();
    BEGIN
    V_ID := V_ID MULTISET UNION DISTINCT T_ID;
    IF V_ID.COUNT > 0  THEN
      FORALL i IN 1..V_ID.COUNT
       UPDATE T SET RESULT = 'A'
       WHERE ID = V_ID(i);
    END IF;
    -- Cleanup
    V_ID.DELETE;
    T_ID.DELETE;
    EXCEPTION
      WHEN OTHERS THEN
        DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
    END UPD_T;
    END PKG_T_MUTATING;
    CREATE OR REPLACE TRIGGER TRG_TEST_BU
    BEFORE UPDATE OF FLAG ON T FOR EACH ROW
    WHEN (NEW.FLAG = 'Y')
    BEGIN
    pkg_t_mutating.get_update_id(:NEW.ID);
    END;
    CREATE OR REPLACE TRIGGER TRG_TEST_AU
    AFTER UPDATE OF FLAG ON T
    BEGIN
    PKG_T_MUTATING.UPD_T;
    END;
    SQL>SELECT * FROM T;
            NO         ID FLAG       RESULT
             1          1 Y          A
             2          1 N          B
             3          1            B
             4          2 N          B
             5          2 N          B
    SQL>UPDATE T SET FLAG = 'Y' WHERE NO = 1 AND ID = 1;
    1 row updated.
    SQL>SELECT * FROM T;
            NO         ID FLAG       RESULT
             1          1 Y          A
             2          1 N          A
             3          1            A
             4          2 N          B
             5          2 N          B
    SQL>
    {code}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Deadlock ( holds: S, waits: SSX )

    Hello,
    I have a deadlock problem on a database.
    Here is a summary of dump trace:
    Dump file /home/migtt2/appli/expl/udump/migtt2_ora_1024024.trc
    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
    With the Partitioning, OLAP and Data Mining options
    System name:     AIX
    Release:     3
    Version:     5
    Instance name: MIGTT2
    Deadlock graph:
    ---------Blocker(s)-------- ---------Waiter(s)---------
    Resource Name process session holds waits process session holds waits
    TM-0003ad7d-00000000 24 568 S SSX 26 577 S SSX
    TM-0003ad7d-00000000 26 577 S SSX 24 568 S SSX
    3ad7d identifies a table T1.
    update T1 set .. where MSGOID=:13 and MSGINSTVERSION=:14
    update T1 set .. where MSGOID=:13 and MSGINSTVERSION=:14
    After reading on Metalink and studying concepts of lock in Oracle documentation, I have no explanation about this deadlock.
    Could you help me.
    Thanks.
    Stéphane.

    Great example, mister Hooper. Thanks.
    In fact, on this database, I also have this kind of
    deadlock ( holds: SX, waits: SSX ). And it's always
    on the same table T1. The deadlock looks like your
    example. But I have a foreign key.
    I've already verified the possible problem due to
    unindexed foreign keys.
    Moreover, the same code ( Java, Hibernate ) performs
    very well on the other
    "same" databases, particularly in production for 6
    months.
    Unfortunately, I can't see the code and correct it.
    Before saying to development team to attempt to
    correct it, I want to be sure
    it's really a lock management problem and not an
    database problem.
    It's why I ask you to confirm me it's a code problem
    and not a database bug.You mentioned that there are foreign keys. It may not be easy to determine if there are foreign keys that have not been indexed. You might try the following query, which I adapted from a query that I believe Tim Kyte listed in one of his books:
    SELECT
      DECODE(B.TABLE_NAME, NULL, '*Check*', 'OK' ) STATUS,
      A.OWNER,
      A.TABLE_NAME,
      A.COLUMNS,
      B.COLUMNS INDEX_COLUMNS
    FROM
      (SELECT
        A.OWNER,
        SUBSTR(A.TABLE_NAME,1,30) TABLE_NAME,
        SUBSTR(A.CONSTRAINT_NAME,1,30) CONSTRAINT_NAME,
        MAX(DECODE(POSITION, 1,     SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 2,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 3,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 4,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 5,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 6,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 7,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 8,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION, 9,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION,10,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION,11,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION,12,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION,13,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION,14,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION,15,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) ||
        MAX(DECODE(POSITION,16,', '||SUBSTR(COLUMN_NAME,1,30),NULL)) COLUMNS
      FROM
        DBA_CONS_COLUMNS A,
        DBA_CONSTRAINTS B
      WHERE
        A.CONSTRAINT_NAME = B.CONSTRAINT_NAME
        AND A.OWNER=B.OWNER
        AND B.CONSTRAINT_TYPE = 'R'
      GROUP BY
        A.OWNER,
        SUBSTR(A.TABLE_NAME,1,30),
        SUBSTR(A.CONSTRAINT_NAME,1,30) ) A,
        (SELECT
          TABLE_OWNER,
          SUBSTR(TABLE_NAME,1,30) TABLE_NAME,
          SUBSTR(INDEX_NAME,1,30) INDEX_NAME,
          MAX(DECODE(COLUMN_POSITION, 1,
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 2,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 3,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 4,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 5,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 6,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 7,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 8,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION, 9,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION,10,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION,11,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION,12,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION,13,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION,14,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION,15,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) ||
          MAX(DECODE(COLUMN_POSITION,16,', '||
          SUBSTR(COLUMN_NAME,1,30),NULL)) COLUMNS
        FROM
          DBA_IND_COLUMNS
        GROUP BY
          TABLE_OWNER,
          SUBSTR(TABLE_NAME,1,30),
          SUBSTR(INDEX_NAME,1,30)) B
        WHERE
          A.TABLE_NAME = B.TABLE_NAME (+)
          AND A.OWNER=B.TABLE_OWNER(+)
          AND B.COLUMNS (+) LIKE A.COLUMNS || '%'
    ORDER BY
      A.OWNER,
      A.TABLE_NAME;In the output from the above, if STATUS is Check, you might want to investigate that foreign key. You might also want to restrict the query to objects in a specific schema.
    Note: your original deadlock showed that the lock type was TM. If the deadlock points to a type TX, then the problem is probably not related to foreign keys indexing problems.
    Another test setup to produce a deadlock with lock type TX:
    /* The setup (assumes that the tables from the previous test setup still exist) */
    DROP TABLE T2;
    DROP TABLE T1;
    DROP TABLE T3;
    CREATE TABLE T1(C1 NUMBER(10) PRIMARY KEY, C2 NUMBER(10));
    INSERT INTO T1 VALUES(1,NULL);
    INSERT INTO T1 VALUES(2,NULL);
    INSERT INTO T1 VALUES(3,NULL);
    INSERT INTO T1 VALUES(4,NULL);
    COMMIT;
    CREATE TABLE T2(C1 NUMBER(10) PRIMARY KEY, C2 NUMBER(10));
    INSERT INTO T2 VALUES(1,NULL);
    INSERT INTO T2 VALUES(2,NULL);
    INSERT INTO T2 VALUES(3,NULL);
    INSERT INTO T2 VALUES(4,NULL);
    COMMIT;
    CREATE TABLE T3(TRANSACTION_ID NUMBER(10) PRIMARY KEY);
    INSERT INTO T3 VALUES(1);
    INSERT INTO T3 VALUES(2);
    INSERT INTO T3 VALUES(3);
    INSERT INTO T3 VALUES(4);
    COMMIT;
    /* Now we have two data tables and a third table, which could be interesting if there were 3 sessions involved */
    /* Test 3 - session 1 updates a row, waits, session 2 updates 2 rows and hangs */
    /* SESSION 1 */
    UPDATE
      T1
    SET
      C2=C1
    WHERE
      C1=1;
    /* SESSION 2 */
    UPDATE
      T2
    SET
      C2=C1
    WHERE
      C1=1;
    UPDATE
      T1
    SET
      C2=C1
    WHERE
      C1=1;
    /* HANGS */
    /* SESSION 1 */
    UPDATE
      T2
    SET
      C2=C1
    WHERE
      C1=1;
    /* HANGS */
    /* SESSION 2 */
      T1
    ERROR at line 2:
    ORA-00060: deadlock detected while waiting for resource
    Deadlock graph:
                           ---------Blocker(s)--------  ---------Waiter(s)---------
    Resource Name          process session holds waits  process session holds waits
    TX-00010003-0000238f        18     208     X             17     210           X
    TX-00090005-00002383        17     210     X             18     208           X
    session 208: DID 0001-0012-000000D9     session 210: DID 0001-0011-000000D0
    session 210: DID 0001-0011-000000D0     session 208: DID 0001-0012-000000D9
    Rows waited on:
    Session 210: obj - rowid = 0000D644 - AAANZEAAEAAFvr2AAA
      (dictionary objn - 54852, file - 4, block - 1506038, slot - 0)
    Session 208: obj - rowid = 0000D642 - AAANZCAAEAAFvrmAAA
      (dictionary objn - 54850, file - 4, block - 1506022, slot - 0)
    /* SESSION 2 */
    ROLLBACK;
    /* SESSION 1 */
    ROLLBACK;
    /* Test 4 - Transaction table that does not use a sequence contributes to the problem */
    /* SESSION 1 */
    UPDATE
      T1
    SET
      C2=C1
    WHERE
      C1=1;
    INSERT INTO
      T3
    SELECT
      MAX(TRANSACTION_ID)+1
    FROM
      T3;
    /* SESSION 2 */
    UPDATE
      T2
    SET
      C2=C1+1
    WHERE
      C1=1;
    INSERT INTO
      T3
    SELECT
      MAX(TRANSACTION_ID)+1
    FROM
      T3;
    /* HANGS */
    /* SESSION 1 */
    DELETE FROM T2;
    /* HANGS */
    /* SESSION 2 */
      T3
    ERROR at line 2:
    ORA-00060: deadlock detected while waiting for resource
    Deadlock graph:
                           ---------Blocker(s)--------  ---------Waiter(s)---------
    Resource Name          process session holds waits  process session holds waits
    TX-00060029-00002376        18     208     X             17     210           X
    TX-00090016-00002386        17     210     X             18     208           S
    session 208: DID 0001-0012-000000D9     session 210: DID 0001-0011-000000D0
    session 210: DID 0001-0011-000000D0     session 208: DID 0001-0012-000000D9
    Rows waited on:
    Session 210: obj - rowid = 0000D644 - AAANZEAAEAAFvr2AAA
      (dictionary objn - 54852, file - 4, block - 1506038, slot - 0)
    Session 208: obj - rowid = 0000D642 - AAANZCAAEAAFvrmAAA
      (dictionary objn - 54850, file - 4, block - 1506022, slot - 0)Test 5 (if setup) might have used 3 sessions, the first session would update a row in T1 and then insert a row into T3. The second session would update a row in T2 and attempt to insert a row into T3 (session 2 would hang). Session 3 would update a different row in T2, and then attempt to insert a row into T3 (session 3 would hang). Session 1 would see that the row originally updated by session 2 was not updated, and attempt to update that row (session 1 would hang). The Deadlock graph?
    Deadlocks almost always point to application design problems (or user design problems when the user attempts to start the same batch process twice).
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • ORA-00060: deadlock detected while waiting for resource CLOSE cursor

    Hi,
    I am a new member of this forum. I am working with a problem we got a few weeks ago. It is from a Pro C batch executable running on 10 threads dealing with >800 data accessed from multiple tables. The error as reported came from a package.function call.
    This is the error I encountered:
    process_item~G****, D***~-60~ORA-00060: deadlock detected while waiting for resource~PACKAGE ERROR = CLOSE cursor C_***** in package R***.I*** 7641
    The cursor is a simple SELECT cursor without Table or Record locking.
    My questions are:
    *Upon the occurrence of this error, is the execution already at the CLOSE cursor line or did the error occurred between the OPEN cursor and the CLOSE cursor? There are several lines of code in between OPEN and CLOSE:
    - one that calls for a package.function that simply stores parameter values to a variable
    - another one which fetches the cursor. The group that holds the cursor values is only used by a single function in the package
    *Is it possible for this CLOSE cursor to cause a deadlock? What could have caused this?
    *From what I know, Oracle deals with deadlocks by aborting the deadlocking process while others continue, but this deadlock caused our program to hang. How is this possible? Could the root cause of the deadlock be from our threading program? This is a rare occurrence and happened only twice this year.
    Thanks,
    Raf

    Raf Serrano wrote:
    Hi,
    I am a new member of this forum. I am working with a problem we got a few weeks ago. It is from a Pro C batch executable running on 10 threads dealing with >800 data accessed from multiple tables. The error as reported came from a package.function call.
    This is the error I encountered:
    process_item~G****, D***~-60~ORA-00060: deadlock detected while waiting for resource~PACKAGE ERROR = CLOSE cursor C_***** in package R***.I*** 7641
    The cursor is a simple SELECT cursor without Table or Record locking.
    My questions are:
    *Upon the occurrence of this error, is the execution already at the CLOSE cursor line or did the error occurred between the OPEN cursor and the CLOSE cursor? There are several lines of code in between OPEN and CLOSE:
    - one that calls for a package.function that simply stores parameter values to a variable
    - another one which fetches the cursor. The group that holds the cursor values is only used by a single function in the package
    *Is it possible for this CLOSE cursor to cause a deadlock? What could have caused this?
    *From what I know, Oracle deals with deadlocks by aborting the deadlocking process while others continue, but this deadlock caused our program to hang. How is this possible? Could the root cause of the deadlock be from our threading program? This is a rare occurrence and happened only twice this year.
    Thanks,
    RafSELECT (without FOR UPDATE) statements are never involved in ORA-00060.
    only DML statements throw ORA-00060 error

  • Sqlldr- ORA-00060: deadlock detected while waiting for resource

    Hi Team,
    My database version is 11.1.0.7.0. I am loading the data using sqlldr. I am getting the error ORA-00060: deadlock detected while waiting for resource. once dead lock detected ,whether data will be rejected after commit point reached(Rows=100000). FYI information only sqllder is running on the database,it is getting completed withing 5-10min. please help me whether any other lock happening on this due to sqllder.
    sqlldr userid=orcl/orcle control=".$controlfile." log=".$logfile.".log data=".$datafile." bad=".$badfile." discard=".$discardfile." Bindsize=19000000 Rows=100000 Readsize=20000000 Errors=1000000";
    Thanks in advance

    user9256814 wrote:
    Hi Team,
    My database version is 11.1.0.7.0. I am loading the data using sqlldr. I am getting the error ORA-00060: deadlock detected while waiting for resource. once dead lock detected ,whether data will be rejected after commit point reached(Rows=100000). FYI information only sqllder is running on the database,it is getting completed withing 5-10min. please help me whether any other lock happening on this due to sqllder.
    sqlldr userid=orcl/orcle control=".$controlfile." log=".$logfile.".log data=".$datafile." bad=".$badfile." discard=".$discardfile." Bindsize=19000000 Rows=100000 Readsize=20000000 Errors=1000000";
    Thanks in advanceadditional clues will exist within alert_SID.ora file & subsequent trace file.

  • Resource_semaphore wait type not matching sys.dm_exec_query_memory_grants

    We are using Red Gate's SQL Monitor to alert (every 5 minutes) when memory grants pending are greater than zero. Several times a day we are alerted on our Devel and Prod servers.
    However, when querying the resource_semaphore wait type using sys.dm_os_wait_stats, it used to register non-zero amounts several months ago, but now is always equal to zero.
    The Devel server is version 11.0.3128 standard on Windows 2008 R2 Standard 64-bit, and the Prod server is version 10.0.5500 on Windows 2008 Standard 64-bit.
    We are storing wait stats for each server in a database, collected every half hour. The Prod resource semaphore was 569 early August 11, then after a reboot at 3:30 AM was equal to zero and is the same today. I have confirmed the current value using the following
    query.
    SELECT * FROM sys.dm_os_wait_stats
    WHERE wait_type = 'RESOURCE_SEMAPHORE';
    Similarly, the Devel resource semaphore was 167 early October 23, then after a reboot at 7:03 AM was equal to zero and has not changed from zero since then. Again, I confirmed the current value using the above query.
    The custom alert code for Red Gate SQL Monitor is:
    SELECT COUNT(*) FROM sys.dm_exec_query_memory_grants;
    Also, running a perfmon counter against SQL Server: Memory Manager: Memory Grants Pending for
    several days yields a flat line equal to zero, with maximum value zero.
    Looks to me like something in SQL Server's internal stats collection system has broken. Or possibly, I am misunderstanding that these three counters measure the same thing.
    Thanks for your help.

    We are using Red Gate's SQL Monitor to alert (every 5 minutes) when memory grants pending are greater than zero. Several times a day we are alerted on our Devel and
    Prod servers. However, when querying the resource_semaphore wait type using sys.dm_os_wait_stats, it used to register non-zero amounts several months ago, but now is always equal to zero.
    The Devel server is version 11.0.3128 standard on Windows 2008 R2 Standard 64-bit, and the Prod server is version 10.0.5500 on Windows 2008 Standard 64-bit.
    We are storing wait stats for each server in a database, collected every half hour. The Prod resource semaphore was 569 early August 11, then after a reboot at 3:30 AM was equal to zero and is the same today. I have confirmed the current value using
    the following query.
    SELECT * FROM sys.dm_os_wait_stats
    WHERE wait_type = 'RESOURCE_SEMAPHORE';
    Similarly, the Devel resource semaphore was 167 early October 23, then after a reboot at 7:03 AM was equal to zero and has not changed from zero since then. Again, I confirmed the current value using the above query.
    The custom alert code for Red Gate SQL Monitor is:
    SELECT COUNT(*) FROM sys.dm_exec_query_memory_grants;
    Also, running a perfmon counter against SQL Server: Memory Manager: Memory Grants Pending for
    several days yields a flat line equal to zero, with maximum value zero.
    Looks to me like something in SQL Server's internal stats collection system has broken. Or possibly, I am misunderstanding that these three counters measure the same thing.
    Thanks for your help.
    Hello,
    SQL server internal stats collection is fine it is not broken what you are doing is after restart SQL server cache is cleared and this is area from where you get all your DMV result so before restart you are seeing some value for resource semaphore wait
    and after restart it is gone.
    For query memory grants pending value as non zero it clearly points to fact that there is memory crunch and you need to increase more RAM.
    resource semaphore waits point to fact that your query which is running is costly one and is involving lots of sort and hash you need to tune it.Read below article for resource semaphore wait
    http://blogs.msdn.com/b/sqlqueryprocessing/archive/2010/02/16/understanding-sql-server-memory-grant.aspx
    If you want to find out cumulative waits stats i suggest you to use below query by Jonathan Kehayias.
    Can you post output for this query
    SELECT TOP 10
    wait_type ,
    max_wait_time_ms wait_time_ms ,
    signal_wait_time_ms ,
    wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
    100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( )
    AS percent_total_waits ,
    100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( )
    AS percent_total_signal_waits ,
    100.0 * ( wait_time_ms - signal_wait_time_ms )
    / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
    FROM sys.dm_os_wait_stats
    WHERE wait_time_ms > 0 -- remove zero wait_time
    AND wait_type NOT IN -- filter out additional irrelevant waits
    ( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
    'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
    'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH',
    'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
    'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
    'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
    'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
    'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
    'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
    'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
    'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN',
    'RESOURCE_QUEUE' )
    ORDER BY wait_time_ms DESC
    Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

  • How to overcome thisORA-00060: deadlock detected while waiting for resource

    Hi ,
    I have table name problems(prom_number,prom_relation,prom_impact,prom_prom_number)
    Now from oracle form raltion can be set.
    parent and chil relation can be set from the form
    for ex
    first suppose row=1 prom_number=1 is set as parent.
    so the tabl is updated as prom_+relation='PARENT'
    so after first updation values are
    prom_number=1,prom_impact='xxx',prom_relation='PARENT' prom_prom_number=null
    now in form level the 2 row which is set as child is update as follow
    prom_number=2,prom_impact='yyy',prom_relation='CHILD' prom_prom_number=1
    Now my requirment is after the 2nd row is updated the prom_impact of 2 row should be pusehd to row=1 which has the pirom_relation as ='PARENT.
    the problem is i dont have the fmb of form so i cant do any changes in the form.
    So i have written a trigger which fires when row2 is updated it picks the prom_impact value and trys to push it in row=1 with prom_number=1
    however since in form level the table has not been committed it displays the following error
    ORA-00060: deadlock detected while waiting for resource
    So how can we overcome this error.
    the trigger i have written is given below.
    So how can we resolve thsis issue.
    CREATE OR REPLACE TRIGGER Parent_Child_Impact_Trg
    AFTER UPDATE OF prom_relation,prom_prom_number
    ON PROBLEMS
    REFERENCING NEW AS NEW OLD AS OLD
    FOR EACH ROW
    Version History:9.2.8.1
    (format: version, date, developer, description)
    1.0, 19-Dec-2008, Tanmoy Kr Moulik The "Impact" of Paren fault ticket
    will be changed upon manual creation of Parent Child relation
    Rules:
    1.0     Upon manual creation of new Parent-Child fault relation, the 'Fault Impact' of
    Child fault will be auto updated in the parent fault, if the parent fault impact matches
    with the attached list(Non Serve Affeect or Threat) or the impact of Parent Fault is blank (null).
    2.0     In case, the parent fault have fault impact matches with the attached list
    (service affect), then its impact is not changed while making the relationship.
    DECLARE
    PRAGMA autonomous_transaction;
    ecode NUMBER;
    emesg VARCHAR2(200);
    --BEGIN
    -- NULL;
    CURSOR c1--(v_prom_num NUMBER)
    IS
    SELECT PROM_IMPACT,prom_number FROM PROBLEMS WHERE prom_number=:NEW.prom_prom_number;
    v_prom_imp VARCHAR2(30) DEFAULT NULL;
    v_prom_imp_p1 NUMBER DEFAULT 0;
    v_prom_imp_p2 NUMBER DEFAULT 0;
    v_prom_num NUMBER;
    BEGIN
    IF :NEW.PROM_RELATION='CHILD' AND :NEW.PROM_PROM_NUMBER IS NOT NULL THEN
    --dbms_output.put_line(1);
    --INSERT INTO TEMP_PROM VALUES(:NEW.prom_number,:NEW.prom_prom_number,:NEW.prom_impact,:NEW.prom_relation);
    --COMMIT;
    OPEN c1;--(:NEW.prom_prom_number);
    FETCH c1 INTO v_prom_imp,v_prom_num;
    --INSERT INTO TEMP_PROM(PROM_NUM,PROM_IMPACT) VALUES(v_prom_num,v_prom_imp);
    --COMMIT;
    IF c1%NOTFOUND THEN
    v_prom_imp:=NULL;
    v_prom_num:=NULL;
    END IF;
    CLOSE c1;
    v_prom_imp:=UPPER(v_prom_imp);
    v_prom_imp_p1:=INSTR(v_prom_imp,'NON');
    v_prom_imp_p2:=INSTR(v_prom_imp,'THREAT');
    --INSERT INTO TEMP_PROM(PROM_NUM) VALUES(v_prom_imp_p1);
    --INSERT INTO TEMP_PROM(PROM_NUM) VALUES(v_prom_imp_p2);
    --COMMIT;
    IF v_prom_imp_p1>0 OR v_prom_imp_p2>0 THEN
    IF :NEW.prom_impact IS NOT NULL THEN
    /*BEGIN
    INSERT INTO TEMP_PROM(PROM_NUM,PROM_PROM_NUMBER,prom_impact,PROM_RELATION) VALUES(:NEW.prom_number,:NEW.prom_prom_number,:NEW.prom_impact,:NEW.prom_relation);
    COMMIT;
    EXCEPTION WHEN OTHERS THEN
    INSERT INTO TEMP_PROM(prom_impact,PROM_RELATION) VALUES('failed1'||ecode,emesg);
    COMMIT;
    END;
    BEGIN
    COMMIT;
    --INSERT INTO PROBLEMS(prom_number,PROM_REPORTED,PROM_REPORTEDBY,PROM_PRIORITY,PROM_DESCRIPTION,PROM_EMPE_ID,PROM_WORG_NAME,PROM_CREATED,PROM_CWORG_NAME)
    -- VALUES(50000000,SYSDATE,'TAN',1,'DASD','CLARITY','CLARITY',SYSDATE,'CLARITY');
    UPDATE PROBLEMS SET PROM_IMPACT=:NEW.PROM_IMPACT WHERE prom_number=:NEW.prom_prom_number;
    COMMIT;
    EXCEPTION WHEN OTHERS THEN
         ecode := SQLCODE;
    emesg := SQLERRM;
    COMMIT;
    BEGIN
         UPDATE PROBLEMS SET PROM_IMPACT=:NEW.PROM_IMPACT WHERE prom_number=:NEW.prom_prom_number;
         EXCEPTION WHEN OTHERS THEN
         INSERT INTO TEMP_PROM(prom_impact,PROM_RELATION) VALUES('failed'||ecode,emesg);
         END;
    --INSERT INTO TEMP_PROM(prom_impact,PROM_RELATION) VALUES('failed'||ecode,emesg);
    COMMIT;
    -- EXCEPTION WHEN OTHERS THEN*/
         NULL;
         END;
         --END;
    --END;     
    END IF;     
         /*BEGIN
         INSERT INTO TEMP_PROM(PROM_NUM,PROM_IMPACT) VALUES(:NEW.prom_prom_number,:NEW.prom_impact);
         COMMIT;
    EXCEPTION WHEN OTHERS THEN
         INSERT INTO TEMP_PROM(prom_impact) VALUES('failed1');
         NULL;
         END;
    --NULL;
    -- END;
    --COMMIT;
    --END;
    /* BEGIN
    INSERT INTO TEMP_PROM(PROM_NUM,PROM_IMPACT) VALUES(:NEW.prom_prom_number,:NEW.prom_impact);
    EXCEPTION WHEN OTHERS THEN
    --INSERT INTO TEMP_PROM(prom_impact) VALUES('failed');
    NULL;
    END;
    COMMIT;
    --COMMIT;
    /* ELSIF v_prom_imp_p2>0 THEN
    -- v_prom_imp_p2
    IF :NEW.prom_impact IS NOT NULL THEN
    BEGIN
    UPDATE PROBLEMS SET PROM_IMPACT=:NEW.PROM_IMPACT WHERE prom_number=:NEW.prom_prom_number;
    EXCEPTION WHEN OTHERS THEN
    BEGIN
         ecode := SQLCODE;
    emesg := SQLERRM;
    --BEGIN
    INSERT INTO TEMP_PROM(prom_impact,PROM_RELATION) VALUES('failed'||ecode,emesg);
    COMMIT;
    --EXCEPTION WHEN OTHERS THEN
         NULL;
         END;
    NULL;
    END;
    COMMIT;
    BEGIN
    INSERT INTO TEMP_PROM(PROM_NUM,PROM_IMPACT) VALUES(:NEW.prom_prom_number,:NEW.prom_impact);
    EXCEPTION WHEN OTHERS THEN
    NULL;
    END;
    COMMIT;*/
    --UPDATE PROBLEMS SET PROM_IMPACT=:NEW.PROM_IMPACT WHERE prom_number=:NEW.prom_prom_number;
    -- COMMIT;
    -- END IF;
    END IF;
    END IF;
    EXCEPTION WHEN OTHERS THEN
    INSERT INTO TEMP_PROM(prom_impact,PROM_RELATION) VALUES('failed2'||ecode,emesg);
    COMMIT;
    NULL;
    END;
    /

    Please do not take this the wrong way, my intention is not to be insulting, but from reading what you've posted I have no idea what you are doing or in what version of what product(s).
    What I can tell you, though, is that your explicit cursor declarations with explicit OPEN and FETCH have no business in your code. Neither do incremental commits belong in any code. Nor does the following:
    EXCEPTION WHEN OTHERS THEN
    INSERT INTO TEMP_PROM(prom_impact,PROM_RELATION) VALUES('failed2'||ecode,emesg);
    COMMIT;
    NULL;belong in any code. What is NULL doing there? And why are there any commits in your trigger? Your use of PRAGMA AUTONOMOUS TRANSACTION to allow these commits is similarly unexplainable. It is no wonder you are getting deadlocks.
    You need to push away from the keyboard and take SQL and PL/SQL courses and learn the basics. While looking for a good course in your area get a copy of any of Tom Kyte's books and start reading it and practicing with the examples.

  • Wait type CXPACKET - BPC 5.1 on MSS 2005 SP3

    We are experiencing large variations in run times of logic packages in a BPC 5.1 system.  A package may run in 15 minutes at one time and then the next run may take 5 hours.  When the run time is significantly longer we see a process in the MSS Activity Monitor that is running in parallel (multiple rows with the same SPID) and all but one are suspended.  Each of the suspended threads shows CXPACKET in the "Wait type" column.  The command column has the value INSERT.
    The other observation is that the system appears to spawn more threads for the same SPID after a period of time.  For example, I have often found there are 20 threads and the wait time will be the same for groups of four threads -- each group of four has a different wait time than the others in the list.
    My research indicates that this means the process is running in parallel and the threads are waiting for the completion (or start) of parallel statements.  The only suggestion I have found so far is to change "Max Degree of Parallelism" from 0 (zero) to 1 on the server to prevent parallel query execution, or to set a hint to set MAXDOP to 1. 
    Is the logic package creating inefficient query plans that cause MSS to generate inefficient query plans that go into parallel?  Is there any way to prevent this from happening?
    Thanks,
    David

    CXPACKET wait is due to parallelism, and as you have researched you can avoid it by setting MAXDOP to 1.
    Yes, improper query plans may be cause for long time executions, you may want to check the statistics are updated,any missing indexes,lots of fragmentation.
    you may want to look into this nice article, about how to tune your query  against CXPACKET waits.
    [http://www.mssqltips.com/tip.asp?tip=2027]
    Thanks
    Mush

  • Wait Type PAGEIOLATCH_SH and PAGEIOLATCH_EX

    Hello, 
    I am looking at the performance issue on one of the SQL Server which is for Zenworks. 
    There are 4 application server which reads and writes to the Zen SQL Server. 
    It's been there for a while now and quite a lot of times I see the status as suspended and the Wait Type is PAGEIOLATCH_SH and PAGEIOLATCH_EX which disappears and comes back again and again. 
    Could somebody please advise how to troubleshoot this?
    Best regards, 
    Mohan

    Hello,
    Could you please share the result of the following query with us?
    SELECT
    TOP 50 *
    FROM
    [sys].[dm_os_wait_stats]
    ORDER
    BY [wait_time_ms]
    DESC
    Thank you in advance.
    Regards,
    Alberto Morillo
    SQLCoffee.com
    Thanks Alberto, 
    The result is below. 
    wait_type waiting_tasks_count
    wait_time_ms max_wait_time_ms
    signal_wait_time_ms
    REQUEST_FOR_DEADLOCK_SEARCH 32350
    161783933 5462
    161783933
    XE_TIMER_EVENT 5394
    161766099 30301
    161765240
    LAZYWRITER_SLEEP 168848
    161737044 3023
    71938
    SQLTRACE_INCREMENTAL_FLUSH_SLEEP 40395
    161627956 4590
    89
    LOGMGR_QUEUE 1982118
    161505817 645651
    258372
    XE_DISPATCHER_WAIT 17
    156846134 50730025
    0
    CHECKPOINT_QUEUE 18208
    150758459 2037452
    3257
    PAGEIOLATCH_SH 12811676
    138069019 3369
    244808
    BROKER_EVENTHANDLER 14
    112016323 84467042
    11
    SLEEP_TASK 10361836
    81580069 2809
    676539
    BROKER_TO_FLUSH 78813
    80887188 1980
    26694
    PAGEIOLATCH_EX 2774508
    28392234 3545
    73181
    SOS_SCHEDULER_YIELD 2446505
    8560372 1536
    8532156
    WRITELOG 1895345
    5805484 20821
    66796
    SLEEP_BPOOL_FLUSH 1452978
    4558026 753
    204212
    LCK_M_IX 67
    3806433 311970
    519
    BROKER_TASK_STOP 746
    3747976 10008
    100
    CXPACKET 331690
    1348196 17612
    179146
    BACKUPBUFFER 230089
    1273926 2048
    12506
    ASYNC_IO_COMPLETION 5
    1243210 628743
    0
    BROKER_RECEIVE_WAITFOR 4
    1199953 598704
    0
    BACKUPIO 105914
    1174546 2127
    594
    LCK_M_U 184
    1069219 238125
    151
    PAGEIOLATCH_UP 16079
    665743 1457
    3672
    LCK_M_X 47
    585665 72697
    20
    PREEMPTIVE_OS_AUTHENTICATIONOPS 61568
    345872 3007
    0
    ASYNC_NETWORK_IO 94086
    106911 1694
    26395
    MSQL_XP 9808
    101965 2272
    0
    PREEMPTIVE_OS_GETPROCADDRESS 9808
    101553 2272
    0
    PAGELATCH_EX 249003
    82555 2041
    58631
    LCK_M_S 4
    75172 70016
    1
    LOGBUFFER 1615
    73754 1134
    564
    PREEMPTIVE_OS_WAITFORSINGLEOBJECT 26593
    56219 545
    0
    PREEMPTIVE_OS_WRITEFILEGATHER 30
    40052 5399
    0
    PREEMPTIVE_OS_LOOKUPACCOUNTSID 17496
    25534 280
    0
    OLEDB 18501515
    23474 249
    0
    PREEMPTIVE_OS_DELETESECURITYCONTEXT 17661
    22908 507
    0
    PAGELATCH_SH 53643
    19873 344
    12476
    THREADPOOL 2904
    19451 288
    0
    LATCH_EX 10260
    17581 521
    1750
    IO_COMPLETION 1865
    16677 407
    168
    PAGELATCH_UP 855
    14606 1335
    384
    PREEMPTIVE_OS_AUTHORIZATIONOPS 18055
    13845 216
    0
    PREEMPTIVE_OS_REVERTTOSELF 14248
    9884 170
    0
    SQLTRACE_FILE_BUFFER 139
    7130 380
    83
    SLEEP_DBSTARTUP 61
    7007 334
    371
    SQLTRACE_FILE_WRITE_IO_COMPLETION 729
    6963 324
    6
    PREEMPTIVE_OS_QUERYREGISTRY 2691
    5844 503
    0
    PREEMPTIVE_OS_CRYPTACQUIRECONTEXT 3696
    5093 200
    0
    PREEMPTIVE_OS_NETVALIDATEPASSWORDPOLICY 3559
    3948 87
    0
    Sorry, not in a great friendly format. 
    Many thanks, 
    Mohan

  • ORA-00060 "deadlock detected while waiting for resource"

    Hello.
    I am having an oracle deadlock when calling a stored procedure (wich updates several records in several tables) from several threads: ORA-00060 error. The error does not happen very often but from time to time, normally the calls to this proceudre end ok.
    Each call starts and ends a transaction. (When the oracle error raises the transaction where it raises is rolled back) and the other transactions can go on.
    I don't how to avoid it. Should it be solved at the stored procedure level or could it be solved at java level by doing the call to the stored procedure to be synchronized?
    Thanks in advance.

    Fernando_Sanchez wrote:
    Hello.
    I am having an oracle deadlock when calling a stored procedure (wich updates several records in several tables) from several threads: ORA-00060 error. The error does not happen very often but from time to time, normally the calls to this proceudre end ok.Which doesn't really sound good.
    If you have a java thread then to do JDBC, regardless of what type, you get a new connection and new statements in each one.
    If you are not doing that then that is a problem.
    If you are doing that then the thread information is irrelevant at the java level.
    You can of course do all sorts of interesting things with locks and transactions in Oracle and via stored procs but other ways as well. And if you are not careful it will cause problems.

  • ORA-00060: deadlock detected while waiting for resource ON INSERT

    I am running into a deadlock while INSERTING records into a table. This seems strange to me. I've tracked it down to the following, and it feels like an Oracle bug to me, so I wanted to get another opinion:
    I have a procedure that inserts records into a table.
    That table has a Before INSERT OR UPDATE OR DELETE FOR EACH ROW trigger on it.
    The trigger has an IF UPDATING section in it; this section updates records in other tables related to this table.
    I have confirmed that the IF UPDATING section is not firing (which makes sense because I am inserting, but since I was getting a deadlock, it seemed to make sense that somehow the updating section was firing).
    Here's the part that makes this feel buggy:
    I have been able to reproduce the deadlock pretty much on command.
    I commented out the IF UPDATING section of the trigger, compiled the trigger, and then put the IF UPDATING section of the trigger back in, and compiled it. Note there was no net code change.
    I ran my procedure that inserts records and experienced NO DEADLOCK.
    However, if I compile the original version of the trigger (before I commented code out and put it back in), the deadlock reappears. To make the deadlock go away, I have to re-comment out the code, compile, put the code back, and compile again.
    I know this sounds crazy. I'm running Oracle Database 11g Release 11.2.0.2.0.
    Has anyone ever seen something like this before?

    MPL wrote:
    Thanks - there are no autonomous transactions being run. Here's the deadlock graph:
    ---------Blocker(s)--------  ---------Waiter(s)---------
    Resource Name          process session holds waits  process session holds waits
    TX-00220006-0000a762        71     207     X             70      46           S
    TX-00200020-000072ee        70      46     X             71     207           S
    session 207: DID 0001-0047-00000016     session 46: DID 0001-0046-00000021
    session 46: DID 0001-0046-00000021      session 207: DID 0001-0047-00000016
    Rows waited on:
    Session 207: obj - rowid = 00000000 - D/////AACAAAMS9AAA
    (dictionary objn - 0, file - 2, block - 50365, slot - 0)
    Session 46: obj - rowid = 0000ADF7 - AAAsJmAASAAAXYGAAA
    (dictionary objn - 44535, file - 18, block - 95750, slot - 0)
    There are various anomalies that can cause the TX locks waiting in S mode - many of them to do with indexes or unique constraints. Your rowid information may be misleading - but it's worth checking which object has object_id 44535. (I'm always inclined to assume that any reference to slot 0 is suspect, and objn 0 is clearly not a real object.)
    The trace file should be reporting the SQL that the two sessions are waiting on - does that give you any clues.
    Regards
    Jonathan Lewis

  • DBIF_RSQL_SQL_ERROR - ORA-00060: deadlock detected while waiting

    We have recently upgrade to BI 7.0.  In the upgrade environment, we are having oracle deadlock issues.  We are running on SAPKW70015.   Notes related to this are for SAPKW70014. 
    Any ideas on why this occurring in BI 7.0?  We never encountered this with BI 3.5.
    I will reward points.

    Hi Stephen
    see the note
    Note 631668 - DEADLOCK when loading data into InfoCubes
    Thi is a "Consulting note", not correction is necessary.
    do you have found a different solution?

Maybe you are looking for

  • No cellular on iPad 2 after iOS 8.1 update

    Lost cellular capability after updating iPad 2 to iOS 8.0, then 8.0.2. Have now Reset, Restored and Updated iPad to iOS 8.1 but still no cellular, only wi-fi. This problem has only occurred since since iOS 8.x. Is there a fix for this?

  • Reading masterdata of attribute in BI 7.0

    Hello Gurus I have the following situation: I am creating a transformation from an ODS to the Cube. I have an InfoObject in the cube which should be populated based on the value of another InfoObject in the ODS (which is a navigation attribute of ano

  • Strange Issue: App UI Window not coming up (OS X w/ AIR 2)

    A coworker of mine recently upgraded his OS X to 10.6, then to 10.6.4, and now an app we use internally won't start on his machine. I have the exact same setup as he does (OS X 10.6.4, AIR 2, Flash Player 10.1, same app version) and mine starts just

  • How to use error table in mapping level?

    Hi all Any one please tell me how to use error table in mapping level or how to handle the errors in mapping. I am creating one error table in oracle but i dont know how to use it in mapping. Thanks in advance. Kumar

  • ADF business component wizard with tables referencing junction table

    I have a three tables, user, devices and a link/junction table to map the user's assigned devices. <<user>> user_id user_name <<device>> device_id device_name <<userdevice>> user_id device_id I wanted to create a view page where I can search a user t