When working with Azure SQL Database, you’re operating on a fully managed SQL Server engine that is continually updated behind the scenes. While Microsoft manages the infrastructure, there are still settings and metadata you control that directly affect how your database behaves and how your applications interact with it. We tell you all about it in this blog post.
Author: Jon Russell
Understanding “CU + GDR” in SQL Server Servicing: What It Really Means
SQL Server administrators often encounter Microsoft updates labeled as “CU + GDR”, and understandably, this can cause confusion — especially when trying to stay on a consistent CU-based servicing path. This post clarifies what “CU + GDR” really means and why it’s not something to worry about.
SQL Server Permissions and Ownership Chaining
This post demonstrates how to secure reporting views in SQL Server by combining schema‑level permissions with ownership chaining. You’ll create separate schemas for HR data and reporting, define a role and user, then grant and deny the appropriate permissions. The walkthrough shows how a broken ownership chain leads to permission errors and how to realign schema ownership to restore access. It includes scripts for setup, testing via EXECUTE AS, metadata inspection, and clean‑up. By the end, you’ll understand how to expose safe views while protecting sensitive base tables under the least‑privilege model.
Troubleshooting SQL Server Permissions
Understanding and troubleshooting SQL Server permissions can be challenging, especially when direct grants, role inheritance, ownership chains, and explicit denies all interact. The six scenarios that follow show how the engine decides who can do what, then demonstrate the diagnostic steps that reveal why it made that decision. Each section provides a setup script you can run in a dedicated test database, followed by a diagnostic query and a short explanation of the result.
Avoiding the Halloween Problem in SQL Server with Safer UPDATE Patterns
The Halloween Problem can silently degrade SQL Server performance by causing rows to be updated multiple times in a single statement. This post explains how SQL Server’s internal table spool (eager spool) protects against it—and why that can hurt your workload under heavy load. You’ll learn two simple patterns—using CTEs or temp tables—to materialize target rows before the update, eliminating the need for spooky spools. Finally, we cover how batch updates help control locking, reduce escalation risk, and improve concurrency.
Index Maintenance on Your SQL Server VLDBs
Most database administrators are comfortable with the daily tasks of backup, CHECKDB, index maintenance, and statistics updates. The available guidance for those topics is extensive. Much less has been written about caring for estates that contain hundreds of databases—or a single database large enough to strain conventional maintenance windows. This post will focus on options that help when individual tables or complete databases grow beyond the point where “standard” maintenance jobs finish in a reasonable time.
Optimizing SQL Server with Indirect Checkpoints and Target Recovery Time
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.