Managing Data Concurrency and Consistency
Managing Data Concurrency and Consistency
Managing Data Concurrency and Consistency
Dirty reads: a transaction reads data that has been written by another
transaction that has not been committed yet
Fuzzy reads (nonrepeatable): a transaction rereads data it has previously
read and finds that another committed transaction has modified or deleted
the data
Phantom reads: a transaction re-runs a query returning a set of rows that
satisfies a search condition and finds that another committed transaction has
inserted additional rows that satisfy the condition
Isolation Level
Dirty Read
Nonrepeatable
Read
Phantom
Read
Read
uncommitted
Possible
Possible
Possible
Possible
Possible
Serializable
Not possible
Multiuser databases use some form of data locking to solve the problems associated
with data concurrency, consistency, and integrity. Locks are mechanisms that
prevent destructive interaction between transactions accessing the same
resource.
Resources include two general types of objects:
Oracle always enforces statement-level read consistency. All the data returned by a
single query comes from a single point in time, its the time that the query
executed. So, a query never sees dirty data or any of the changes made by
transactions that commit during query execution.
Only data committed before the query began is visible to the query. The
query does not see changes committed after statement execution begins.
This consistency enforced to a SELECT, INSERT, UPDATE and DELETE query (DML)
Note:
Description
This is the default transaction isolation level.
committed
Serializable
Read-only
you can set the isolation level of a transaction by using one of these statements at
the beginning of a transaction:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET TRANSACTION READ ONLY;
Use ALTER SESSION statement to set the transaction isolation level for all
subsequent transactions:
ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE;
ALTER SESSION SET ISOLATION_LEVEL = READ COMMITTED;
Serializable Isolation
Oracle database permits a serializable transaction to modify a data row only if it can
be determine that prior changes to the row were made by transactions that had
committed when the serializable transaction began.
Serializable isolation is suitable for environments:
With large databases and short transactions that update only a few rows
Where the chance that two concurrent transactions will modify the same rows
is relatively low
Where relatively long-running transactions are primarily read only
Oracle Database generates and error when a serializable transaction tries to update
or delete data modified by a transaction that commits AFTER the serializable
transaction began:
ORA-08177: Cannot serialize access for this transaction
When serializable transaction fails with the Cannot Serialize Access Error, the
application can take any of several actions:
Row-level Locking
Referential Integrity
Because oracle does not use read locks in either read-consistent or serializable
transactions, data read by one transaction can be overwritten by another.
Note:
You can use both read committed and serializable transaction isolation
levels with Oracle RAC.
Distributed Transactions
Modes of Locking
Deadlocks
Description
Prevents the associated 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
Allows the associated resource to be shared. Multiple users
reading data can share the data, holding share locks to prevent
concurrent access by a writer. Several transactions can acquire
share locks on the same resource
Deadlocks can occur when two or more users are waiting for data locked by each
other. Deadlocks prevent some transactions from continuing to work.
Oracle automatically detects deadlock situations and resolves them by rolling back
one of the statements involved in the deadlock, thereby releasing one set of the
conflicting row locks. The statement rolled back is the one belonging to the
transaction that detects the deadlock.
Note:
Avoid Deadlocks
Deadlocks can usually be avoided if transactions accessing the same table lock
those tables in the same order, either through implicit or explicit locks.
Types of Locks
Oracle locks fall into one of three general categories shown below
Lock
DML locks (data
locks)
DDL locks (dictionary
locks)
Internal locks and
latches
Description
DML locks protect data, for example: table locks lock
entire tables, row locks lock selected rows
DDL locks protect the structure of schema objects, for
example: the definitions of tables and views
Internal locks and latches protect internal database
structures such as datafiles. Internal locks and latches
are entirely automatic