Oracle Database - Locks

Card Puncher Data Processing


Lock Mechanism in Oracle

Oracle Database provides:

  • consistency. The data a session is viewing or changing must not be changed by other sessions until the user is finished.
  • and integrity. The data and structures must reflect all changes made to them in the correct sequence.

among transactions through a locking mechanisms.

The locks are:

  • performed automatically and requires no user action.
  • directly associated with a session.

Locks are mechanisms that prevent destructive interaction between transactions accessing the same resource. The resources can be either:

  • user objects, such as tables and rows,
  • or system objects not visible to users, such as shared data structures in memory and data dictionary rows.

Oracle Database automatically obtains and manages necessary locks when executing SQL statements, so you need not be concerned with such details. However, the database also lets you lock data manually.

A lock is a mechanism that prevents destructive interactions, which are interactions that incorrectly update data or incorrectly alter underlying data structures, between transactions accessing shared data.

Oracle Database automatically obtains necessary locks when executing SQL statements. For example, before the database permits a session to modify data, the session must first lock the data. The lock gives the session exclusive control over the data so that no other transaction can modify the locked data until the lock is released.

Because the locking mechanisms of Oracle Database are tied closely to transaction control, application designers need only define transactions properly, and Oracle Database automatically manages locking. Users never need to lock any resource explicitly, although Oracle Database also enables users to lock data manually.

Summary of Locking Behavior

The database maintains several different types of locks, depending on the operation that acquired the lock. In general, the database uses two types of locks:

  • exclusive locks (Only one exclusive lock can be obtained on a resource such as a row or a table)
  • and share locks (Many share locks can be obtained on a single resource)

Locks affect the interaction of readers and writers. A reader is a query of a resource, whereas a writer is a statement modifying a resource.

The following rules summarize the locking behaviour of Oracle Database for readers and writers:

  • A row is locked only when modified by a writer. When a statement updates one row, the transaction acquires a lock for this row only. By locking table data at the row level, the database minimizes contention for the same data. Under normal circumstances the database does not escalate a row lock to the block or table level.
  • A writer of a row blocks a concurrent writer of the same row. If one transaction is modifying a row, then a row lock prevents a different transaction from modifying the same row simultaneously.
  • A reader never blocks a writer. Because a reader of a row does not lock it, a writer can modify this row. The only exception is a SELECT … FOR UPDATE statement, which is a special type of SELECT statement that does lock the row that it is reading.
  • A writer never blocks a reader. When a row is being changed by a writer, the database uses undo data data to provide readers with a consistent view of the row.

Readers of data may have to wait for writers of the same data blocks in very special cases of pending distributed transactions.

Lock Modes

Oracle Database automatically uses the lowest applicable level of restrictiveness to provide the highest degree of data concurrency yet also provide fail-safe data integrity:

  • The less restrictive the level, the more available the data is for access by other users.
  • Conversely, the more restrictive the level, the more limited other transactions are in the types of locks that they can acquire.

Oracle Database uses two modes of locking in a multi-user database:


The Exclusive lock mode prevents the associated resource from being shared. A transaction obtains an exclusive lock when it modifies data. The first transaction to lock a resource exclusively is the only transaction that can alter the resource until the exclusive lock is released.


The Share lock mode allows the associated resource to be shared, depending on the operations involved. Multiple users reading data can share the data, holding share locks to prevent concurrent access by a writer who needs an exclusive lock. Several transactions can acquire share locks on the same resource.


Assume that a transaction uses a SELECT … FOR UPDATE statement to select a single table row. The transaction acquires:

  • an exclusive row lock. It allows other sessions to modify any rows other than the locked row
  • and a row share table lock. The table lock prevents sessions from altering the structure of the table

Thus, the database permits as many statements as possible to execute.

Conversion and Escalation


Oracle Database performs lock conversion as necessary. In lock conversion, the database automatically converts a table lock of lower restrictiveness to one of higher restrictiveness.

