Are your users seeing bad data?
If you’re using the default isolation level of read committed in SQL Server, chances are that sometimes your users get incorrect results — and that blocking can slow down their queries. If NOLOCK hints lurk in your code, the odds are even higher that sometimes your customers see information that just isn’t right.
What you’ll learn
In this demo packed seminar, you’ll learn why a single statement may read rows twice, miss rows entirely, or return combinations of data that never existed in the database — and why that’s not a bug. You’ll learn what “read phenomena” are, which isolation levels are vulnerable to them, and the performance trade-offs (also known as the risks of blocking) which come from raising your isolation level to protect your users from bad data.
You’ll discover why version-based isolation levels can be awesome for reducing blocking and providing data integrity. But you’ll also learn when some of these isolation levels may produce– you guessed it– incorrect results.
At the end of the seminar, we’ll pull together all this information into a guide. You’ll leave the seminar with the tools and knowledge to choose the right isolation levels for new and existing applications based on business and performance requirements.
Scripts and Slides
- Conquer Blocking and Isolation Levels - Slides (pdf)
- Conquer Blocking and Isolation Levels - Demo Scripts (zip)
- SQL Server Desktop Wallpapers – includes poster/wallpaper on isolation levels