■ Read consistency guarantees a consistent view of the data at all times.
■ Changes made by one user do not conflict with the changes made by another user.
■ Read consistency ensures that, on the same data:
– Readers do not wait for writers
– Writers do not wait for readers
– Writers wait for writers
Database users access the database in two ways:
■ Read operations (SELECT statement)
■ Write operations (INSERT, UPDATE, DELETE statements) You need read consistency so that the following occur:
■ The database reader and writer are ensured a consistent view of the data.
■ Readers do not view data that is in the process of being changed.
■ Writers are ensured that the changes to the database are done in a consistent manner.
■ Changes made by one writer do not disrupt or conflict with the changes being made by another writer.
The purpose of read consistency is to ensure that each user sees data as it existed at the last commit, before a DML operation started.
Implementing Read Consistency
Read consistency is an automatic implementation. It keeps a partial copy of the database in the undo segments. The read-consistent image is constructed from the committed data in the table and the old data that is being changed and is not yet committed from the undo segment.
When an insert, update, or delete operation is made on the database, the Oracle server takes a copy of the data before it is changed and writes it to an undo segment.
All readers, except the one who issued the change, see the database as it existed before the changes started; they view the undo segment’s “snapshot” of the data.
Before the changes are committed to the database, only the user who is modifying the data sees the database with the alterations. Everyone else sees the snapshot in the undo segment. This guarantees that readers of the data read consistent data that is not currently undergoing change.
When a DML statement is committed, the change made to the database becomes visible to anyone issuing a SELECT statement after the commit is done. The space occupied by the old data in the undo segment file is freed for reuse.
If the transaction is rolled back, the changes are undone:
■ The original, older version of the data in the undo segment is written back to the table.
■ All users see the database as it existed before the transaction began.