For example, suppose a transaction issues a SELECT … FOR UPDATE for an employee and later updates the locked row. In this case, the database automatically converts the row share table lock to a row exclusive table lock. A transaction holds exclusive row locks for all rows inserted, updated, or deleted within the transaction. Because row locks are acquired at the highest degree of restrictiveness, no lock conversion is required or performed.


Lock conversion is different from lock escalation, which occurs when numerous locks are held at one level of granularity (for example, rows) and a database raises the locks to a higher level of granularity (for example, table).

If a user locks many rows in a table, then some databases automatically escalate the row locks to a single table.

The number of locks decreases, but the restrictiveness of what is locked increases.

Oracle Database never escalates locks. Lock escalation greatly increases the likelihood of deadlocks. Assume that a system is trying to escalate locks on behalf of transaction 1 but cannot because of the locks held by transaction 2. A deadlock is created if transaction 2 also requires lock escalation of the same data before it can proceed.

Automatic Locks

Oracle Database automatically locks a resource on behalf of a transaction to prevent other transactions from doing something that requires exclusive access to the same resource. The database automatically acquires:

  • different types of locks
  • at different levels of restrictiveness

depending on the resource and the operation being performed.

The database never locks rows when performing simple reads.

Oracle Database locks are divided into the following categories.

  • DML Locks. Protect data. For example, table locks lock entire tables, while row locks lock selected rows.
  • DDL Locks. Protect the structure of schema objects—for example, the dictionary definitions of tables and views.
  • System Locks. Protect internal database structures.

Rules to avoid lock

  • run the change late at night when the database is idle.
  • Do all DDL during a maintenance window with all end-users locked-out.
  • Kill the sessions that are preventing the exclusive lock.



Located in the directory : oracle_home\db_1\RDBMS\ADMIN

  • catblock.sql, creates the lock views that utllockt.sql needs, so you must run it before running utllockt.sql.
  • utllockt.sql script displays, in a tree fashion, the sessions in the system that are waiting for locks and the locks that they are waiting for. The location of this script file is operating system dependent.

View and table

The base table for all locks is the VLOCK view.

Oracle has several views for showing lock status, some of which show the username:

  • DBA_BLOCKERS – Shows non-waiting sessions holding locks being waited-on
  • DBA_DDL_LOCKS – Shows all DDL locks held or being requested
  • DBA_DML_LOCKS - Shows all DML locks held or being requested
  • DBA_LOCK_INTERNAL – Displays 1 row for every lock or latch held or being requested with the username of who is holding the lock
  • DBA_LOCKS - Shows all locks or latches held or being requested
  • DBA_WAITERS - Shows all sessions waiting on, but not holding waited for locks


Oracle Database automatically releases a lock when some event occurs so that the transaction no longer requires the resource.

In most cases, the database holds locks acquired by statements within a transaction for the duration of the transaction.

These locks prevent destructive interference such as:

  • dirty reads,
  • lost updates,
  • and destructive DDL

from concurrent transactions.

A table lock taken on a child table because of an unindexed foreign key is held for the duration of the statement, not the transaction. Also, the DBMS_LOCK package enables user-defined locks to be released and allocated at will and even held over transaction boundaries.

Oracle Database releases all locks acquired by the statements within a transaction when it commits or rolls back. Oracle Database also releases locks acquired after a savepoint when rolling back to the savepoint.

However, only transactions not waiting for the previously locked resources can acquire locks on the now available resources. Waiting transactions continue to wait until after the original transaction commits or rolls back completely

Lock Type

There are dozens of lock types, but the vast majority are system types. System locks are normally only held for a very brief amount of time.

There are only three types of user locks:

  • TX. The TX lock is a row transaction lock; it's acquired once for every transaction that changes data, no matter how many objects you change in that transaction. The ID1 and ID2 columns of Vlock point to the rollback segment and transaction table entries for that transaction.
  • TM. The TM lock is a DML lock. It's acquired once for each object that's being changed. The ID1 column of Vlock identifies the object being modified.
  • and UL. UL is a user-defined lock – a lock defined with the DBMS_LOCK package.


