Deadlock Errors

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 15.5

Description:
I have been noticing an unusual amount of DEADLOCK errors in the ORACLE logs on our production server in the aleph2/bdump/alert logs recently a snippet from the alert log below:
Sun Dec 3 07:22:42 2006
ARC0: Beginning to archive log# 5 seq# 11996
ARC0: Completed archiving log# 5 seq# 11996
Sun Dec 3 07:27:07 2006
ORA-000060: Deadlock detected. More info in file /exlibris/app/oracle/admin/aleph2/udump/aleph2_ora_5898.trc.
Sun Dec 3 07:27:10 2006
ORA-000060: Deadlock detected. More info in file /exlibris/app/oracle/admin/aleph2/udump/aleph2_ora_5895.trc.
Sun Dec 3 07:27:11 2006
ORA-000060: Deadlock detected. More info in file /exlibris/app/oracle/admin/aleph2/udump/aleph2_ora_5902.trc.
Sun Dec 3 07:27:13 2006
ORA-000060: Deadlock detected. More info in file /exlibris/app/oracle/admin/aleph2/udump/aleph2_ora_5895.trc.
Sun Dec 3 07:27:20 2006
ORA-000060: Deadlock detected. More info in file /exlibris/app/oracle/admin/aleph2/udump/aleph2_ora_5902.trc.
Sun Dec 3 07:27:21 2006
ORA-000060: Deadlock detected. More info in file /exlibris/app/oracle/admin/aleph2/udump/aleph2_ora_5898.trc.
Sun Dec 3 07:27:28 2006
ORA-000060: Deadlock detected. More info in file /exlibris/app/oracle/admin/aleph2/udump/aleph2_ora_5928.trc.
Sun Dec 3 07:27:28 2006

A snippet from one of the trc files in udump:

*** SESSION ID:(497.333) 2006-12-03 08:00:18.118
DEADLOCK DETECTED
Current SQL statement for this session:
update sys01.z120 set z120_rec_key = :r1:i1,z120_rec_key_1 = :r2:i2,z120_update_flag = :r3:i3,z120_same_no_lines
= :r4:i4,z120_same = :r5:i5 where z120_rec_key = :v1
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:
"aleph2_ora_7607.trc" [Read only] 2985 lines, 164203 characters

Resolution:
Is a batch job which creates/updates item records (such as p_manage_50, p_file_96, or p_file_90) running in the bib library, while ue_01 is running in the xxx50 library?

We have seen cases where that sometimes resulted in deadlock. The solution is to stop ue_01 in the xxx50 when such jobs are running.

Article last edited: 10/8/2013