Thank you in advance for any help you can lend.
==============================
During the OTM Upgrade to 6.3.3, the dbpatch_63.sql starts:
Creating new tables...
Compiling 631 packages....
No errors.
No errors.
Applying preupdates...
Applying preupdates...
Compiling 632 packages....
Applying preupdates...
Applying preupdates...
Compiling 633 packages....
Applying preupdates....
Applying preupdates...
create sequence
Then the following DELETE executes and consumes (99%) one-full-CPU
from our Large-Linux-Server. The DELETE Executes for Hours.
DELETE FROM GTM_TR_PROD_CLASSIFICATION GTA
WHERE ROWID < ANY (
SELECT ROWID FROM GTM_TR_PROD_CLASSIFICATION GTB
WHERE GTA.GTM_TRANSACTION_LINE_GID =
GTB.GTM_TRANSACTION_LINE_GID
AND GTA.GTM_PRODUCT_CLASS_TYPE_GID =
GTB.GTM_PRODUCT_CLASS_TYPE_GID
AND GTA.GTM_PROD_CLASS_CODE_GID =
GTB.GTM_PROD_CLASS_CODE_GID)
Row-Counts:
GTM_TR_PROD_CLASSIFICATION 427361 Rows
Additionally, we bounced the OTM Database before we launched the
dbpatch_63. So there in only the one (1) SQL-Session executing.
There are NO BLOCKING Locks, but this SQL DELETE has LOCKED eight (8)
Objects. These Objects are NOT Blocking Locks. Please see below.
The Oracle SQL-Explain-Plan: Show NO-COSTLY-Activity.
(Simple-Delete-Statement and Execution-Plan)
Plan hash value: 526368618
----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows |Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------------------------
| 0 | DELETE STATEMENT | | | | 1 (100)|
| 1 | DELETE | GTM_TR_PROD_CLASSIFICATION | | | |
| 2 | NESTED LOOPS SEMI | | 1 | 193 | 0 (0)|
| 3 | TABLE ACCESS BY INDEX ROWID| GTM_TR_PROD_CLASSIFICATION | 1 | 104 | 0 (0)|
|* 4 | INDEX FULL SCAN | IX_GTPC_GTM_PROD_CLASS_TYPE_G | 1 | | 0 (0)|
|* 5 | TABLE ACCESS BY INDEX ROWID| GTM_TR_PROD_CLASSIFICATION | 1 | 89 | 0 (0)|
|* 6 | INDEX RANGE SCAN | IX_GTPC_GTM_PROD_CLASS_TYPE_G | 1 | | 0 (0)|
--------------------------------------------------------------------------------------------------
There are NO (zero) Blocking Locks in the Database.
There is only ONE (1) SQL-Session executing.
The Following eight (8) objects are LOCKED by the DELETE operation.
Object Session Session Session Lock Rqst Lock
UserName Name Sid Serial AudSid Program Mode Mode Type
--------- -------------------------- ------- ------- ------- ----------- ---- ---- ----
GLOGOWNER ITEM 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_TR_PROD_CLASSIFICATION 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_TRANSACTION_LINE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_ITEM_CLASSIFICATION 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_PROD_CLASS_CODE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_ITEM_CLASS_TEMPLATE_D 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_ITEM_CLASS_TEMPLATE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_PROD_CLASS_TYPE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
There are NO entries in the Database Alert-Log since the Database Startup.
(We bounced the Database BEFORE we launched the dbpatch_63 Upgrade Script.)
==============================
During the OTM Upgrade to 6.3.3, the dbpatch_63.sql starts:
Creating new tables...
Compiling 631 packages....
No errors.
No errors.
Applying preupdates...
Applying preupdates...
Compiling 632 packages....
Applying preupdates...
Applying preupdates...
Compiling 633 packages....
Applying preupdates....
Applying preupdates...
create sequence
Then the following DELETE executes and consumes (99%) one-full-CPU
from our Large-Linux-Server. The DELETE Executes for Hours.
DELETE FROM GTM_TR_PROD_CLASSIFICATION GTA
WHERE ROWID < ANY (
SELECT ROWID FROM GTM_TR_PROD_CLASSIFICATION GTB
WHERE GTA.GTM_TRANSACTION_LINE_GID =
GTB.GTM_TRANSACTION_LINE_GID
AND GTA.GTM_PRODUCT_CLASS_TYPE_GID =
GTB.GTM_PRODUCT_CLASS_TYPE_GID
AND GTA.GTM_PROD_CLASS_CODE_GID =
GTB.GTM_PROD_CLASS_CODE_GID)
Row-Counts:
GTM_TR_PROD_CLASSIFICATION 427361 Rows
Additionally, we bounced the OTM Database before we launched the
dbpatch_63. So there in only the one (1) SQL-Session executing.
There are NO BLOCKING Locks, but this SQL DELETE has LOCKED eight (8)
Objects. These Objects are NOT Blocking Locks. Please see below.
The Oracle SQL-Explain-Plan: Show NO-COSTLY-Activity.
(Simple-Delete-Statement and Execution-Plan)
Plan hash value: 526368618
----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows |Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------------------------
| 0 | DELETE STATEMENT | | | | 1 (100)|
| 1 | DELETE | GTM_TR_PROD_CLASSIFICATION | | | |
| 2 | NESTED LOOPS SEMI | | 1 | 193 | 0 (0)|
| 3 | TABLE ACCESS BY INDEX ROWID| GTM_TR_PROD_CLASSIFICATION | 1 | 104 | 0 (0)|
|* 4 | INDEX FULL SCAN | IX_GTPC_GTM_PROD_CLASS_TYPE_G | 1 | | 0 (0)|
|* 5 | TABLE ACCESS BY INDEX ROWID| GTM_TR_PROD_CLASSIFICATION | 1 | 89 | 0 (0)|
|* 6 | INDEX RANGE SCAN | IX_GTPC_GTM_PROD_CLASS_TYPE_G | 1 | | 0 (0)|
--------------------------------------------------------------------------------------------------
There are NO (zero) Blocking Locks in the Database.
There is only ONE (1) SQL-Session executing.
The Following eight (8) objects are LOCKED by the DELETE operation.
Object Session Session Session Lock Rqst Lock
UserName Name Sid Serial AudSid Program Mode Mode Type
--------- -------------------------- ------- ------- ------- ----------- ---- ---- ----
GLOGOWNER ITEM 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_TR_PROD_CLASSIFICATION 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_TRANSACTION_LINE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_ITEM_CLASSIFICATION 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_PROD_CLASS_CODE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_ITEM_CLASS_TEMPLATE_D 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_ITEM_CLASS_TEMPLATE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
GLOGOWNER GTM_PROD_CLASS_TYPE 12 7 100053 sqlplus@gbl 6(X) 0( ) TX
There are NO entries in the Database Alert-Log since the Database Startup.
(We bounced the Database BEFORE we launched the dbpatch_63 Upgrade Script.)