Oracle Locks

Locks are mechanisms that prevent destructive interaction between transactions accessing
the same resource.
General Object Type Affected By Locks:
1) User objects, such as tables and rows (structures and data)
2) System objects not visible to users, such as shared data structures in the memory and
data dictionary rows

Oracle Lock Duration

All locks acquired by statements within a transaction are held for the duration of the
transaction.
Oracle releases all locks acquired by the statements within a transaction when an explict
or implied commit or roll back is
executed. Oracle also releases locks acquired after a savepoint when rolling back to the
savepoint.

Oracle Lock Modes

1) Exclusive Lock Mode
2) Share Lock Mode
Exclusive Lock Mode
Prevents the associates resource from being shared. This lock mode is obtained to modify
data. The first transaction to
lock a resource exclusively is the only transaction that can alter the resource until the
exclusive lock is released.
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.

Oracle Lock Types

1) DML locks (data locks)
2) DDL locks (dictionary locks)
3) Oracle Internal Locks/Latches
4) Oracle Distributed Locks
DML locks (data locks)
DML locks protect data. For example, table locks lock entire tables, row locks lock
selected rows.
DML operations can acquire data locks at two different levels: for specific rows and for
entire tables.

Oracle DML Lock Types

1)Row Level Locks
2)Table Level Locks

Oracle Row Locks [TX]

All DML locks Oracle acquires automatically are row-level locks.
No limit to the number of row locks held by a transaction.
Oracle does not escalate locks from the row level.
Row locking provides the lowest level of locking possible provides the best possible
transaction concurrency.
Readers of data do not wait for writers of the same data rows.
A modified row is always locked exclusively so that other users cannot modify the row
until the transaction holding the lock is committed or rolled back.
If a transaction obtains a row lock for a row, the transaction also acquires a table lock for
the corresponding table. The table lock prevents conflicting DDL operations that would
override data changes in a current transaction.

Oracle Table Level Lock [TM]

A transaction acquires a table lock for DML statements such as
INSERT/UPDATE/DELETE, SELECT with the FOR UPDATE, and LOCK TABLE.
Reasons are to reserve DML access to the table on behalf of a transaction and prevent
DDL operations
Table locks prevent the an exclusive DDL lock on the same table which prevents DDL
operations. Example, a table cannot be altered or dropped if any uncommitted
transaction holds a table lock for it.
A table lock can be held in several modes: row share (RS), row exclusive (RX), share (S),
share row exclusive (SRX), and exclusive (X).

Oracle DDL Locks

Protects the definition of an object while being used by a DDL operation. Recall that a
DDL statement implicitly commits.
Create Procedure will automatically acquire DDL locks for all schema objects referenced
in the procedure definition. The DDL locks prevent objects referenced in the procedure
from being altered/dropped before the compile is complete.
Cannot explicitly request DDL locks. Individual schema objects that are modified or
referenced are locked during DDL operations; the whole data dictionary is never locked.
Three categories: exclusive DDL locks, share DDL locks, and breakable parse locks.

Oracle DDL Lock Modes

1) Exclusive DDL Locks
2) Shared DDL Locks
3) Breakable Parse Locks

Oracle Exclusive DDL Lock

Most DDL operations require exclusive DDL locks for a resource to prevent destructive
interference with other DDL operations on the same object.
In the acquisition of an exclusive DDL lock, if another DDL lock is already held on the
object by another operation, the lock get waits until the other DDL lock is released before
proceeding.
DDL operations also acquire DML locks (data locks) on the schema object to be
modified.

Oracle Shared DDL Lock

Some DDL need a share DDL lock for an object to prevent destructive interference other
conflict DDL operations, but allow data concurrency for other DDL. For example, when
a CREATE PROCEDURE executes, the transaction acquires share DDL locks for all
referenced tables. Other transactions can concurrently create procedures that reference
the same tables and therefore acquire concurrent share DDL locks on the same tables, but
no transaction can acquire an exclusive DDL lock on any referenced table. No transaction
can alter or drop a referenced table. As a result, a transaction that holds a share DDL lock
is guaranteed that the definition of the referenced schema object will remain constant for
the duration of the transaction.
Gotten on an object for DDL statements that have: AUDIT, NOAUDIT, COMMENT,
CREATE [OR REPLACE] VIEW/PROCEDURE/PACKAGE/ PACKAGE
BODY/FUNCTION/ TRIGGER, CREATE SYNONYM, and CREATE TABLE (when
the CLUSTER parameter is not included).

Oracle Breakable Parse Locks

A SQL statement (or PL/SQLprogram unit) in the shared pool holds a parse lock for each
object referenced. Parse locks are gotten so that the associated shared SQL area can be
invalidated if a referenced object is altered or dropped. A parse lock does not disallow
any DDL operation and can be broken to allow conflicting DDL operations.
Gotten during the parse phase of SQL statement execution and held as long as the shared
SQL area for that statement
remains in the shared pool.

Oracle Internal Locks/Latches

Internal locks and latches protect Oracle internal database structures such like datafiles.
Internal locks and latches are entirely handled by Oracle internal functions and are
automatic. Some Internal Latches can be turned by an Oracle DBA.

Oracle Latches
Latches are low-level serialization mechanisms to protect shared data structures in the
system global area (SGA). Latches protect the oracle lists like list of users currently
accessing the database and protect the data structures describing the blocks in the buffer

cache. A server or background process acquires a latch for a very short time while
manipulating or looking at one of these structures. The implementation of latches is
operating system dependent, particularly in regard to whether and how long a process
will wait for a latch.

Oracle Internal Locks

Data Dictionary Locks
Held on entries in dictionary caches while the entries are being modified or used. They
guarantee that statements being parsed do not see inconsistent object definitions.
File and Log Management Locks
Protect various files like control files, redo log files so that only one process at a time can
change it. Datafiles are locked to ensure that multiple instances mount a database in
shared mode or that one instance mounts it in exclusive mode.
Tablespace and Rollback Segment Locks
Protect tablespaces and rollback segments. Example, all instances accessing a database
must agree on if s tablespace is online or offline. Rollback segments are locked so that
only one instance can write to a segment.

Oracle Distributed Locks

Distributed locks ensure that the data and other resources distributed among the various
instances consistent.Distributed
locks are held by instances rather than transactions.

Deadlocks
Oracle automatically detects deadlock situations and resolves them by rolling back one of
the statements involved in the deadlock. This releases one set of the conflicting row
locks. A corresponding message also is returned to the transaction that undergoes the
rollback.
Deadlocks often occur when transactions override Oracle default locking. Oracle itself
does no lock escalation and does not use read locks for queries and does not use pagelevel locking, deadlocks rarely occur in Oracle.
Deadlocks can usually be avoided if transactions accessing the same tables lock those
tables in the same order, either through implicit or explicit locks and when a sequence of
locks for one transaction are required, you should consider acquiring the most exclusive
(least compatible) lock first.
Always close explicit cursors when finished to free locks.

Action to be taken after getting the alert

The alert gives the sid and serial# and spid of the session which is locking the library
cache,

the database session has to be terminated login to the database.

alter system kill session 'sid,serial#';