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.
Category: Internals
Understanding the “mssqlsystemresource” (Resource) Database in SQL Server
This blog post explores the critical role of the hidden mssqlsystemresource database in SQL Server. It explains how this read-only database stores essential system object definitions and simplifies patch management and upgrades. DBAs will gain valuable insights on best practices, versioning, and troubleshooting to keep their SQL Server environment secure and efficient.
Understanding and Managing the Model, MSDB, and Master Databases in SQL Server
It’s easy to focus on user databases and overlook the system databases at the core of every SQL Server instance. However, the master, msdb, and model databases form the backbone of your environment. Understanding each database’s specific responsibilities, how to safely customize them, and how to protect them from data loss or corruption is important for maintaining a stable server. In this post we take a look at all three databases to better understand their purposes and proper maintenance.
Comparative Analysis: SQL Server on Linux vs. Windows for Production
For years, SQL Server was synonymous with the Windows operating system, a pairing that brought deep integration and mature ecosystem support. The arrival of SQL Server on Linux introduced a broader choice, allowing organizations to deploy Microsoft’s flagship relational database on an entirely different platform. Although both versions share the same core engine, technical differences persist in the way each handles process scheduling, I/O, security, and administration.
SQL Server 2019 and the Memory Grant
When SQL Server runs a query, it needs memory for operations like sorting and joining data. It also relies on memory during query compilation to hold intermediate plans while the Query Optimizer finds the best execution strategy. In parallel processing scenarios, the memory requirement grows even further. SQL Server manages this by pre-allocating memory for each query through the SQL Server Operating System (SQLOS). This process ensures that no single query can monopolize the server’s memory
Exploring Spinlocks and Latch Contention in SQL Server
High concurrency can expose subtle performance bottlenecks in SQL Server, particularly those stemming from spinlocks and latch contention. Both mechanisms exist to synchronize access to shared data structures, yet they operate differently and require distinct troubleshooting approaches. By recognizing how they work and knowing what causes them to overload a system, DBAs can reduce CPU spikes, timeouts, and overall application slowdowns.
Reading SQL Server’s XML Deadlock Report Captured by the system_health Event
SQL Server includes an Extended Events session called system_health, which runs by default and, among other things, captures information about deadlocks as they occur. When two or more sessions block each other in such a way that no progress can be made (a deadlock), SQL Server chooses one session as the “victim,” rolls back its transaction, and frees resources so other sessions can continue. By reviewing the deadlock report in the system_health session’s XML output, you can see precisely why the deadlock happened and identify which queries or procedures were involved.
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.
Handling Compatibility Level Changes During SQL Server Upgrades
Compatibility levels determine how certain features of SQL Server behave, allowing databases to maintain functionality even as the server itself evolves. However, changing compatibility levels requires careful consideration to balance the benefits of new features against the potential risks of disrupting existing applications. This blog explores the importance of handling compatibility level changes thoughtfully during SQL Server upgrades, highlighting the risks of making changes too hastily and the advantages of adopting new compatibility levels within a reasonable timeframe.
Leveraging SQL Server 2019’s Last Known Actual Query Plan for Troubleshooting
Troubleshooting production performance issues is often challenging because detailed query execution data can vanish before you realize there’s a problem. Many times, you end up piecing together incomplete clues from runtime statistics or the plan cache. Fortunately, SQL Server 2019 introduced a powerful feature to address this pain point: the Last Known Actual Query Plan.