For years, SQL Server Management Studio has anchored day-to-day database work. Most improvements since the 2010s were minor interface tweaks or new wizards that left the underlying 32-bit shell untouched. SSMS 21 marks a clean break: it moves to a modern 64-bit platform, folds indispensable tools into the core product, and refreshes the entire interface without changing the familiar Object Explorer + Query Editor workflow. The result is the same trusted environment—only faster, more accessible, and far better equipped for today’s workloads.
Author: Stephen Planck
Verifying SQL Server Backups with PowerShell and SMO
Regularly restoring test copies of your databases is the gold-standard proof that your backups work. Between those tests, however, RESTORE VERIFYONLY offers a fast way to confirm that a backup file is readable, that its page checksums are valid, and that the media set is complete. In this post you will see how to run that command from PowerShell by invoking SQL Server Management Objects (SMO), turning a one-off verification into a repeatable step you can schedule across all your servers.
Five SQL Server 2025 Enhancements DBAs Will Notice
There is a lot to be excited about in SQL Server 2025! When thinking about features that may not get as much attention as others, yet will make a real difference in the lives of DBAs, I have selected my top 5 enhancements for SQL Server 2025. These improvements may not make the headlines, but they address pain points we’ve all experienced as DBAs. Please let me know if I’ve left any of your favorites off the list.
Filtered Indexes in SQL Server: Targeted Performance in High-Volume Tables
When a table holds millions of rows yet most queries touch only a small, well-defined subset, a traditional non-clustered index feels like using a searchlight to find something sitting under a desk lamp: the index still stores an entry for every row even though the workload rarely needs most of them. SQL Server’s answer is the filtered index—introduced in SQL Server 2008 and still under-used today—allowing you to index just the rows that match a predicate you supply in a WHERE clause.
Database Snapshots in SQL Server High-Availability Setups
A database snapshot in SQL Server provides an instant, read-only view of your data at a specific point in time without blocking the live workload. This post explores how snapshots interact with high-availability technologies—Always On Availability Groups, log shipping, and transactional replication—highlighting that creating a snapshot is always safe but restoring it severs existing sync mechanisms. You’ll learn the steps required to roll back to a snapshot, including AG reseeding, log-shipping reinitialization, or replication re-initialization, and why planning for these operations is essential. The post also covers practical tips on monitoring sparse-file growth and choosing between snapshots and full backups for longer-term retention.
Working with Database Snapshots in SQL Server
Database snapshots are one of those features that’s been around forever, but still solves real-world problems with very little setup. In a single statement you can capture a point-in-time, read-only copy of any user database, use it for reporting or off-load testing, and—if disaster strikes—revert the source back to that snapshot in minutes. This guide explains how snapshots work under the hood, walks through day-to-day tasks (including creating the original database), and highlights the pitfalls you should plan for before using them in production.
Restoring a Single Data Page in SQL Server: A DBAs Guide
Usually corruption in SQL Server is either nonexistent or so widespread that you have no choice but to perform a file or full‑database restore. Yet an awkward middle ground exists: a handful of pages—perhaps only one—become unreadable while the rest of the database remains perfectly healthy. A full restore would repair the damage, but at the cost of rolling back hours of work and locking users out of an otherwise functional system. That’s precisely why Microsoft built RESTORE … PAGE. You can surgically overwrite just the bad 8‑KB chunks, roll them forward with transaction‑log backups, and return the database to service in minutes rather than hours.
Introduction to Temporal Tables: Seamless Record Versioning in SQL Server
Have you ever wanted to see exactly how a row looked in your SQL Server database a week or a month ago—without writing complicated auditing code or triggers? With temporal tables (also known as system-versioned tables), you can do precisely that. Temporal tables automatically track historical data changes by maintaining multiple versions of each row in a separate history table. Let’s explore how they work, why you might use them, how to set them up, and what best practices to follow.
Remembering Yvonne Vanslageren
As some of you may have noticed, our last blog post was on February 18th. On February 19th, 2025, Yvonne Vanslageren, the cofounder of this blog and my very dear friend, passed away after a short battle with illness. She was 55 years old. Her unexpected loss has devastated her family, colleagues and myself. When I first got the news I couldn’t bring myself to touch the blog which is why I’m notifying you all of this so late.
Lock Escalation in SQL Server: Understanding and Troubleshooting for Performance
Lock escalation is a built-in mechanism in SQL Server designed to optimize how the database engine manages locks. By reducing thousands of fine-grained locks (such as row or page locks) to a single table-level lock, SQL Server aims to lower overhead in the lock manager. In practice, lock escalation saves system resources but can also introduce challenges in high-concurrency environments. This post explores why lock escalation happens, how it works under the hood, the problems it can cause, and strategies to prevent or mitigate unwanted escalations.