Ma n a g i n g Da t a

Concurrency
and Undo
 Managing Data Changes Using DML
• A change in the database is made using Data Manipulation Language
(DML). Data Definition Language (DDL) and Data Control Language
(DCL) statements also make changes, but to the data dictionary. INSERT,
DELETE, UPDATE, and MERGE are the DML statements available to
make changes to application data.
• A transaction is a logical unit of work.
• All the changes made by the SQL statements in a transaction commit or rollback
at the same time to ensure data consistency in the database.
• The use of transactions is one of the important ways in which a database
management system differs from a file-based system.
• In the database management system, a transaction must obey ACID properties.
• ACID stands for atomicity, consistency, isolation, and durability.
 Understanding “Change”
• With the first DML statement in a session, a transaction is initiated and it ends when
the change is saved (COMMIT) or when the change is discarded (ROLLBACK).
• When a change is made to the database, it is not immediately visible to other
sessions in the database. The change is visible only after the change-initiated
session performs a commit.
• Until the change is committed or rolled back, the before-image of change is saved
in the undo segments of the database.
• A consistent view of the data is provided to other sessions by using the data from
the undo blocks, as long as the change is not saved.
• Oracle also writes the changes to undo blocks and data blocks to log buffer and is
flushed to disk, to the online redo log files.
• The redo data keeps track of change, so that if needed the change can be
reapplied, or so that during instance recovery the change can be rolled back if the
transaction was not committed.
 Example
• Let’s assume user X issues UPDATE tabx SET namef = 'ABCD'. Oracle optimizer
determines the fastest way to get to the block based on statistics and indexes on the table.
• Once the block(s) with row(s) namef = 'ABCD' are identified, the server process reads
the blocks from the data file to buffer cache
(1). Before making changes to the block, the row is written to the undo segment, to re-
create the original state if needed
(2). The change that was made to the data is written to the log buffer, to repeat the change
if needed(3)
Since the undo block also changed, the undo change is written to the log buffer as well(3)
(4). When the log buffer is one-third full, or after 3 seconds or after a commit in the
database, the log buffer is written to the online redo log files by the LGWR process.
 The log buffer is flushed when one of the
following conditions is met:
• The log buffer is one-third full.
• The log buffer has 1MB of redo data.
• Three seconds have passed since the last flush.
• A commit has been performed.
• A database checkpoint occurs.
 Differentiating Undo and Redo
• The undo space is dynamic, and segments and extents are allocated as and when
required, whereas the redo log buffer is a fixed size.
• Undo data is the old value of data when a process or user changes data in a table.
• Undo data serves four purposes in an Oracle database:
• Rollback of a transaction
• Read consistency of DML operations and queries
• Instance recovery operations (undo data from the redo log file is used for instance recovery)
• Flashback functionality
• Redo data is written to the online redo log files, and the information is
used to reproduce a change.
• Redo data is used primarily for recovery by the database in the following
situations:
• Roll forward a change during instance recovery
• Archive the redo data in archive log files and use for point-in-time recovery of
database
• Use log miner to read the redo (online or archived) log files and reapply the change
or undo the change
 Using Undo for Transaction Rollback
• At the user-session level, there may be one or hundreds of DML
commands (such as DELETE, INSERT, UPDATE, or MERGE) within a
particular transaction that need to be undone.
• Undoing the changes within a transaction is called rolling back part or all
of the transaction.
• The undo information needed to roll back the changes is called,
appropriately, the rollback information and is stored in a special type of
tablespace called an undo tablespace.
• When an entire transaction is rolled back, Oracle uses the saved undo
information in the undo tablespace to undo all the changes since the
beginning of the transaction, releases any locks on rows involved in the
transaction, and ends the transaction.
• If a failure occurs on the client or a network, abnormally terminating the
user’s connection to the database, undo information is used in much the
same way as if the user explicitly rolled back the transaction, and Oracle
undoes all the changes since the beginning of the transaction, using
information saved in the undo tablespace.
Undo and Redo Application During Instance
Recovery
• When a database is shut down cleanly (not using SHUTDOWN ABORT),
a full checkpoint happens and, therefore, all the dirty blocks from the
buffer cache are written to the data files.
• As a result, when the database starts, there is no need for any kind of
recovery.
• If the database was shutdown using SHUTDOWN ABORT or if the
instance crashed for some reason, then during the instance start-up both
redo and undo data are required to put the database in a consistent state.
• when the database instance crashes or is brought down abruptly, Oracle
has the responsibility to perform a clean-up and bring the database to a
consistent state.
• In order to ensure that no committed change is lost, Oracle writes the redo
log buffer to redo log files immediately after a commit.
• As such, any change in the database is captured in the log file, but not
necessarily in the data file. Changed data blocks (dirty buffer) from the
buffer cache are written to the data files only during checkpoints.
• Instance recovery is a two-phase operation consisting of cache recovery
(or rolling forward) and transaction recovery (or rolling back). Cache
recovery uses redo information, and transaction recovery uses undo
information.
• During cache recovery, Oracle replays the transactions from the online
redo log files since the last checkpoint.
• During this roll forward operation, both committed and uncommitted
changes are applied to the data files.
• At the end of the roll-forward operation, the data files will have
committed changes, uncommitted changes that were written to the data
files to free up buffer cache space and uncommitted changes applied by
the roll-forward operation.
• The database can be opened as soon as cache recovery is complete.
• After the cache is recovered, the database is inconsistent; the database
includes both committed and uncommitted changes.
• To clean up the mess, Oracle uses the undo segments from the undo
tablespace.
• In the transaction-recovery phase of instance recovery, Oracle applies
undo blocks to roll back uncommitted changes in data blocks that were
either written before the instance crash or made by the roll-forward
operation during cache recovery.