The serializable mode of transaction behavior tries to ensure that transactions run in such a way that they appear to be executed one at a time, or serially, rather than concurrently.

• Dirty reads: A transaction reads data that has been written by another transaction that has not been committed yet
• Nonrepeatable reads: A transaction re-reads 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.

Oracle offers the read committed and serializable isolation levels, as well as a read-only mode. Read committed is the default.

How Oracle Manages Data Concurrency and Consistency

Multiversion Concurrency Control

Oracle automatically provides read consistency to a query so that all the data that the query sees comes from a single point in time (statement-level read consistency). Orable can also provide read consistency to all of the queries in a transaction (transaction-level read consistency).

Oracle uses the information maintained in its rollback segments to provide these consistent views. The rollback segments contain the old values of data that have been changed by uncommitted or recently committed transactions.

Statement-Level Read Consistency

Oracle always enforces statement-level read consistency. This gurantees that all the data returned by a single query comes from a single point in time - the time that the query begin.

As query execution proceesds, only data committed before the query began is visible to the query. The query does not see changes committed after statement execution begins.

Transaction-Level Read Consistency

Oracle also offers the option of enforcing transaction-level read consistency. When a transaction runs in serializable mode, all data accesses reflect the state of the database as of the time the transaction began.

This mean that the data seen by all queries within the same transaction is consistent with respect to a single point in time, except that queries mde by a serializable transaction do see changes mode by the transaction itself.

Transactional-level read consistency produces repeatable reads and does not expose a query to phantoms.

Comparison of Read Committed and Seriablizable Isolation

Row-Level Locking

Both read committed and serializable transactions use row-level locking, and both will wait if they try to change a row updated by an uncommitted concurrent transaction. The second transaction that tries to update a given row waits for the other transaction to commit or undo and release its lock. If that other transaction rolls back, the waiting transaction, regardless of its isolation mode, can proceed to change the previously locked row as if the other transaction had not existed.

Referential Integrity

Because Orable does not use read locks in either read-consistent or seriablizable transactions. data read by one transaction can be overwritten by another. Transaction that perform database consistency checks at the application level cannot assume that the data they read will remain unchanged during the execution of the transaction even though such changes are not visible to the transaction.