Understanding Flashback Technology - OCP: Oracle Database 12c Administrator Certified Professional - page 353

Now, suppose the bank's computer system crashed after completing the first statement
but not the second. The money would be gone from her checking account but never added
to her savings account. She would be out $500 on the deal. Instead, the two statements
must be treated as a single, logical unit of work (in other words, a transaction). Only when
both statements have completed successfully should the changes be committed. If either
fails, they must both be rolled back.
When a user changes data in a table (via insert, update, or delete), the change does
not occur immediately. The user must either commit the change (finalize it) or roll it
back (undo it). Until they do, the database must keep track of both versions of the data
(before the change and after the change).
In order to meet this requirement, the database will modify the data in the table to
reflect the change and create an undo record in the undo tablespace that contains any
data needed to undo the change.
Although the transaction remains in limbo (neither committed nor rolled back), other
users who query the table will see the data as it looked prior to the change. If the user
decides to roll back the transaction, the undo information is used to modify the table data
to revert it to its previous value. If the user decides to commit the transaction, the change
becomes permanent.
From strictly a transaction-processing standpoint (allowing a transaction the option
of committing or rolling back), the undo records for a transaction are useless after the
transaction finishes. They have served their purpose and could be deleted. However,
by retaining undo information for a period of time after a commit, many new options
become available to us.
As you will see as you continue through this chapter, the whole host of Flashback options
becomes available by the simple act of retaining undo records for a period of time after they
have been committed.
Recovering Failed Transactions
A failed transaction is a transaction that never completes; that is, it never commits or rolls
back. This can happen for a variety of reasons, but they all boil down to a session closing
with a transaction still in progress.
Since most (if not all) Oracle clients are designed to either commit or roll back automati-
cally when a session is closed, simply forgetting to finish a transaction before exiting will rarely
result in a failed transaction. In general, a failed transaction occurs because of an abnormal
server shutdown (because of hardware failure, loss of power, or even a shutdown abort ).
When a failed transaction is discovered (generally at startup time following an abnor-
mal shutdown), Oracle will undo the transaction automatically using the data stored in
the undo tablespace.
Maintaining Read Consistency
When a user issues a query, the database is required to process the query and return the data
as it looked at the moment the query started. In other words, if you kicked off a long-running