ORA-00060 during remove workspace

Question

I'm using Oracle Release 9.2.0.4 with Workspace Manager.
In my application all changes are made inside long transaction, all involved tables are versioned.
Several users work concurrently, the users can not modify the same rows (update/delete), insert are possible
(the application generates automatically the unique primary keys using sequences)
Any user session operates in this way:
- Create workspace: execute dbms_wm.createworkspace('ws1');
- go to workspace : execute dbms_wm.gotoworkspace('ws1');
- make changes: update/delete/insert on different tables
- exit from workspace: execute dbms_wm.gotoworkspace('LIVE');
- merge/rollback workspace: execute dbms_wm.mergeworkspace('ws1')/dbms_wm.rollbackworkspace('ws1');
- remove workspace: execute dbms_wm.removeworkspace('ws1');
Sometimes the following error occurs during dbms_wm.removeworkspace:
ORA-00060 deadlock detected while waiting for resource
While this error can occur? Can I prevent this error?
In the follow I include the content of oracle trace files:
oraadmn6@cdsv00jd:SIGASP> more /app/oraadmn6/admin/SIGASP/udump/sigasp_ora_21687.trc
/app/oraadmn6/admin/SIGASP/udump/sigasp_ora_21687.trc
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
ORACLE_HOME = /app/oraadmn6/product/9.2.0
System name: SunOS
Node name: cdsv00jd
Release: 5.8
Version: Generic_108528-19
Machine: sun4u
Instance name: SIGASP
Redo thread mounted by this instance: 1
Oracle process number: 58
Unix process pid: 21687, image: oracle@cdsv00jd (TNS V1-V3)
*** 2005-10-26 15:25:55.494
*** SESSION ID:(60.2524) 2005-10-26 15:25:55.488
DEADLOCK DETECTED
Current SQL statement for this session:
DELETE FROM WMSYS.WM$WORKSPACE_SAVEPOINTS_TABLE WHERE WORKSPACE = :b1
----- PL/SQL Call Stack -----
object line object
handle number name
3927ac3e0 1145 package body SYS.LTADM
38dd4bf40 3421 package body SYS.LT
38dd4bf40 3286 package body SYS.LT
38dd4bf40 4507 package body SYS.LT
3920d4c00 1 anonymous block
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-0003002d-000083db 58 60 X 32 46 X
TX-00020004-00008db9 32 46 X 58 60 X
session 60: DID 0001-003A-0000094E session 46: DID 0001-0020-00001A99
session 46: DID 0001-0020-00001A99 session 60: DID 0001-003A-0000094E
Rows waited on:
Session 46: obj - rowid = 00001771 - AAABdxAABAAAFILAAE
(dictionary objn - 6001, file - 1, block - 21003, slot - 4)
Session 60: obj - rowid = 00001786 - AAABeGAABAAAFKSAAI
(dictionary objn - 6022, file - 1, block - 21138, slot - 8)
Information on the OTHER waiting sessions:
Session 46:
pid=32 serial=112 audsid=1728581 user: 0/SYS
O/S info: user: ri01516, term: SNWS00695019, ospid: 1716:1712, machine: SNAMRETEGAS\SNWS00695019
program: Ustation.exe
application name: Ustation.exe, hash value=0
Current SQL Statement:
UPDATE WMSYS.WM$WORKSPACES_TABLE SET PARENT_VERSION=:b1 WHERE PARENT_VERSION = :b2
End of information on OTHER waiting sessions.
===================================================
oraadmn6@cdsv00jd:SIGASP> more /app/oraadmn6/admin/SIGASP/udump/sigasp_ora_21757.trc
/app/oraadmn6/admin/SIGASP/udump/sigasp_ora_21757.trc
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
ORACLE_HOME = /app/oraadmn6/product/9.2.0
System name: SunOS
Node name: cdsv00jd
Release: 5.8
Version: Generic_108528-19
Machine: sun4u
Instance name: SIGASP
Redo thread mounted by this instance: 1
Oracle process number: 13
Unix process pid: 21757, image: oracle@cdsv00jd (TNS V1-V3)
*** 2005-10-06 16:51:56.140
*** SESSION ID:(19.2048) 2005-10-06 16:51:56.134
DEADLOCK DETECTED
Current SQL statement for this session:
insert into TRATTI (FAC_TYPE, COD_GASD, TIPO_COND, STATO_FUN, CENTRO, LUN, DN, PRES_MAX, PRES_CPI, COD_SPE, LIVELLO_CIRC, ORD
INE_LIVELLO, VISIBILITA_STR, AUTOMATIZZAZIONE, mslink) values (1100, 45860, 2, 1, 'PI', 300, 450, 24, 70, 'PI047', 4, 1, 0, '
S', 2100000120)
----- PL/SQL Call Stack -----
object line object
handle number name
392cf1e80 82 package body SYS.DBMS_LOCK
392cf1e80 110 package body SYS.DBMS_LOCK
392d561f0 2055 package body SYS.LTADM
38dcbf928 352 package body SYS.LT_CTX_PKG
38d4dfb28 42 GISDBA.OVM_INSERT_3842
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
TM-0000ab01-00000000 13 19 X 44 32 SX
UL-00000000-00000000 44 32 X 13 19 S
session 19: DID 0001-000D-000006DB session 32: DID 0001-002C-0000224D
session 32: DID 0001-002C-0000224D session 19: DID 0001-000D-000006DB
Rows waited on:
Session 32: obj - rowid = 0000AA54 - AAAAAAAAJAAAPi7AAA
(dictionary objn - 43604, file - 9, block - 63675, slot - 0)
Session 19: no row
Information on the OTHER waiting sessions:
Session 32:
pid=44 serial=1406 audsid=1556312 user: 118/GISDBA
O/S info: user: ri50000, term: SNWS01146378, ospid: 1876:1872, machine: SNAMRETEGAS\SNWS01146378
program: Ustation.exe
application name: Ustation.exe, hash value=0
Current SQL Statement:
UPDATE GISDBA.TRATTI_LT
SET ltlock =
sys.lt_ctx_pkg.checkngetlock(:b4, ltlock, nextver,
:b2, 0,'UPDATE'),
nextver = sys.lt_ctx_pkg.getNextVer(nextver,:b3,:b2)
WHERE ROWID = :b1
Thanks, Alessandra

Answer 1

Hi,
Do any of the versioned tables that you are using have RICs defined on them ? If so, you may find useful information regarding deadlocks in the following thread.
RIC in OWM - ORA-20171 deadlock detected ...
A deadlock will occur when 2 different sessions are waiting on a resource that has already been acquired by the other session.
The easiest example of this are multiple updates to the same table:
-- Session 1
SQL> update scott.test_tab set value=10 where id=1 ;
SQL> -- wait for session 2 to execute its first statement
SQL> update scott.test_tab set value=10 where id=2 ;
-- Session 2
SQL> update scott.test_tab set value=10 where id=2 ;
SQL> -- wait for session 1 to execute its first statement
SQL> update scott.test_tab set value=10 where id=1 ;
At this point 1 of the 2 sessions will fail due to a deadlock. Please note that a deadlock will not occur when 2 sessions simply update the same row. It needs to have already acquired a lock on a row that the other session will be updating.
The same principles can be applied to workspace manager. During each of the workspace operations(merge, remove, rollback, etc) we will acquire a lock on the current workspace and also the parent workspace in the case of remove and merge and a few other operations. If you set the auto_commit to false than those locks are retained until the session either commits or rolls back.
So, if two session successfully perform a workspace operation without committing, and then each of them tries to do another workspace operation which requires the lock held by the other session, then a deadlock will occur. This could also happen from a combination of dmls and workspace operations if you do not commit between them.
It is hard to say from the description that you gave exactly what is happening in your case. It will depend on when the commits are occurring and if you set auto_commit to false during any workspace operations. If you have a simple testcase that is able to show the deadlock occurring, then I would be glad to look at it and make any further recommendations. I would also suggest to upgrade to the latest version of workspace manager(9.2.0.5.1) if you have not already done so. You can find your current version by querying the wm_installation view. The latest version of workspace manager is always available on Metalink.
Regards,
Ben