A sales dashboard runs under the READ UNCOMMITTED isolation level and occasionally displays order totals that include rows from transactions that are later rolled back. Which change prevents this with the least additional blocking?
Select an answer to reveal the explanation.
Short Explanation
Reading uncommitted data is like announcing the score before the referee confirms the goal: sometimes the goal gets taken back. That's a dirty read, and READ COMMITTED is the first rung on the ladder that stops it. Watch the trap: jumping all the way to SERIALIZABLE works, but it isn't the lowest level and it costs you far more blocking.
Full Explanation
A dirty read occurs when a transaction reads data written by another transaction that has not yet committed; if that writer rolls back, the reader has used values that never officially existed. READ UNCOMMITTED explicitly allows dirty reads, which is why the dashboard sometimes includes rolled-back orders. In the ANSI SQL isolation hierarchy, READ COMMITTED is the lowest level that prohibits dirty reads, so moving the dashboard to it fixes the symptom while keeping locking and blocking overhead modest. SERIALIZABLE also prevents dirty reads, but it is the highest level rather than the lowest, adding range locking or validation that increases contention for no benefit here. Wrapping the query in an explicit transaction does not change the isolation level; the reads inside it are still uncommitted reads. Issuing COMMIT after a SELECT ends the reader's own transaction but has no effect on whether other sessions' uncommitted changes were visible to it. Exam caveat: READ COMMITTED still permits nonrepeatable reads and phantoms, which matter only when a transaction re-reads data. Operational check: confirm the session isolation level the dashboard connection actually uses, because drivers and connection pools can set it independently of the database default.