I have a series of scripts running in parallel as a nohup on an AIX server hosting oracle 10g. These scripts are written by somebody else and are meant to be executed concurrently. All the scripts are performing updates on a table. I am getting the error,
ORA-00060: deadlock detected while waiting for resource
As I googled for this, I found, http://www.dba-oracle.com/t_deadly_perpetual_embrace_locks.htm
Even though the scripts are performing updation on the same table concurrently, they are performing updates on different records of the table determined by the WHERE
clause with no overlaps of records between them.
So would this have caused the error?.
Will this error happen regardless of where the updates are performed on a table?.
Should I avoid concurrent updates on a table at all times?.
Strangely I also found on the nohup.out log, PL/SQL successfully completed
after the above quoted error.
Does this mean that oracle has recovered from the deadlock and completed the updates successfully or Should I rerun those scripts serially? Any help would be welcome.
Thanks in advance.
Too high activity - Re-running the job during a less busy period can fix this ORA-00060 deadlock error. Poor application design - As noted in the trace file: "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."
A deadlock occurs when two or more sessions are waiting for data locked by each other, resulting in all the sessions being blocked. Oracle automatically detects and resolves deadlocks by rolling back the statement associated with the transaction that detects the deadlock.
In a database, a deadlock is a situation in which two or more transactions are waiting for one another to give up locks. For example, Transaction A might hold a lock on some rows in the Accounts table and needs to update some rows in the Orders table to finish.
I was recently struggling with a similar problem. It turned out that the database was missing indexes on foreign keys. That caused Oracle to lock many more records than required which quickly led to a deadlock during high concurrency.
Here is an excellent article with lots of good detail, suggestions, and details about how to fix a deadlock: http://www.oratechinfo.co.uk/deadlocks.html#unindex_fk
You can get deadlocks on more than just row locks, e.g. see this. The scripts may be competing for other resources, such as index blocks.
I've gotten around this in the past by engineering the parallelism in such a way that different instances are working on portions of the workload that are less likely to affect blocks that are close to each other; for example, for an update of a large table, instead of setting up the parallel slaves using something like MOD(n,10)
, I'd use TRUNC(n/10)
which mean that each slave worked on a contiguous set of data.
There are, of course, much better ways of splitting up a job for parallelism, e.g. DBMS_PARALLEL_EXECUTE.
Not sure why you're getting "PL/SQL successfully completed", perhaps your scripts are handling the exception?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With