Which transaction isolation level prevents dirty reads but allows non-repeatable reads and phantom reads?
Think about which isolation level only blocks reading uncommitted data but does not lock rows for repeatable reads.
Read Committed prevents dirty reads by only reading committed data. However, it does not prevent non-repeatable reads or phantom reads because data can change between reads.
Consider two transactions running concurrently under Repeatable Read isolation level. Transaction 1 reads a row, then Transaction 2 updates that row and commits. Transaction 1 reads the same row again.
What will Transaction 1 see on the second read?
Repeatable Read guarantees the same data for repeated reads within the same transaction.
Under Repeatable Read, once a row is read, the transaction sees the same data for that row even if other transactions commit changes. This prevents non-repeatable reads.
Which SQL statement correctly sets the transaction isolation level to Serializable for the current session in standard SQL?
Focus on the standard SQL syntax for setting isolation level.
The standard SQL command to set the isolation level for the current transaction is SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;. Other options are either vendor-specific or invalid.
You want to maximize concurrency in a database system but still avoid dirty reads. Which isolation level should you choose?
Consider which isolation level balances data accuracy and concurrency.
Read Committed avoids dirty reads and allows higher concurrency than Repeatable Read or Serializable, which use more locking and reduce concurrency.
In a database using Repeatable Read isolation level, a transaction reads a set of rows matching a condition twice and sees different rows the second time (phantom reads). What is the most likely cause?
Think about what Repeatable Read guarantees and what it does not.
Repeatable Read prevents non-repeatable reads by locking rows but does not lock the range of rows scanned, so phantom rows can appear if new rows are inserted.