Scribd
Upload
7 views3 pages

Avoiding Phantom Reads

Phantom reads occur in SQL Server when a transaction reads data that can be altered by other transactions, leading to inconsistent results. To prevent phantom reads, stricter isolation levels like Serializable and Snapshot can be used, where Serializable prevents any changes during a transaction and Snapshot provides a consistent view of data at the transaction's start. SQL Server employs various lock types, including Shared, Exclusive, and Update locks, to manage concurrent access to data.

Uploaded by

shreekant420
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
7 views3 pages

Avoiding Phantom Reads

Phantom reads occur in SQL Server when a transaction reads data that can be altered by other transactions, leading to inconsistent results. To prevent phantom reads, stricter isolation levels like Serializable and Snapshot can be used, where Serializable prevents any changes during a transaction and Snapshot provides a consistent view of data at the transaction's start. SQL Server employs various lock types, including Shared, Exclusive, and Update locks, to manage concurrent access to data.

Uploaded by

shreekant420
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

A phantom read is a phenomenon that occurs in SQL Server (and other relational database management

systems) when a transaction reads a set of rows matching a condition, but another transaction inserts,
updates, or deletes rows that affect the result of the original query. This causes the result of the original
query to change if it is re-executed within the same transaction.

Avoiding Phantom Reads


Phantom reads can be prevented by using stricter isolation levels:

1. Serializable Isolation Level:


o This is the strictest isolation level, ensuring no new rows are inserted or deleted by
other transactions within the range of the query.
o SQL Server achieves this by placing range locks on the queried data.
sql

Snapshot Isolation Level:

· Instead of locking, SQL Server uses row versioning to provide a consistent snapshot of the data
for the duration of the transaction.
· This prevents phantom reads without blocking other transactions

Types of Locks in SQL Server


SQL Server uses several types of locks, categorized based on the resource being locked and the type of
operation (read/write):

1. Lock Types by Operation:

· Shared Lock (S):


o Used for read-only operations (e.g., SELECT queries).
o Allows multiple transactions to read the same resource but prevents any transaction
from modifying it.
· Exclusive Lock (X):
o Used for write operations (e.g., INSERT, UPDATE, DELETE).
o Ensures that only one transaction can modify the resource, preventing others from
reading or writing.
· Update Lock (U):
o Used to prevent deadlocks in situations where a transaction intends to update data.
o Initially applied as a shared lock, but converted to an exclusive lock when the data is
modified.
· Intent Locks (IS, IX, SIX):
o Used to indicate the intent to acquire a specific type of lock on a resource. These are hi-
erarchical locks applied at the table or page level to manage finer-grained locks.
Repeatable Read
• Shared locks are held on all data read during the transaction and are not released until the transac-
tion completes.
• Prevents other transactions from updating or deleting the rows read by the current transaction.

Repeatable Read in Simple Terms


Repeatable Read ensures that once you’ve read some data in a transaction, that data cannot be
changed by any other transaction until your transaction is complete. This means you’ll always see the
same data if you read it again during your transaction. However, new data (rows) can still be added by
other transactions, which you might not see.

Read Committed in SQL Server (Layman's Terms)


Read Committed is the default isolation level in SQL Server. It ensures that when you read data, you
only see data that has been fully committed (finalized) by other transactions. You won’t see any tempo-
rary or uncommitted changes (unlike Read Uncommitted).

Serializable

Serializable is an extreme measure to demand total control of the range of rows being modified. It will not read un-
committed and it will not allow other transactions to read data that it is modifying. As such, it requires exclusive locks,
causing other transactions to wait for it to complete. This also prevents other rows from being added to the set of
records, preventing what is known as a phantom read.
Serializable Isolation (Layman’s Terms)
Serializable is the strictest isolation level. It ensures that transactions behave as though they are hap-
pening one after the other, never overlapping. You’ll never see incomplete data or changes that might
affect your work, and other transactions can’t make any changes that would interfere with what you’re
doing. This prevents any type of "phantom reads," meaning you won’t see new data that shows up dur-
ing your transaction.

Snapshot Isolation (Layman’s Terms)


Snapshot Isolation gives you a "picture" of the data at the time your transaction started. You can see
the data as it was when you began, even if other transactions are making changes during your work. You
won’t see any of those changes until you commit your transaction. This isolation level prevents dirty
reads, but it still allows for other transactions to change data that doesn’t directly affect what you're
working on.

You might also like