A checkpoint is a background process that writes dirty pages to disk. A checkpoint performs a full scan of the pages in the buffer pool, lists all the dirty pages that are yet to be written to disk, and finally writes those pages to disk. In SQL instances that do not have many dirty pages in the buffer pool, this is a trivial operation. However, with SQL instances that have OLTP databases, use more memory and/or involve sequential scanning of all pages, the performance of the system could be impacted.
Category: Storage Engine
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.
Understanding and Resolving TempDB Contention in SQL Server
TempDB contention is a common challenge in SQL Server when running highly concurrent workloads. In this post, we will explore why it occurs, how to identify it, and some practical solutions—especially leveraging In-Memory OLTP and memory-optimized table variables.
Optimizing Table Width and Data Types in SQL Server
Organizing data effectively in SQL Server can be a juggling act. You may be tempted to make tables as all-encompassing as possible by giving columns very large data types or piling on extra fields for convenience. While this seems harmless in the short term, it can lead to heavier storage requirements, slower queries, and frequent obstacles when updating the schema. Narrower tables, carefully chosen data types, and a normalized design often work together to keep a database agile and efficient.
Using TRUNCATE TABLE with Table Partitions in SQL Server
In SQL Server, the TRUNCATE TABLE command is often favored over DELETE for its efficiency when removing data from a table. However, when working with partitioned tables, the locking behavior changes slightly. Additionally, the LOCK_ESCALATION = AUTO setting can further optimize performance by managing lock escalation at the partition level. We explore how these features interact, providing an in-depth look at locking behavior when truncating partitioned tables and the role of LOCK_ESCALATION = AUTO.
Manually Synchronizing a Lagging Secondary Replica in SQL Server Always On Availability Groups
In high-availability environments, SQL Server Always On Availability Groups (AG) are essential for minimizing downtime and preventing data loss. However, situations can arise where a secondary replica lags behind the primary, disrupting synchronization and risking potential data inconsistencies. This blog provides instructions on how to manually catch up a lagging secondary replica using transaction log backups.
Combining Always On Availability Groups with Peer-to-Peer Replication
Starting with SQL Server 2019 CU13, databases participating in a peer-to-peer replication configuration can now be part of an Always On availability group. This integration is flexible—you are not required to have all members of the replication configuration within an AG. You can mix and match AG and non-AG databases within your replication setup, significantly improving the availability and scalability of your configurations.
Managing SQL Server Database Growth with Files and Filegroups
As SQL Server databases expand over time, managing their growth becomes an important task. If not handled properly, this growth can lead to performance issues and maintenance headaches. One effective way to manage database growth is by using filegroups and data files thoughtfully. With proper planning, you can distribute your data across different storage devices, enhance performance, and keep your database scalable.