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