Remove the execution of more than 48 hours

Hello

I have the deletion request that runs more than 48 hours. How to find what really makes the query?

Sql plan, I can see that the query is FULL TABLE SCAN.

Query: REMOVE TRND_UPC_FV2_XAOC WHERE MRKT_KEY IN (11,12);

SPL plan:

PLAN_TABLE_OUTPUT

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hash value of plan: 2256923628

-----------------------------------------------------------------------------------------------------------

| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

-----------------------------------------------------------------------------------------------------------

| 0 | DELETE STATEMENT.   288 M |  6322M |   182K (2) | 00:36:26 |       |

| 1. REMOVE | TRND_UPC_FV2_XAOC |            | |       |       |

| 2.   COORDINATOR PX |       | | | |       |       |

| 3.    PX SEND QC (RANDOM). : TQ10000 | 288 M |  6322M |   182K (2) | 00:36:26 |       |       |

| 4.     ITERATOR BLOCK PX |   288 M |  6322M |   182K (2) | 00:36:26 |     1.   267.

|* 5 |      TABLE ACCESS FULL | TRND_UPC_FV2_XAOC |   288 M |  6322M |   182K (2) | 00:36:26 |     1.   267.

PLAN_TABLE_OUTPUT

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):

---------------------------------------------------

5 - filter ("MRKT_KEY" = 11 GOLD "MRKT_KEY" = 12)

Event:

EVENT MACHINE P1, P2 P3 P3TEXT P2TEXT P1TEXT

------------------------------ -------------------- ---------- -------------------- ---------- ---------- ---------- ---------

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 5 passes 5.0440E + 17 qref

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 13 passes 5.0440E + 17 qref

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 2 spend 5.0440E + 17 qref

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 6 pass 5.0440E + 17 qref

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 6 pass 5.0440E + 17 qref

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 8 pass 5.0440E + 17 qref

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 10 passes 5.0440E + 17 qref

PX Deq Credit: send blkd lnx30.nielsen.com # sleeptime/senderid 11 pass 5.0440E + 17 qref

DB file sequential read lnx30.nielsen.com # file # 1693322 block # 1 blocks

9 selected lines.

Dependence:

NAME OF THE REFERENCED REFERENCED_NAME DEPE OWNER

---------- ------------------------------ ---------- ------------------------------ ----

BIR V_TRND_UPC_FCT_MRKT BIR TRND_UPC_FV2_XAOC HARD

Question: Why the query take so long? How to find the root cause.

Hello


> Why the query take so long? How to find the cause root

Well it seems that you have enabled a parallel query on table TRND_UPC_FV2_XAOC, but forgot to enable parallel DML as well. So the FTS is happening in parallel, but DELETE itself is treated in a unique way (check the position of the COORDINATOR PX implementation plan). If the parallel/DML query is not useful (or wanted to) here, because of the column volume 11 and 12 represent the data of the minority of the values MRKT_KEY and you have a valid and appropriate index for it - check the parallelism setting. However, we are already looking at the crystal ball.

For parallel DML stuff - check out the blog of Jonathan Lewis here: parallel DML. Notebook of the Oracle

Concerning

Stefan

Tags: Database

Similar Questions

Maybe you are looking for