OCP 1Z0 052 172

172. The session of user SCOTT receives the following error after executing an UPDATE command on

the EMP table:

ERROR at line 1:

ORA-00060: deadlock detected while waiting for resource

On investigation, you find that a session opened by user JIM has a transaction that caused the deadlock.

Which two statements are true regarding the session of SCOTT in this scenario? (Choose two.)

A.The session is terminated after receiving the error and JIM can continue with his transaction.

B.SCOTT should perform a COMMIT or ROLLBACK to allow JIM to continue with his transaction.

C.The session is rolled back after receiving the error and JIM can continue with his transaction.

D.SCOTT has to reexecute the last command in the transaction after he commits the transaction.

Answer: BD

当两个会话分别请求对方锁定的资源时，就会产生deadlock

常见情景就是，两个会话分别update对方已锁定的行。

死锁产生时oracle会自动中断前一个会话的请求，并在alert.log中增加deadlock记录

http://docs.oracle.com/cd/E11882_01/server.112/e40540/consist.htm#CNCPT1336

Locks and Deadlocks

A deadlock is
a situation in which two or more users are waiting for data locked by each other. Deadlocks prevent some transactions from continuing to work.

Oracle Database automatically detects deadlocks and resolves them by rolling back one statement involved in the deadlock, releasing one set of the conflicting row locks. The database returns a corresponding message to the transaction that undergoes statement-level
rollback. The statement rolled back belongs to the transaction that detects the deadlock. Usually, the signalled transaction should be rolled back explicitly, but it can retry the rolled-back statement after waiting.

Table 9-5 illustrates two transactions in a deadlock.

Table 9-5 Deadlock Example

Time	Session 1	Session 2	Explanation
t0	SQL> UPDATE employees SET salary = salary*1.1 WHERE employee_id = 100; 1 row updated.	SQL> UPDATE employees SET salary = salary*1.1 WHERE employee_id = 200; 1 row updated.	Session 1 starts transaction 1 and updates the salary for employee 100. Session 2 starts transaction 2 and updates the salary for employee 200. No problem exists because each transaction locks only the row that it attempts to update.
t1	SQL> UPDATE employees SET salary = salary*1.1 WHERE employee_id = 200; -- prompt does not return	SQL> UPDATE employees salary = salary*1.1 WHERE employee_id = 100; -- prompt does not return	Transaction 1 attempts to update the employee 200 row, which is currently locked by transaction 2. Transaction 2 attempts to update the employee 100 row, which is currently locked by transaction 1. A deadlock results because neither transaction can obtain the resource it needs to proceed or terminate. No matter how long each transaction waits, the conflicting locks are held.
t2	UPDATE employees * ERROR at line 1: ORA-00060: deadlock detected while waiting for resource SQL>		Transaction 1 signals the deadlock and rolls back the UPDATE statement issued at t1. However, the update made at t0 is not rolled back. The prompt is returned in session 1. Note: Only one session in the deadlock actually gets the deadlock error, but either session could get the error.
t3	SQL> COMMIT; Commit complete.		Session 1 commits the update made at t0, ending transaction 1. The update unsuccessfully attempted at t1 is not committed.
t4		1 row updated. SQL>	The update at t1 in transaction 2, which was being blocked by transaction 1, is executed. The prompt is returned.
t5		SQL> COMMIT; Commit complete.	Session 2 commits the updates made at t0 and t1, which ends transaction 2.

Deadlocks most often occur when transactions explicitly override the default locking of Oracle Database. Because Oracle Database does not escalate locks and does not use read locks for queries, but does use row-level (rather than page-level) locking, deadlocks
occur infrequently.