![]() To resolve the issue, make sure that rows in tables are always locked in the same order. The SQL statements listed in the trace file should allow you to identify the application code that is causing the problem. The third section lists the blocked SQL statements in the other waiting sessions. The second section is a message from Oracle telling you this is an application issue, not an Oracle error. The first section shows the blocked SQL statement in the session that detected the deadlock. The sections in bold are of the most interest. ![]() SELECT ID FROM DEADLOCK_1 WHERE ID = 1 FOR UPDATEĮnd of information on OTHER waiting sessions. O/S info: user: tim_hall, term: winxp1, ospid: 5928:3844, machine: winxp1Īpplication name: SQL*Plus, hash value=3669949024 Information on the OTHER waiting sessions: (dictionary objn - 59080, file - 4, block - 72, slot - 0) Session 137: obj - rowid = 0000E6C8 - AAAObIAAEAAAABIAAA (dictionary objn - 59079, file - 4, block - 64, slot - 0) Session 159: obj - rowid = 0000E6C7 - AAAObHAAEAAAABAAAA Resource Name process session holds waits process session holds waits Information may aid in determining the deadlock: It is aĭeadlock due to user error in the design of an application The following deadlock is not an ORACLE error. SELECT ID FROM DEADLOCK_2 WHERE ID = 1 FOR UPDATE The error message contains a reference to a trace file, whose contents indicate the SQL statements blocked in both the session that detected the deadlock and the other blocked sessions. More info in file c:\oracle\product\10.2.0\admin\db10g\udump\db10g_ora_c. In addition to the deadlock error reported to the session, a message is placed in the alert log. ORA-00060: deadlock detected while waiting for resource A typical deadlock error is displayed below. ![]() ![]() ![]() The call to the DBMS_LOCK.SLEEP procedure is only present to give you enough time to switch sessions.Įventually, one of the sessions will detect the deadlock, rollback its transaction and produce a deadlock error, while the other transaction completes successfully. The second piece of code does the same thing but in reverse, locking a row in the DEADLOCK_2 table, then the DEADLOCK_1 table. The first piece of code gets a lock on a row in the DEADLOCK_1 table, it pauses for 30 seconds, then attempts to get a lock on a row in the DEADLOCK_2 table. Start two SQL*Plus sessions, each logged into the test user, then run the following pieces of code, one in each session. This article shows the steps necessary to identify the offending application code when a deadlock is detected. Typically, deadlocks are caused by poorly implemented locking in application code. Oracle automatically detects and resolves deadlocks by rolling back the statement associated with the transaction that detects the deadlock. A deadlock occurs when two or more sessions are waiting for data locked by each other, resulting in all the sessions being blocked. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |