Stedman SQL Podcast Season 2, Episode 14: Mastering RCSI with Derrick Bovenkamp
Welcome to another insightful installment of the Stedman SQL Server Podcast! In Season 2, Episode 14, host Steve Stedman sits down with database expert Derrick Bovenkamp to explore Read Committed Snapshot Isolation (RCSI), a powerful SQL Server feature that can significantly enhance database performance and concurrency. Whether you’re a seasoned DBA or a developer looking to optimize your SQL Server environment, this episode is packed with practical knowledge and real-world applications. Let’s dive into the key takeaways from this engaging discussion.
What is RCSI?
Read Committed Snapshot Isolation (RCSI) is a SQL Server isolation level designed to improve concurrency by reducing blocking in database transactions. Unlike the default Read Committed isolation level, which can lead to blocking when readers and writers access the same data, RCSI leverages row versioning to provide a consistent snapshot of data at the start of a transaction. This allows readers to access data without waiting for writers to complete, resulting in smoother performance in high-transaction environments.
Derrick explains that RCSI is particularly valuable for applications with heavy read and write activity, such as e-commerce platforms or financial systems, where minimizing delays is critical. By enabling RCSI, you can reduce contention and improve the user experience without requiring significant code changes.
Why Use RCSI?
During the episode, Steve and Derrick highlight several compelling reasons to consider RCSI for your SQL Server databases:
- Reduced Blocking: RCSI eliminates the need for readers to wait for writers, preventing common performance bottlenecks caused by locks.
- Improved Concurrency: By providing a snapshot of data, RCSI allows multiple transactions to proceed simultaneously, boosting throughput.
- Minimal Application Changes: Unlike other isolation levels, RCSI can often be enabled with little to no modifications to existing application code, making it a low-effort optimization.
- Enhanced Scalability: For systems with growing transaction volumes, RCSI helps maintain performance as demand increases.
However, Derrick cautions that RCSI isn’t a one-size-fits-all solution. It relies on SQL Server’s tempdb for row versioning, which can increase tempdb usage and require careful monitoring to avoid performance issues.
How to Enable RCSI
One of the episode’s highlights is Derrick’s step-by-step guide to enabling RCSI in SQL Server. For those new to the feature, here’s a simplified overview based on their discussion:
- Check Compatibility: Ensure your SQL Server version supports RCSI (it’s available in SQL Server 2005 and later).
- Enable RCSI on the Database: Use the following T-SQL command to activate RCSI:sql
ALTER DATABASE [YourDatabaseName] SET READ_COMMITTED_SNAPSHOT ON; - Monitor tempdb Usage: Since RCSI uses row versioning, keep an eye on tempdb to ensure it’s adequately sized and optimized.
- Test Thoroughly: Before enabling RCSI in production, test it in a development or staging environment to confirm it meets your application’s needs.
Derrick emphasizes the importance of testing, as RCSI may introduce subtle changes in transaction behavior that could affect specific workloads. For example, applications relying on strict locking behavior might need adjustments.
Best Practices and Potential Pitfalls
To get the most out of RCSI, Steve and Derrick share several best practices:
- Optimize tempdb: Configure multiple tempdb data files and ensure sufficient disk space to handle increased row versioning.
- Monitor Performance: Use tools like Database Health Monitor (available at DatabaseHealth.com) to track tempdb usage and transaction performance.
- Understand Trade-offs: RCSI reduces blocking but may increase resource usage, so evaluate its impact on your server’s CPU, memory, and I/O.
- Document Changes: Clearly document when and why RCSI was enabled to aid future troubleshooting or database migrations.
On the flip side, Derrick warns of potential pitfalls, such as over-reliance on RCSI without proper tempdb optimization or failing to account for applications sensitive to snapshot-based reads. Careful planning and monitoring are key to a successful implementation.
Why Listen to This Episode?
This episode of the Stedman SQL Podcast is a must-listen for anyone managing SQL Server databases. Steve and Derrick’s conversation strikes a perfect balance between technical depth and practical advice, making complex concepts accessible to both beginners and seasoned professionals. Whether you’re troubleshooting performance issues or proactively optimizing your database, their insights on RCSI provide actionable strategies to elevate your SQL Server game.
Where to Listen or Watch
You can catch Season 2, Episode 14 of the Stedman SQL Server Podcast on multiple platforms:
- Spotify: https://spotifycreators-web.app.link/e/O043Tsi50Sb
- YouTube: https://youtu.be/4De7-0vx-2k
- Podcast Website: Find all episodes at shttps://stedmansolutions.com/home/sql-server-podcast/
Don’t miss out—subscribe to the podcast to stay updated on the latest SQL Server tips and tricks from Stedman Solutions!
Additional Resources
To complement the episode, check out these resources from Stedman Solutions:
- Database Health Monitor: A free tool to monitor and optimize your SQL Server performance, available at DatabaseHealth.com.
Don’t forget to check out all of our previous episodes from Season one!
More from Stedman Solutions:
Steve and the team at Stedman Solutions are here for all your SQL Server needs.
Contact us today for your free 30 minute consultation..
We are ready to help!

Hi Steve, thank you for the useful podcast.
The question:
You wrote: “RCSI leverages row versioning to provide a consistent snapshot of data at the start of a TRANSACTION”. If it is then I understand that read operation reads the data from committed transaction.
But in other article I have read: “it retrieves a snapshot of the data as it existed at the time the current statement started”. So in that case the 2nd session can read data from the active transaction which can be as committed as rolled back.
What is correct: from latest stmt or committed transaction?
Thanx.
Regards,
Oleg.
Oleg – thanks for the question.
RCSI does not allow for dirty reads (i.e. uncommitted transactions). Everything that is being read from RCSI has been committed.
When I say the start of the transaction, I should have clarified that as teh start of any open transactions.
For instance if I have a long running transaction open that has updated thousands of rows over the last 10 minutes, and you run a query with RCSI enabled, you would see the state of that data prior to my changes, or prior to the start of my long running transaction.
I hope that helps clarify things.
Have a great day! Thanks for listening to the podcast.
-Steve Stedman