Nonrepeatable reads defined What anomaly occurs when a transaction re-reads rows it previously read and finds that some have been modified or deleted by another committed transaction?

Introduction / Context:
Nonrepeatable reads reflect instability of previously observed rows under concurrent updates. They are distinct from phantoms (new rows) and from dirty reads (uncommitted data). Understanding the distinctions guides proper isolation selection.

Given Data / Assumptions:

• We read a particular row or set of identified rows.
• Later, re-reading the same rows returns different committed values or shows that rows were deleted.
• Another transaction committed the changes in between.

Concept / Approach:

At READ COMMITTED, each statement sees a fresh committed view, so repeated reads of the same row can differ. Preventing this requires REPEATABLE READ (row-level stability) or SERIALIZABLE (full schedule equivalence), depending on the engine's semantics.

Step-by-Step Solution:

Verification / Alternative check:

Academic and vendor references classify nonrepeatable reads as changes to previously read rows, in contrast with phantoms that concern new qualifying rows for a predicate.

Why Other Options Are Wrong:

• Phantom read: concerns new rows appearing in a range, not changes to an already-read row.
• Dirty read: involves uncommitted data, not committed changes.
• Consistent read: stable view, typically the opposite of this anomaly.
• Write skew: a snapshot anomaly involving concurrent writes to disjoint rows under SI.

Common Pitfalls:

• Using READ COMMITTED while expecting identical re-reads of the same row.
• Confusing predicate instability (phantoms) with row instability (nonrepeatable read).

Final Answer:

Nonrepeatable read.