The DBA_LOCK_INTERNAL view used to show locks for a specific user, and you can specify the query in the form:

   NVL(b.username,'SYS') username,
   sys.dba_lock_internal a,
   sys.v_$session b
   where ...

You can also query vaccess and vlocked_object to see specific locks:

select s.sid, s.serial#, p.spid
   v$session s,
   v$process p
   s.paddr = p.addr
   s.sid in (select SESSION_ID from v$locked_object);


Show locked objects

set lines 100 pages 999
col username 	format a20
col sess_id 	format a10
col object	format a25
col mode_held	format a10
select	oracle_username || ' (' || s.osuser || ')' username
,	s.sid || ',' || s.serial# sess_id
,	owner || '.' ||	object_name object
,	object_type
,	decode(	l.block
	,	0, 'Not Blocking'
	,	1, 'Blocking'
	,	2, 'Global') status
,	decode(v.locked_mode
	,	0, 'None'
	,	1, 'Null'
	,	2, 'Row-S (SS)'
	,	3, 'Row-X (SX)'
	,	4, 'Share'
	,	5, 'S/Row-X (SSX)'
	,	6, 'Exclusive', TO_CHAR(lmode)) mode_held
from	v$locked_object v
,	dba_objects d
,	v$lock l
,	v$session s
where 	v.object_id = d.object_id
and 	v.object_id = l.id1
and 	v.session_id = s.sid
order by oracle_username
,	session_id

In Toad

In the menu Database / Monitor / Session Browser

Toad Lock

Session Set

10gR2 or above.

alter session set DDL_WAIT_FOR_LOCKS=true;

Session altered.

Documentation / Reference

Discover More
Card Puncher Data Processing
Oracle - Monitoring

Oracle - Monitoring
Card Puncher Data Processing
Oracle Database

Documentation about the Oracle database
Card Puncher Data Processing
Oracle Database - COMMIT (of a transaction)

in oracle A commit ends the current transaction and makes permanent all changes performed in the transaction. When a transaction commits, the following actions occur: A system change number...
Card Puncher Data Processing
Oracle Database - DBMS_LOCK

The DBMS_LOCK package enables user-defined locks to be released and allocated at will and even held over transaction boundaries.
Card Puncher Data Processing
Oracle Database - DDL Locks (data dictionary lock)

A data dictionary (DDL) lock protects the definition of a schema object while an ongoing DDL operation (CREATE, ALTER, DROP) acts on or refers to the object. Only individual schema objects that are modified...
Card Puncher Data Processing
Oracle Database - DML Lock

A DML lock, also called a data lock, guarantees the integrity of data accessed concurrently by multiple users. For example, a DML lock prevents two customers from buying the last copy of a book available...
Card Puncher Data Processing
Oracle Database - Deadlock

A deadlock can occur when two or more users are waiting for data locked by each other. Deadlocks prevent some transactions from continuing to work. Oracle Database automatically detects deadlock situations...
Oracle Database Lock Foreign Key Unindexed
Oracle Database - Locks and Foreign Keys - Concurrency control of parent keys

Oracle Database maximizes the concurrency control of parent keys in relation to dependent foreign keys. Locking behaviour depends on whether foreign key columns are indexed. If foreign keys are not indexed,...
Card Puncher Data Processing
Oracle Database - ROLLBACK (undo of a transaction)

Use the ROLLBACK statement to undo work done in the current transaction or to manually undo the work done by an in-doubt distributed transaction. An implicit ROLLBACK occurs when the session (or...
Card Puncher Data Processing
Oracle Database - Read Consistency

in Oracle The database uses a transaction table, also called an interested transaction list (ITL), to determine if a transaction was uncommitted when the database began modifying the block. The block...

Share this page:
Follow us:
Task Runner