[bbk3206] 第69集 Chapter 17Monitoring and Detecting Lock Contention(02)

Table Lock Modes

These table lock modes are automatically assigned by the Oracle server:

Row Exclusive(RX):INSERT,UPDATE,DELETE

Row Share(RS):SELECT ... FOR UPDATE

Manually Locking a Table

Manually acquired in LOCK TABLE Statement

SQL>LOCK TABLE HR.employees IN share MODE;

• Share(S)
  • No DML operations allowed
  • Implicity used for referential integrity
• Share Row exclusive (SRX)
  • No DML operations or Share mode allowed
  • Implicitly used for referential integrity
  • No index is required on the foreign key column in the child table
• Exclusive(X)
  • No DML or DDL operations allowed by other sessions
  • No manual locks allowed by other sessions
  • Queries are allowed

DML Locks in Blocks

DDL Locks

• Exclusive DDL locks are required for:
  • DROP TABLE statements
  • ALTER TABLE statements
  • (The lock is released when the DDL statement completes.)
• Shared DDL locks are required for:
  • CREATE PROCEDURE statements
  • AUDIT statements
  • (The lock is released when the DDL parse completes)
• Breakable parse locks are used for invalidating statements in the shared SQL area.

Possible Causes

• Unnecessarily high locking levels
• Long-running transactions
• Uncommitted changes
• Other products imposing higher-level locks

Diagnostic Tools

• v$lock;(most important data dictionary)
• v$locked_object;
• dba_waiters
• dba_blocksers;

Guidelines for Resolving

Transaction 1		Transaction 2
UPDATE employees SET salary = salary * 1.1 WHERE empno = 1000；	09:00
	09:05
	10:30	UPDATE employees SET salary = salary * 1.1 WHERE empno = 1000;

method 1:COMMIT/ROLLBACK;

method 2:ALTER SYSTEM KILL SESSION '10,23';

Deadlocks(死锁模型)

Transaction 1		Transaction 2
UPDATE employees SET salary = salary * 1.1 WHERE empno = 1000;	9:00	UPDATE employees SET manager = 1342 WHERE empno = 2000;
UPDATE employees SET salary = salary * 1.1 WHERE empno = 2000;	9:15	UPDATE employees SET manager = 1342 WHERE empno = 1000;
ORA-00060:Deadlock detected while waiting for resource	9:16

 

 

死锁现象的发生一般是由于多个transaction，在抢占使用2个以上的资源时发生；以上述死锁模型为例，为了避免这种情况的发生，最好是transaction1与transaction2的使用资源顺序协商一致，以此来避免. 

Summary

In this lesson,you should have learned to do the following:

• Define levels of locking
• Identify causes of contention
• Prevent locking problems
• Use Oracle utilities to detect lock contention
• Resolve contention in an emergency
• Resolve deadblock conditions