Many environments use scheduled jobs that evaluate index fragmentation, reorganize indexes above a certain threshold, and rebuild those with higher fragmentation levels. The original administrator may have introduced the configuration during deployment, adopted it from a maintenance framework, or inherited it from an earlier setup. Over time, these jobs become part of the regular operational routine. Unless they cause noticeable problems, administrators may see little reason to revisit them.

There is nothing inherently wrong with this approach. Index fragmentation can affect query performance, and reorganizing or rebuilding indexes can improve their physical structure. For certain workloads, these operations provide measurable benefits. However, an effective SQL Server index maintenance strategy needs to consider more than fragmentation percentages. An index can be heavily fragmented without causing noticeable performance problems, while another index with relatively low fragmentation may consume more resources than necessary because of poor page density.

Maintenance operations also consume resources themselves. Rebuilding large indexes generates transaction log activity, uses CPU and storage I/O, and can interfere with application workloads if maintenance windows are insufficient or poorly planned. In environments with multiple databases or demanding workloads, the cumulative impact of these operations can become an operational concern, even when individual maintenance jobs complete without errors.

With Automatic Index Compaction in Azure SQL, Microsoft has introduced another mechanism for maintaining index page density. The feature works incrementally in the background, potentially reducing the need for some traditional maintenance operations. While its capabilities are limited to supported Azure SQL platforms, the underlying approach raises a broader question: Does an established maintenance strategy still reflect the actual requirements of the workload, or are we continuing practices simply because they have worked well enough in the past?

Why traditional index maintenance deserves another look

For many DBAs, index fragmentation has long been a familiar indicator of index health. Maintenance frameworks commonly use fragmentation percentages to determine whether an index should be reorganized or rebuilt. This approach is understandable. It provides measurable conditions, predictable execution, and a straightforward way to automate recurring maintenance. After configuration, the process needs relatively little administrative involvement. That matters in environments with many databases and limited operational resources.

The difficulty is that fragmentation alone tells us relatively little about whether an index is affecting query performance. Consider two indexes with similar fragmentation levels. One supports reporting queries that regularly perform large range scans, while the other is primarily accessed through selective index seeks that retrieve only a few pages. Both indexes may report similar fragmentation percentages, yet the workloads can experience very different effects. Logical fragmentation is generally more relevant when SQL Server reads substantial ranges of index pages, especially where sequential I/O characteristics matter. For selective lookups involving relatively few pages, the same fragmentation level may have little practical impact.

Storage characteristics influence this relationship as well. A workload on traditional storage may behave differently from one on modern SSD-based infrastructure. However, storage technology alone does not determine whether fragmentation matters. Access patterns, the number of pages involved, caching behavior, and the underlying I/O subsystem all contribute to the actual performance impact. A SQL Server index maintenance strategy based only on the same fragmentation threshold for both indexes overlooks important differences in how the workload uses them.

The maintenance operation itself also deserves attention. An index rebuild can consume significant CPU, memory, transaction log capacity, and storage I/O. The SQL Server edition, operation options, database size, and available maintenance window influence how much the rebuild affects concurrent applications. In environments using Availability Groups, the additional transaction log activity can increase the amount of data that needs to be transported and processed on secondary replicas. Under sufficient load, this may contribute to send or redo backlogs. Secondary replicas may then need more time to catch up.

None of these considerations makes index rebuilding inherently unsuitable. Some workloads benefit significantly from it, and scheduled maintenance remains a practical way to address certain index-related problems. However, the expected performance improvement should justify the resources consumed and the potential operational impact. A maintenance job completing successfully tells us that the operation worked as configured, but it does not necessarily tell us whether the operation was needed or whether the workload benefited from it.

Page density and its impact on SQL Server performance

Traditional index maintenance discussions often concentrate on logical fragmentation, which describes the extent to which leaf-level index pages follow their logical key order. Another characteristic deserves at least as much attention: page density.

Page density describes how much of the available space within database pages is occupied by data. When page density decreases, SQL Server needs more pages to store the same information. This affects more than the physical size of an index. A larger index may require additional pages to be read during query execution, increasing I/O activity. It also occupies more space in the buffer pool, potentially reducing the amount of other useful data that can remain cached in memory. Lower page density can also influence query optimization because it changes the estimated cost of accessing data.

For example, imagine an index that supports frequently executed reporting queries. If page density declines significantly, the same range of data may occupy considerably more pages than before. SQL Server must read and process those additional pages, even if logical fragmentation remains relatively low. Reorganizing or rebuilding the index may improve performance by increasing page density, allowing the same queries to access fewer pages. In such a case, the improvement comes primarily from reducing the amount of data that needs to be processed rather than simply restoring the logical ordering of index pages.

However, maximizing page density is not always the appropriate objective. Indexes that experience frequent inserts or updates within existing key ranges can suffer from page splits when pages have insufficient free space. For some workloads, a reduced fill factor can help limit those splits by reserving space for future modifications. That decision involves a tradeoff. Reserving free space also increases the number of pages needed to store the data, potentially increasing memory consumption and I/O. A fill factor that benefits one index may therefore be inappropriate for another, particularly when their modification patterns differ significantly.

The same principle applies to maintenance thresholds based solely on fragmentation percentages. Page density, fragmentation, page splits, and query access patterns describe different aspects of index behavior, and their relevance depends on the workload. Looking at these characteristics together provides a more useful basis for maintenance decisions than treating any single measurement as a universal indicator of index health.

How Automatic Index Compaction changes Azure SQL index maintenance

Automatic Index Compaction introduces a different approach to maintaining page density. Instead of periodically reorganizing or rebuilding an entire index, the database engine can consolidate eligible index pages incrementally in the background as data changes. The feature works with persistent version store cleanup. The engine can redistribute rows between eligible pages and release pages it no longer needs.

This can improve page density and reduce the number of pages needed to store the same data. Depending on the workload, the resulting smaller index footprint may also reduce storage I/O and buffer pool consumption. Unlike a traditional index rebuild, automatic compaction does not process every index page in a single maintenance operation. This incremental approach can help databases with continuous write activity. Large scheduled maintenance operations may otherwise compete with production workloads for resources.

However, its scope is deliberately limited. As of November 2026, Automatic Index Compaction is available for Azure SQL Database, Azure SQL Managed Instance with the Always-up-to-date update policy, and SQL database in Microsoft Fabric. It is not generally available for traditional SQL Server installations. The feature is also off by default. Administrators must enable it at the database level before an existing environment can benefit from it.

Technically, automatic compaction operates on eligible leaf-level B-tree pages within IN_ROW_DATA allocation units. It does not provide equivalent maintenance for heaps, LOB data, columnstore indexes, or memory-optimized tables. It also does not rebuild indexes or update index statistics. Logical fragmentation is not its primary maintenance objective and may even increase while page density improves. That distinction is important because a higher fragmentation percentage after compaction does not automatically indicate that index performance has deteriorated. If the index occupies fewer pages, the resulting reduction in I/O and memory requirements may outweigh the effects of additional fragmentation.

There is another limitation when introducing the feature into an existing environment. Automatic compaction processes eligible pages that change while the feature is enabled. It therefore does not immediately correct historical page density problems across an entire index. An index that has accumulated substantial unused space over several years may therefore still benefit from an initial reorganization or rebuild. Automatic compaction can subsequently help maintain page density as further modifications occur.

For supported Azure SQL environments, this creates an opportunity to reduce certain recurring maintenance operations, particularly where their primary purpose is to improve page density. Whether administrators can remove those operations depends on their current purpose and on the maintenance requirements that remain. Automatic compaction addresses a specific part of index maintenance, and its benefits should be evaluated in that context.

Why statistics complicate the evaluation of index rebuilds

There is another aspect of traditional index maintenance that can make its actual benefits difficult to assess. When query performance improves after an index rebuild, teams often credit reduced fragmentation or better page density. That may be the correct explanation, but rebuilding a rowstore index also updates its associated index statistics. A conventional, nonpartitioned, nonresumable rebuild generally refreshes those statistics using a full index scan.

Updated statistics can influence cardinality estimates and query optimization. If earlier statistics no longer reflect the underlying data, SQL Server may generate a different execution plan after the rebuild. This means that a noticeable performance improvement following index maintenance does not necessarily prove that fragmentation was responsible for the original problem.

Consider an application where certain queries consistently perform better following a scheduled index maintenance job. At first glance, this seems to confirm that rebuilding the indexes is necessary. However, if the improvement primarily results from refreshed statistics, the same workload might benefit from a targeted statistics update without the additional cost of rebuilding the entire index. The distinction matters because the appropriate maintenance operation depends on what actually caused the improvement.

An improvement after maintenance alone does not reliably establish its cause. The investigation must consider execution plans, statistics changes, query performance history, and workload characteristics together. As discussed in SQL Server Query Store: Why Performance History Matters, Query Store can help examine plan changes and the development of query performance over time. Even then, the team should interpret the evidence carefully, especially if workload or configuration changes occurred in the same period.

This becomes even more relevant when evaluating Automatic Index Compaction. Because automatic compaction does not update statistics, replacing existing index rebuild jobs without reviewing the statistics maintenance strategy could unintentionally remove a beneficial side effect of those jobs. One possible response is to separate index structure maintenance from statistics maintenance. Each activity can then address its actual purpose. For some environments, that change alone could make maintenance more predictable and reduce unnecessary resource consumption.

When should SQL Server indexes be rebuilt or reorganized?

Automatic Index Compaction does not make index rebuilds and reorganizations obsolete. There are legitimate situations where a targeted maintenance operation remains useful, including in Azure SQL environments where automatic compaction is available. An index with historically low page density may require an initial corrective operation, while other indexes may benefit from reduced logical fragmentation. This is particularly relevant when workloads perform substantial range scans and the storage characteristics make fragmented access more expensive.

A rebuild may also be appropriate when changing the fill factor or performing a specific structural maintenance operation. Index types and allocation units outside the scope of automatic compaction may require separate consideration, especially where their maintenance requirements differ from those of traditional rowstore indexes. These examples do not establish a universal schedule. They show why the index structure, its workload, and the expected benefit should guide each maintenance decision.

The same principle applies to traditional SQL Server installations, where Automatic Index Compaction is currently unavailable. In those environments, scheduled maintenance jobs remain a practical way to perform index maintenance. However, their configuration should still reflect the database workload rather than relying exclusively on thresholds that may have been established years earlier. An index with high fragmentation is not necessarily a candidate for rebuilding, just as an index with low fragmentation is not necessarily operating efficiently.

The SQL Server index maintenance strategy should identify when maintenance provides a meaningful benefit and which operation addresses that need. That may mean rebuilding an index, reorganizing it, updating statistics, or deliberately leaving the index unchanged. Each of these decisions can be appropriate, provided the underlying reason is understood.

Developing a workload-aware SQL Server index maintenance strategy

A modern SQL Server index maintenance strategy should reflect what the database workload actually requires. That does not mean abandoning automation or replacing predictable maintenance processes with manual decisions. Automation remains essential for operating larger SQL Server environments consistently, but the rules behind that automation deserve the same attention as the maintenance operations themselves.

Before changing a maintenance configuration, identify the indexes that support important queries. Then examine the problems the jobs aim to address and whether workload measurements demonstrate an actual benefit. For example, an index used by a business-critical reporting workload may justify a different maintenance approach from an index that receives relatively little read activity. Similarly, an index experiencing frequent page splits may require a different intervention from one suffering primarily from low page density.

These distinctions become particularly important when maintenance jobs consume substantial resources or extend beyond their intended execution windows. A rebuild that improves query response times may justify its cost, while another rebuild that produces no measurable benefit may be an unnecessary source of CPU, I/O, and transaction log activity. Where possible, Query Store, execution plans, storage metrics, and representative workload measurements should provide evidence of these effects. The same distinction between metrics and causes also underpins SQL Server Bottleneck Triage: How to Separate Signals from Causes. Before-and-after measurements can help, but the comparison must account for workload changes, caching, and other influences.

It is equally important to consider the database platform. An organization operating traditional SQL Server installations alongside Azure SQL Database may have several available maintenance mechanisms. Applying identical maintenance jobs everywhere can simplify administration, but the resulting operations may not be appropriate for every environment. Automatic Index Compaction provides an additional option for supported Azure SQL databases because it can help maintain page density continuously, potentially reducing the need for certain scheduled operations. Other maintenance activities, particularly those involving statistics or index structures outside its scope, may still be necessary.

The aim should be consistent evaluation criteria across the database estate, while allowing the actual maintenance operations to reflect the capabilities and requirements of each platform. A consistent strategy does not require every database to perform identical maintenance activities. It requires a shared understanding of why the activities matter and how the team will assess their effectiveness.

Reviewing your SQL Server index maintenance strategy

Automatic Index Compaction is an interesting development because it addresses a familiar database maintenance problem through a different mechanism. Its introduction offers an opportunity to review established practices, particularly where teams have retained the same jobs across several SQL Server versions.

For an existing SQL Server environment, the current configuration provides a useful starting point for reviewing the SQL Server index maintenance strategy. Which indexes are being rebuilt or reorganized regularly? How much CPU, I/O, and transaction log activity do these operations generate? Are they affecting production workloads or high availability components? And, perhaps most importantly, is there evidence that they improve the performance of the queries using those indexes?

Answering these questions can reveal opportunities to reduce unnecessary maintenance without compromising production stability. Some operations will remain justified because their benefits are measurable and their operational costs are acceptable. Others may benefit from more selective conditions, a different execution schedule, or a clearer separation between index structure maintenance and statistics updates. When no one has documented the original maintenance decisions, this review can also establish a more reliable basis for future changes.

For supported Azure SQL environments, Automatic Index Compaction adds another possibility to that evaluation. However, enabling the feature should be part of an informed maintenance decision rather than an assumption that existing jobs can simply be removed. Before changing established processes, teams should understand its effects on page density, resource consumption, and remaining maintenance requirements.

A well-designed maintenance strategy does not need to achieve the lowest possible fragmentation percentage or rebuild every index on a predictable schedule. It needs to support the performance and operational requirements of the database environment while avoiding work that provides little measurable benefit. As workloads, SQL Server versions, and platform capabilities evolve, the team should review the SQL Server index maintenance strategy accordingly.

The important question is no longer simply whether the maintenance jobs complete successfully, but whether they still perform work that the database actually needs.

Technical references

• Microsoft Learn: Automatic Index Compaction
• Microsoft Learn: Optimize Index Maintenance to Improve Query Performance and Reduce Resource Consumption
• Microsoft Learn: Query Store

Foto von Danil Shostak auf Unsplash

The post Rethinking SQL Server Index Maintenance: What Automatic Index Compaction Changes appeared first on CraftedSQL.

In such situations, the delay may have little to do with query execution. Before an application can submit its first query, the database driver needs to establish physical connections, which involves network communication, authentication and session initialization.

Microsoft introduced the new implementation with Microsoft.Data.SqlClient 7.1. It lets the driver establish multiple physical database connections concurrently.

Initial benchmarks show a substantial improvement during connection pool initialization. That is particularly interesting for applications that scale dynamically or frequently start new processes and containers. However, an improvement in the database driver also deserves a closer look from the infrastructure side.

If applications can establish connections considerably faster, what does that mean for the SQL Server receiving those connections?

What SqlClient Connection Pool V2 Actually Changes

Connection pooling has been part of SQL Server application connectivity for many years. Instead of establishing a new physical connection for every database operation, the driver maintains a pool of connections that applications can reuse.

This avoids repeatedly paying the overhead associated with connection establishment and authentication. For applications that open and close logical connections frequently, pooling can make a considerable difference. Microsoft explains the underlying behavior in its SQL Server connection pooling documentation.

The situation changes when an application needs more connections than its existing pool can provide. This can happen after a restart, during application initialization or when additional application instances start to handle increasing demand.

With the legacy Microsoft.Data.SqlClient implementation, an individual pool establishes new physical connections sequentially. Even if several application components request connections concurrently, the pool creates only one new physical connection at a time. As a result, connection establishment itself can become a limiting factor.

Connection Pool V2 addresses this limitation through a different internal implementation that supports concurrent physical connection establishment. It also introduces a channel-based design intended to improve how the driver handles concurrent and asynchronous connection requests.

The existing connection-string settings continue to apply, and applications do not need to change their database-access logic to use the new implementation.

There is, however, an important distinction between creating connections and executing database operations. Connection Pool V2 changes how the client manages physical connections. It does not change the SQL Server query optimizer, improve execution plans or make individual SQL statements execute faster.

An application that spends significant time establishing new connections may benefit considerably. An application that already reuses established connections efficiently may see little difference.

Understanding the 6.6x Performance Improvement

Microsoft’s original announcement of Connection Pool V2 includes benchmark results that demonstrate why the new implementation is attracting attention.

In an asynchronous cold-start scenario involving 100 concurrent connection requests on Linux, the reported mean execution time decreased from 604.1 milliseconds with the legacy pool to 92.0 milliseconds with Connection Pool V2.

That represents approximately a 6.6x improvement in the measured operation.

The result is impressive, particularly because teams often treat connection establishment as a relatively minor part of database performance. Yet the conditions of the benchmark are just as important as the resulting numbers.

The test measured the time needed to establish a group of physical connections during a cold start. It did not measure SQL query execution times or the performance of an application continuously reusing an established pool.

Microsoft also ran the benchmark application and SQL Server on the same machine, minimizing network-related variability. In production, the database server may run on a different host, in another network segment or behind additional infrastructure components. Authentication methods, network latency and resource availability can further influence the outcome.

These differences do not invalidate the benchmark. They simply define what its results demonstrate and where additional testing becomes necessary.

For an application that frequently initializes new connection pools, the improvement may be highly relevant. For an application server maintaining relatively stable connection pools throughout the day, the practical benefit could be considerably smaller.

The useful question is therefore not whether SqlClient Connection Pool V2 is faster in the published benchmark. Microsoft has demonstrated that it is. The question is whether physical connection establishment represents a meaningful limitation in the application environment under review.

Faster Connections and Their Impact on SQL Server

From a SQL Server operations perspective, the interesting part begins when we consider how applications use connection pools in larger environments.

A connection pool belongs to an application process. It is not a shared pool that automatically serves every application server, container or service instance.

Imagine an application running across several containers. Each container maintains its own database connections, and a deployment or scaling event may cause several containers to initialize their connection pools within a short period.

With the legacy implementation, each pool establishes new physical connections sequentially. Connection Pool V2 allows those pools to grow more quickly by establishing multiple connections concurrently.

For the application, this can reduce the time required to become fully operational. On the SQL Server side, however, it may change the arrival pattern of new connection requests.

Instead of receiving those connections over a more extended period, SQL Server could experience a more concentrated burst of login and session initialization activity, particularly when many application instances start simultaneously.

That does not automatically create a performance problem. A properly sized SQL Server environment may handle the additional concurrency without noticeable difficulty. In some situations, completing connection establishment sooner could even reduce the time during which startup-related activity affects the overall workload.

Nevertheless, the behavior deserves attention because database connectivity consumes resources on both sides of the connection.

Authentication, session initialization and the resources associated with established connections remain relevant, regardless of how efficiently the client manages its connection pool.

This becomes especially interesting in environments where multiple applications share the same SQL Server instance or where application scaling can happen independently of database capacity.

Connection Pool Limits Still Matter

Connection Pool V2 does not remove the need to understand connection pool sizing and configuration.

Settings such as Min Pool Size and Max Pool Size continue to influence how the driver maintains connections and how many physical connections an individual pool can establish.

The important detail is that these limits apply to individual pools rather than to an entire distributed application.

For example, an application running across multiple processes or containers can maintain several independent pools. Different connection strings and certain differences in authentication context may create additional pools.

Consequently, the total potential number of physical database connections can be considerably higher than the Max Pool Size configured for an individual pool.

Connection Pool V2 does not inherently increase those limits. Instead, it changes how quickly the driver can establish physical connections within them.

In environments where application scaling already approaches database connection or resource limits, this distinction becomes operationally relevant. Creating connections faster does not increase the database server’s underlying capacity.

Where Connection Pool V2 Will Not Help

Not every delay involving database connections stems from slow physical connection establishment.

An application may spend time waiting because all available pooled connections are already in use. Connections can remain occupied by long-running operations, open transactions or application code that does not release them promptly.

Under those circumstances, creating new physical connections more efficiently may provide little benefit once the application reaches the configured pool limit.

Similarly, an application suffering from blocking, inefficient execution plans or excessive resource consumption will not resolve those problems by changing its connection pool implementation.

This distinction is important during troubleshooting because application errors and timeouts do not always identify the underlying cause.

A connection timeout may originate while establishing a physical connection or while waiting for a connection to become available. A command timeout, on the other hand, concerns an operation submitted to SQL Server. Those situations require different diagnostic approaches.

Understanding where the delay actually occurs is therefore more useful than immediately adjusting connection pool settings.

Teams should evaluate application-side connection timings alongside SQL Server evidence such as session activity, resource utilization, wait statistics and the behavior of the affected workload.

This is also a familiar principle in SQL Server bottleneck triage. The visible symptom provides a starting point, but a reliable diagnosis depends on understanding what happens throughout the affected operation.

Evaluating Connection Pool V2 Before Production

Microsoft introduced SqlClient Connection Pool V2 with Microsoft.Data.SqlClient 7.1.0. It remains opt-in throughout the 7.x series, with the legacy pool still enabled by default.

As of November 2026, version 7.1.1 is the latest documented 7.1 release. It fixes an issue involving expired access tokens when reusing connections with Pool V2, making the exact driver version relevant during testing. Microsoft documents the fix in the Microsoft.Data.SqlClient release notes.

Applications can enable the new implementation through an AppContext switch:

AppContext.SetSwitch(
    "Switch.Microsoft.Data.SqlClient.UseConnectionPoolV2",
    true);

Applications must set the switch during startup, before SqlClient initializes and caches the relevant configuration. Microsoft explains this behavior in its AppContext switches documentation.

The configuration change is small, but its effects deserve a broader evaluation.

Start by measuring the application with its existing pool. Record startup times, connection establishment latency and the number of physical connections created.

Then evaluate the same workload with Connection Pool V2 enabled under conditions that reflect the deployment architecture.

For dynamically scaled applications, this means looking beyond a single process. A coordinated restart of multiple instances may expose different behavior from a test involving just one application instance.

DBAs should also monitor SQL Server during these tests. Login activity, session counts and resource utilization help assess whether the improvement benefits the overall environment.

Network conditions also deserve consideration. Microsoft notes that OpenAsync() does not yet perform every underlying network operation asynchronously. Under higher network latency, concurrent connection establishment may therefore place additional pressure on managed thread-pool resources.

This limitation does not negate the benefits of Pool V2, but it illustrates why a benchmark performed under low-latency conditions cannot represent every production environment.

Recovery and Failover Scenarios Deserve Attention

Another useful test involves application recovery after a temporary loss of database connectivity.

Following a SQL Server failover, network interruption or database service restart, multiple application instances may attempt to reconnect within a short period. Depending on the application’s retry behavior and the state of its connection pools, this can produce concentrated connection activity.

Connection Pool V2 changes how the driver establishes new physical connections, but it does not define the application’s entire recovery behavior.

Retry policies, connection timeouts, authentication and the handling of failed connections remain important. The interaction between these components should be understood rather than assuming that faster connection establishment automatically improves service recovery.

For business-critical applications, the relevant assessment includes both how quickly the application reconnects and whether the resulting workload remains manageable for SQL Server.

An evaluation should therefore cover normal startup, representative peak demand and recovery scenarios where connection pools need to establish new physical connections.

Because SqlClient selects the pool implementation when it creates the first pool, meaningful A/B testing requires separate application processes with the appropriate configuration.

Returning to the legacy implementation is straightforward: disable the switch and restart the application. Having that rollback option documented is useful, particularly while Pool V2 remains an opt-in feature.

A Useful Improvement That Needs the Right Context

SqlClient Connection Pool V2 addresses a genuine limitation in the legacy Microsoft.Data.SqlClient implementation. Applications that frequently need to establish many physical database connections may benefit significantly from the ability to create them concurrently.

The published benchmark provides encouraging evidence, and the implementation offers a relatively accessible way to evaluate the improvement without redesigning application database access.

At the same time, connection management is part of the relationship between an application and its database infrastructure. Improving one part of that relationship can change how workloads arrive at SQL Server, even when the database engine itself remains unchanged.

For an application with stable connection pools and predictable demand, adopting Pool V2 may have little immediate operational impact. In an environment with frequent container starts, dynamic scaling or periods of concentrated connection activity, the benefits and potential side effects deserve closer examination.

Neither situation makes the new implementation inherently right or wrong. The decision depends on whether connection establishment currently limits application responsiveness and whether the surrounding infrastructure can support the resulting behavior.

That is also why evaluating changes like this should not be left exclusively to application developers or database administrators. Both perspectives contribute information that the other side may not have.

Application teams understand startup behavior, connection usage and scaling patterns. SQL Server administrators can assess how those patterns interact with database resources, existing workloads and operational limits.

When those observations are brought together, the question becomes much more practical:

Will Connection Pool V2 improve the application’s real operating conditions without introducing new bottlenecks elsewhere in the environment?

That is the level at which a promising technical improvement becomes a sound production decision.

Foto von Patrick Federi auf Unsplash

The post SqlClient Connection Pool V2: Faster Connections, New Questions for SQL Server Operations appeared first on CraftedSQL.

Consider a laboratory information system that suddenly becomes unavailable. Staff may still collect and analyse samples, but the normal electronic workflow for processing, validating and delivering results comes to a halt. Depending on the hospital’s contingency procedures and the affected systems, this can delay clinical decisions and disrupt emergency department operations. In more severe situations, the hospital may need to restrict parts of its clinical workflow until the required information becomes available again.

The underlying cause might be a failed SQL Server instance, an unsuccessful cluster failover or an inaccessible infrastructure component. To medical staff waiting for laboratory results, however, the technical distinction between these failures has little immediate relevance. What matters is whether the application remains available and how quickly the hospital can restore its functionality.

Similar dependencies exist in other areas of critical infrastructure. Energy providers rely on information systems to support operational processes and coordinate technical activities. Water utilities use digital infrastructure to monitor and manage essential processes. Transportation operators depend on applications that coordinate schedules, resources and operational information. Emergency services and public administrations also operate systems whose failure can affect services that people depend on.

Naturally, the consequences differ considerably between these environments. Even within the same organization, a database supporting internal reporting does not necessarily require the same availability as one involved in operational control or clinical diagnostics. The criticality of a database depends on the service it supports and the consequences of an interruption.

For SQL Server high availability, this changes the starting point of an architectural discussion. Before selecting a technology to protect a database, the organization needs to understand what an interruption would mean for the processes that depend on it.

High Availability in Critical Infrastructure Begins With the Service

Critical infrastructure is more than a convenient label for systems that an organization considers important. In Europe, frameworks such as the NIS2 Directive and the Critical Entities Resilience Directive (CER) address security and resilience across essential sectors. These include healthcare, energy, transportation, drinking water and digital infrastructure.

These frameworks establish a broader context for organizational resilience. However, they do not determine which SQL Server high-availability architecture best suits an individual application. That decision requires a closer examination of the service, its dependencies and the operational requirements that follow from them.

A hospital, for example, may operate numerous SQL Server instances supporting clinical applications, administrative systems, reporting platforms and infrastructure services. Some workloads can tolerate an interruption of several hours, provided that recovery remains predictable and data loss stays within acceptable limits. Others require much shorter recovery times because even a temporary loss of functionality affects clinical workflows.

The architecture needs to account for those differences. Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) help translate operational requirements into measurable expectations. They describe how quickly a service needs to recover and how much data loss the organization can tolerate. However, these objectives are useful only when the technical design, supporting infrastructure and operating procedures can realistically meet them.

For a laboratory information system, that assessment must extend beyond the SQL Server instance. The application may depend on several databases, application servers, interfaces to laboratory equipment and connections to other hospital systems. Restoring a database or bringing a cluster resource online may be necessary, but neither action automatically restores the complete workflow.

This distinction matters when evaluating an existing architecture. A system can meet its technical availability objectives at the database level while the operational service still fails to meet its requirements. The database may be running correctly, yet the application cannot perform the functions its users need.

When a Successful Failover Does Not Restore the Service

SQL Server provides established high-availability technologies for different failure scenarios. Always On Availability Groups protect databases through replicas on separate SQL Server instances. Failover Cluster Instances provide instance-level availability through Windows Server Failover Clustering. Virtualization platforms, resilient storage and redundant network components can add protection at other infrastructure layers. Microsoft describes these mechanisms in its documentation on SQL Server business continuity and database recovery.

These technologies have legitimate and well-established uses. Problems arise when their presence becomes the primary evidence that an application is highly available.

Consider a SQL Server Failover Cluster Instance supporting a clinical application. During an incident, a cluster node becomes unavailable. The cluster then brings the SQL Server resources online on another node. From the cluster’s perspective, the transition may have succeeded. SQL Server starts, the databases recover and the instance becomes accessible again.

The application, however, may not immediately resume normal operation. Existing connections have been interrupted, application services may need to reconnect and some components may require additional recovery steps. If other services have also failed, restoring SQL Server alone may leave important functionality unavailable. Microsoft describes related considerations for client connections during Availability Group failover. During such a transition, existing connections terminate and applications must establish new ones.

The situation becomes more difficult when different teams assess recovery from their own technical perspective. The infrastructure team confirms that the cluster is operational, while the database administrator verifies that SQL Server accepts connections. Meanwhile, application administrators may still be investigating why users cannot complete transactions or why an interface has stopped processing information.

All these observations can be correct, although they describe different stages of recovery.

In a hospital laboratory, the consequences are easy to understand. A successfully recovered database provides little immediate benefit to clinical staff if laboratory results still cannot reach the applications where they are needed. The database remains an essential part of the process, but its availability is only one condition for restoring the service.

This does not mean the underlying high-availability technology has failed or that the architecture is unsuitable. Instead, the organization needs to distinguish between recovering an individual component and restoring the application or service. That distinction should also influence how teams test and document availability.

A planned failover can demonstrate that SQL Server resources move between nodes under controlled conditions. It also gives administrators an opportunity to observe application reconnection and recovery behaviour. Yet a successful planned transition does not prove that the environment will behave identically during an unexpected failure. A node might lose network connectivity, storage could become unavailable or several infrastructure components might fail together.

Windows Server Failover Clustering uses mechanisms such as cluster membership, quorum, resource dependencies and health monitoring. SQL Server adds database recovery and service-specific behaviour. The underlying network, storage and virtualization platforms introduce further dependencies, and their interaction determines what happens during a particular failure.

A meaningful test should therefore cover the complete recovery path. How does the cluster react to the failure? When does SQL Server become accessible again? Do applications reconnect as expected, and can users resume their work? Most importantly, does the service recover within the limits the organization considers acceptable?

Without those observations, an architecture may appear highly available on paper while important aspects of its actual recovery behaviour remain unknown.

High Availability Must Also Support Normal Operations

Unexpected failures are only part of the challenge. Even a well-designed SQL Server environment requires regular maintenance. Operating system updates, SQL Server patches and changes to supporting infrastructure all form part of normal operations. In critical environments, administrators need to plan these activities with the same attention to service continuity as an unexpected outage.

A cluster with multiple nodes can simplify maintenance, but it does not automatically make every operation safe or interruption-free.

Before patching a node, administrators need to understand which resources it owns, whether the remaining nodes are healthy and what happens when a workload moves. The expected behaviour also depends on the SQL Server configuration, the application and the supporting infrastructure. Some changes allow limited disruption, while others require coordinated maintenance windows and explicit acceptance of temporary restrictions.

Moving a workload away from a node can simplify maintenance. However, administrators must also verify that the environment has regained its intended level of protection afterward.

For example, a security update may install successfully and the patched node may return to the cluster without errors. Nevertheless, the environment might remain in a degraded state if resources, dependencies or availability configurations have not returned to their intended condition. Completing the patch installation does not necessarily mean the operational task is finished.

In hospital environments, this becomes particularly relevant. Administrators cannot always postpone necessary maintenance simply because the applications are important. Security vulnerabilities, unsupported software and overdue infrastructure changes introduce risks of their own. At the same time, maintenance without a clear understanding of failover behaviour can cause avoidable interruptions.

For that reason, an architecture review should consider patchability before the environment enters production, and revisit it as the infrastructure evolves. Treating maintenance solely as a later operational concern can leave important weaknesses in the design.

A sustainable high-availability design needs a realistic way to maintain its components, recover from expected interruptions and return to a known operating state. If these procedures depend on undocumented knowledge or prove unreliable in practice, the organization may face an operational weakness despite having redundant infrastructure.

Recovery and Responsibility Extend Beyond the Cluster

High availability aims to reduce interruptions caused by particular failures, but no individual mechanism protects against every possible scenario. Some incidents exceed the capabilities of an Availability Group or Failover Cluster Instance. Others require the organization to restore data or application functionality from an earlier state.

A database replica, for instance, does not necessarily protect against logical corruption or an incorrect operation that affects replicated data. Likewise, a functioning cluster cannot compensate for every failure involving shared infrastructure, external dependencies or the wider application environment.

Organizations therefore still need appropriate backup and recovery procedures, even when they have designed their SQL Server infrastructure for high availability. The earlier CraftedSQL article SQL Server Backup Strategy: Why Successful Backups Are Not Enough explains why successful backup jobs alone do not establish recovery readiness.

For critical applications, recovery procedures must account for more than restoring the database. The responsible teams need to know which databases and services belong together, which credentials and access paths recovery requires and how to return the application to an operational state. These dependencies can determine whether a technically successful restore actually helps the organization resume its work.

Incident responsibilities deserve the same attention. Consider an outage affecting a hospital application outside normal working hours. Infrastructure administrators may manage the cluster and supporting systems, while database administrators investigate SQL Server behaviour. Application specialists understand the interfaces needed to restore clinical functionality. Hospital operations must determine whether the service can continue with temporary procedures or whether additional measures are necessary.

Each team contributes important information. However, recovery becomes more difficult when nobody has established how these responsibilities fit together.

Documentation can help, provided that it reflects how the environment actually operates. Network diagrams, instance names and cluster configurations support technical administration, but they do not necessarily explain how to restore application dependencies. Nor do they always establish who makes operational decisions or how teams determine that recovery is complete.

These questions become particularly important when the people who originally designed or implemented the environment are unavailable. An organization should not have to reconstruct essential dependencies for the first time during an incident.

None of this means that organizations must eliminate every dependency or deploy the most elaborate high-availability technology for every critical system. Modern infrastructures inevitably rely on multiple components and specialist teams. Many of those dependencies are reasonable, provided that the organization understands their effect on service continuity and consciously accepts the resulting risks.

The more useful objective is to make those dependencies visible, assess their consequences and verify that recovery procedures work under realistic conditions. That understanding allows teams to prepare for failures without introducing unnecessary complexity into the architecture.

Evaluating SQL Server High Availability From the Service Backwards

An architecture review for critical infrastructure should begin with the operational service rather than the SQL Server technology underneath it.

For a hospital laboratory, this means understanding how laboratory information reaches clinical applications, which processes depend on it and what happens when those processes stop. From there, the assessment can follow the dependencies through application services, database instances, clustering, storage, networking and the supporting infrastructure.

This approach also helps distinguish between different kinds of risk. An untested failover procedure deserves attention when the organization cannot predict how the application will recover. A known dependency on shared storage may be acceptable if the architecture and recovery plan account for its failure. A maintenance procedure that repeatedly leaves the environment without its intended redundancy may indicate an operational problem, even if no unplanned outage has occurred.

The appropriate response depends on the actual requirements and the available evidence. Not every finding requires an architectural redesign, and another layer of redundancy is not automatically the best solution.

A focused SQL Server architecture and operational review can establish whether the configuration supports the required availability objectives. It can also examine how the environment behaves during planned and unplanned transitions, and identify dependencies that may prevent complete service recovery. CraftedSQL addresses these questions through its SQL Server High Availability and Disaster Recovery consulting services.

For organizations operating essential services, this provides a more meaningful basis for technical decisions than selecting a technology simply because people associate it with high availability.

The underlying question remains relatively straightforward: if a critical application becomes unavailable, does the organization understand its dependencies well enough to restore the service within an acceptable timeframe?

That question reaches beyond SQL Server, but database architecture, configuration and operational procedures can strongly influence the answer. The value of high availability becomes visible when teams test the infrastructure under realistic conditions. They also need to understand what must happen when normal operations fail and how to bring the complete service back to an acceptable state.

The post When High Availability Becomes Critical: SQL Server in Essential Infrastructure appeared first on CraftedSQL.

But there is an important difference between demonstrating vector search and deciding which parts of that functionality an application can depend on in production.

SQL Server 2025 includes vector capabilities with different levels of maturity. Some are generally available, while others remain in preview. That distinction affects far more than the syntax used in a demonstration. It influences how teams can update, deploy, maintain, and support an application.

In an earlier article, SQL Server Vector Search: What to Evaluate Before Production, I discussed the wider questions around capacity, performance, security, and operational readiness. Here, I want to focus on a narrower issue: what the current SQL Server 2025 feature boundary means for an actual implementation.

SQL Server 2025: Understanding Vector Feature Maturity

SQL Server 2025 provides a native vector data type and functions for working with vector values. These generally available capabilities allow applications to store embeddings alongside conventional relational data.

However, vector indexes and the VECTOR_SEARCH function remain preview features in SQL Server 2025. To use them, administrators must enable the PREVIEW_FEATURES database-scoped configuration. Microsoft explicitly advises against using preview features in production environments.

The situation differs across Microsoft data platforms. Vector indexes and VECTOR_SEARCH are generally available in Azure SQL Database and certain other supported platforms, including Azure SQL Managed Instance with the Always-up-to-date update policy.

This makes the platform and its update policy part of the technical decision. Two environments may support the same general vector-search concept without offering the same production-ready feature set.

Microsoft documents these differences in the Vector Search and Vector Indexes overview and the SQL Server 2025 release notes.

For an application that only needs native vector storage and exact distance calculations, these distinctions may lead to a different architecture than one requiring approximate nearest-neighbor searches backed by a vector index.

Before evaluating query performance, I would therefore establish which specific capabilities the application depends on and whether their current support status meets the organization’s production requirements.

How Vector Index Versions Affect SQL Server Operations

Imagine an internal document-search application. The first demonstration uses a relatively small collection of documents, each represented by an embedding stored in SQL Server. Users can search for relevant information, and the application retrieves matching document records.

That example becomes more interesting when the document collection starts changing. New documents arrive, existing content changes, and users must sometimes remove records.

At this point, the application must account for how the vector index handles these changes.

Microsoft currently distinguishes between earlier and newer vector index structures. Earlier versions impose significant restrictions on data modification. Tables containing those indexes are read-only unless administrators enable a specific configuration that permits changes while accepting potentially stale vector-search results.

Newer vector index structures introduce automatic index maintenance and support normal data modification operations on supported platforms and configurations. They also improve how traditional predicates interact with approximate vector retrieval.

That is an important development, but it does not mean that every SQL Server 2025 installation automatically has the newer functionality available.

The CREATE VECTOR INDEX documentation describes the version differences, migration requirements, and current limitations. Microsoft also identifies earlier vector index structures as candidates for future retirement.

For production planning, the practical consequence is straightforward: teams must base their design on the index behavior that the selected platform and build actually support. They cannot simply assume that vector indexes behave like conventional SQL Server indexes.

Filtering and Security in SQL Server Vector Search

Now consider that the document collection belongs to several customers. The application must search for semantically relevant content while ensuring that users only receive documents they are authorized to access.

A similarity score cannot establish authorization. The application must apply its existing access rules correctly, regardless of how vector candidates are identified.

Earlier vector index implementations use post-filtering. The search first retrieves approximate candidates, and relational predicates then filter those results. This can affect both the number and relevance of documents that the application returns.

Newer index implementations support a different approach. They consider predicates during the vector search process rather than applying them only afterward. That can improve filtered searches, although the exact behavior still depends on the platform and index version.

This is not simply an optimization detail. In a customer-facing application, authorization must remain correct, while the team needs to assess result completeness and relevance separately.

A search that returns fewer documents than expected may be working exactly as its index implementation allows. Conversely, good similarity scores do not demonstrate that the application enforces the correct security boundary.

I would therefore test filtered vector searches with representative data and actual authorization requirements before accepting the design. Query duration alone tells us little about whether the implementation meets the application’s needs.

Deployment and Recovery Need Their Own Validation

Deploying SQL Server vector search requires more than creating the necessary tables and indexes. Database teams must also verify that their established deployment processes support the selected vector features and their current limitations.

SQL Server teams often rely on schema comparison, DACPAC packages, database provisioning, and automated release pipelines. A new database feature must fit into those processes, or the team must explicitly address its limitations.

Current vector index restrictions include limitations on partitioning, replication to subscribers, and DACPAC deployment. Microsoft also documents minimum data requirements for creating vector indexes.

A schema deployment may succeed without creating the required vector index. In that case, the application can end up in a different operational state from the one its developers expected. Loading additional data afterward does not necessarily correct the missing index automatically.

Consequently, release validation should establish whether the expected index exists and whether the application can actually use the intended search method after deployment.

The same principle applies to recovery. A successful database restore is essential, but it does not demonstrate that every dependent search component is ready for use.

For a vector-search application, a meaningful recovery test should verify the restored data, the expected index configuration, application connectivity, and the ability to retrieve appropriate results. If embeddings depend on external models or services, the recovery assessment must also consider those dependencies.

This follows a broader operational principle discussed in SQL Server Query Store: Why Performance History Matters: teams need reliable operational information when a problem occurs. A successful configuration at some earlier point does not guarantee that the necessary information will still be available.

For vector indexes specifically, teams should check the current Microsoft documentation before building deployment or recovery procedures around particular index capabilities.

Operating Vector Search Workloads

Operating SQL Server vector search introduces responsibilities that extend beyond traditional database administration. Developers may own embedding generation, application logic, and the evaluation of search relevance. Database administrators may manage storage, resource consumption, index availability, database recovery, and infrastructure performance.

Those responsibilities overlap when an application experiences poor search results or unexpected latency.

Suppose the document-search application begins returning fewer relevant results after a data update. SQL Server may show acceptable CPU utilization and no obvious infrastructure errors. The problem could still involve stale embeddings, a change in filtering behavior, an unavailable index, or the application’s retrieval logic.

Investigating that situation requires information from both the application and the database. The team needs to understand which component produced the candidates, which predicates the application applied, and whether the expected index was available.

That is why database health metrics alone cannot demonstrate operational readiness. The application needs a documented way to distinguish technical execution problems from changes in search quality.

This is closely related to the reasoning behind SQL Server Performance: Why Diagnosis Starts with the Problem. The visible symptom is the starting point of an investigation, not sufficient evidence of its cause.

Making a Production Decision

SQL Server 2025 offers useful native capabilities for applications that work with embeddings and relational data. Keeping those workloads together can simplify an architecture, particularly when the application already depends heavily on SQL Server.

However, using the native vector data type is not the same decision as depending on preview vector indexes and approximate search functions.

For a production application, I would want that distinction documented before implementation. The team should know which capabilities are generally available, which remain in preview, what limitations apply to the selected platform, and how updates or future index migrations may affect the application.

Where preview functionality is essential, it may be more appropriate to continue testing, select a platform where the required capabilities are generally available, or reconsider the search architecture. The right choice depends on the workload and the organization’s requirements.

That does not diminish the value of the technology. It makes the decision more precise.

A successful SQL Server vector search demonstration establishes that an approach is technically possible under the conditions tested. Production readiness requires confidence that the team can deploy, operate, maintain, and recover the same approach within the actual constraints of the chosen platform.

Foto von Oleg Kuzmin auf Unsplash

The post Vector Search in Production: Understanding the Limits of SQL Server 2025 appeared first on CraftedSQL.

The monitoring system is not necessarily malfunctioning. It may be collecting exactly the data it was configured to collect. The problem is that those measurements do not always tell the operations team whether the database platform is still behaving as expected.

There is another side to this problem. Some monitoring systems generate so many notifications that administrators become accustomed to seeing the same warnings every day. They acknowledge the alerts, briefly check the affected system and continue working. After a while, certain notifications receive little attention because previous investigations rarely led to any action.

That does not necessarily mean the warnings are irrelevant. It may simply mean that nobody has established whether they still deserve attention.

Both situations raise an important question: Does SQL Server monitoring provide the information needed to make a decision, or does it mainly report that a condition has been detected?

What a monitoring alert actually tells us

SQL Server provides a considerable amount of information about its internal activity and resource consumption. Performance counters, Dynamic Management Views, Query Store, SQL Server Agent and operating system metrics can all contribute to monitoring.

Collecting these measurements is useful. Administrators need to know when available storage becomes limited, backup jobs fail or a server experiences unusual resource consumption. Some conditions require immediate attention, even before application users notice a problem. Microsoft describes how SQL Server Agent can monitor and respond to events, including alerts and associated responses.

However, exceeding a configured threshold does not explain why something happened or whether the condition presents an operational risk.

Consider a SQL Server that regularly reaches high CPU utilization during a scheduled reporting workload. The activity may be expected, understood and compatible with the agreed performance requirements. On another server, a considerably smaller increase in CPU consumption might coincide with a sudden change in query execution times and affect an important application.

The same metric can describe very different situations. If both servers use identical alert thresholds, the monitoring system may generate unnecessary notifications for one while overlooking a relevant change on the other.

Monitoring rules therefore need to account for the workload and operating conditions of the SQL Server they monitor. A threshold remains useful, but its meaning depends on what the server normally does, which applications depend on it and what happens when the condition persists.

Baselines help distinguish normal activity from meaningful changes

A performance baseline provides a reference for evaluating current measurements. Instead of treating each value in isolation, administrators can compare it with behavior observed during comparable periods. Microsoft recommends establishing a SQL Server performance baseline through regular measurements, including periods when no problems occur.

Database activity on a Monday morning, for example, may differ considerably from the workload during an overnight maintenance window. Comparing those periods without considering their purpose can lead to misleading conclusions.

A useful baseline should therefore represent more than an average CPU or memory value. Depending on the environment, it may include query response times, workload patterns, I/O behavior, database growth, backup duration and periods of particularly high activity.

That reference becomes valuable when a SQL Server changes gradually. A report that takes longer every month may never trigger a critical resource alert. Nevertheless, the trend could indicate a developing problem involving data volume, query execution, resource contention or another dependency.

The baseline will not identify the root cause, but it can help determine whether a change deserves investigation.

There is also a limitation worth considering. A baseline describes observed behavior, which is not necessarily acceptable behavior. If an application has suffered from poor performance for months, treating that period as normal could preserve the problem rather than expose it.

Baselines should therefore be evaluated against application requirements and actual operating conditions. Changes in workload, infrastructure or business processes may justify adjusting them, while unresolved performance problems should not quietly become the new standard.

Not every relevant condition requires a historical baseline, however. A failed critical backup or an unavailable production database may require attention regardless of normal CPU or I/O behavior. Monitoring needs to accommodate both types of situations: conditions that matter because they occurred and changes that become relevant because they differ from expected behavior.

An alert needs enough context to support the next decision

Imagine receiving a notification that SQL Server CPU utilization has exceeded a configured threshold.

The message may be accurate, but the administrator still needs to determine whether the condition matters. Is CPU utilization still increasing? How long has the situation lasted? Does it coincide with an expected workload, or has something changed?

A more useful alert would provide at least the affected instance, the time the condition started, its duration and some historical context. If relevant workload information is available, it may help identify which activity contributed to the increased CPU consumption.

That information will not necessarily explain the cause. It does, however, give the administrator a meaningful starting point. Without it, even an accurate alert may require several additional steps before anyone can decide whether further investigation is necessary.

This distinction becomes important when monitoring systems attempt to identify the cause of a problem.

High CPU consumption is a measured condition. Slower application response times are an observable symptom. The underlying cause might involve a changed execution plan, increased workload, additional compilations or something else entirely. This is also why SQL Server bottleneck triage needs to separate signals from causes before the team chooses a corrective action.

Several of these observations may occur at the same time without one necessarily explaining the others. A monitoring system can help establish their timing and relationship, but a root-cause conclusion still requires technical evidence.

The goal is not to include every available metric in an alert. It is to provide enough relevant information for the recipient to understand what happened and decide what to examine next.

Not every warning requires the same response

Some SQL Server conditions justify immediate action. A failed backup job on a critical database, for example, may affect the agreed recovery capability. A storage volume approaching exhaustion can threaten database operations when data or transaction log files need additional space.

Other conditions are better handled through regular review or planned investigation.

This distinction should influence how alerts are classified and delivered. An event that requires immediate intervention needs a defined escalation path. The responsible team should know what to verify and which options are available. The notification also needs to reach someone who can actually act on it.

A performance trend developing over several weeks may instead belong in a recurring operational review. Repeated critical notifications will not necessarily improve the response when the underlying problem requires analysis, planning and an approved change.

Alert severity should reflect operational impact and the required response rather than the numerical size of a metric alone.

An alert also does not always require a configuration change or immediate intervention. Sometimes the appropriate response is to confirm that the condition is expected, continue observing its development or document an accepted operational risk.

That decision should be deliberate. A temporary increase in resource consumption during a known maintenance process may be acceptable, provided the activity remains within agreed operating conditions. The same behavior during normal business operations could deserve closer attention.

The environment matters as well. An interruption affecting a development database does not automatically require the same response as an unavailable production database supporting a time-sensitive business process.

Neither condition should be dismissed solely because of its classification. The relevant considerations are application dependencies, business impact, recovery expectations and the consequences of delaying action.

Repeated alerts can reveal weaknesses in the monitoring design

One useful starting point when reviewing an existing monitoring environment is to examine notifications that appear frequently but rarely result in action.

There may be a legitimate explanation. A threshold could be too sensitive for a known workload, maintenance activity may generate expected resource consumption, or several monitoring rules might report the same underlying condition. In those cases, adjusting the configuration can reduce interruptions without losing important information.

However, recurring alerts deserve careful evaluation before they are disabled.

Sometimes a team has become accustomed to a condition that was never properly resolved. A transaction log may regularly approach its available capacity, or an application may repeatedly encounter short periods of blocking during a particular workload.

Those patterns may be familiar, but familiarity does not establish that the associated risk is acceptable.

The important question is why the condition continues to occur and whether its consequences are understood. A warning that appears every morning may describe expected activity, but it could also indicate an unresolved capacity problem or a workload dependency that has never been investigated properly.

This is where the history of previous alerts becomes particularly valuable. If the team can explain the condition, demonstrate that its impact is acceptable and identify when it would require intervention, the monitoring rule can be adjusted accordingly.

If nobody can explain the recurring warning, disabling it would remove the notification without addressing the uncertainty behind it.

A monitoring review should therefore distinguish between irrelevant notifications, expected operating conditions and unresolved technical risks. The objective is to reduce unnecessary interruptions while preserving visibility into conditions that deserve attention.

Monitoring quality also depends on ownership and operational processes

Even well-designed monitoring rules have limited value when responsibilities are unclear.

Consider a storage warning generated for a SQL Server running on a virtual machine. The DBA may understand the consequences for database files, but additional capacity could depend on the infrastructure team or an external provider.

If the notification reaches only the DBA, the technical issue may be identified without anyone having a clear path to resolve it.

The same difficulty can occur with application performance. SQL Server metrics may indicate increased execution times, while further investigation requires information from developers, application owners or the network team.

The monitoring platform can identify a condition and preserve the available evidence. Resolving the problem may still depend on another team, an external provider or an approved infrastructure change.

Those dependencies need to be understood before an alert becomes critical. Otherwise, valuable time may be spent determining responsibilities while the underlying condition continues to develop.

This does not mean that every technical warning requires a formal escalation process. Routine conditions can often be handled directly by the responsible administrators. However, where responsibilities cross team or service boundaries, the necessary communication and access paths should already be established.

Monitoring also benefits from feedback after investigations and incidents.

When an alert repeatedly proves unhelpful, the team should understand why and adjust the rule if appropriate. When a significant incident occurs without a useful warning, the available measurements and alert conditions deserve review.

Sometimes the necessary data was never collected. In other situations, the information existed, but the monitoring configuration did not recognize the change or communicate it to the right people.

These situations require different improvements, and neither automatically calls for a new monitoring product.

How to assess your SQL Server monitoring

Improving an existing monitoring environment does not have to begin with replacing tools or collecting additional metrics. A useful first step is to examine how the current alerts have actually supported operations.

Start with notifications that occur frequently. Look at when they were triggered, what the responsible administrators did and whether the investigation resulted in a meaningful action or decision.

If the same warning appears repeatedly without any response beyond acknowledgment, there should be a clear explanation. Perhaps the threshold no longer reflects the workload, or the condition is expected and does not require immediate attention. It is also possible that the team has accepted a recurring problem without properly evaluating its consequences.

Incidents without meaningful alerts

The next step is to look at significant incidents that occurred without a useful warning.

Did the monitoring system collect information that could have indicated the developing problem? Were relevant measurements available but not evaluated? Or did the incident involve a dependency outside the scope of the existing monitoring configuration?

These questions help distinguish missing visibility from ineffective alerting.

For example, a database application may experience progressively longer response times while server-level CPU, memory and storage metrics remain within normal ranges. If the monitoring system only observes infrastructure thresholds, it may have no reason to generate a notification.

Adding more infrastructure alerts would not necessarily address that limitation. The environment may need better visibility into workload behavior, query performance or application response times.

Conversely, if the monitoring system already collects those measurements, the more appropriate action could be to review how they are evaluated and when they should trigger an investigation.

A useful assessment should also consider whether the recipients can act on the information they receive. An accurate warning that arrives without sufficient context, or reaches a team without the necessary access or responsibility, may still fail to support an effective response.

The outcome does not have to be fewer alerts in every situation. Some environments may need additional monitoring for risks that are currently invisible, while others may benefit from reducing redundant notifications and refining escalation paths.

What matters is understanding which information supports operational decisions and where the existing monitoring configuration falls short.

Improving monitoring without creating more noise

A useful starting point is to review two things: the alerts that repeatedly interrupt the operations team without leading to action, and the incidents that occurred without a meaningful warning.

The first group can reveal unnecessary noise or unresolved problems that have become routine. The second can show where important information is missing or where existing measurements were not evaluated effectively.

Together, they provide a practical basis for improving SQL Server monitoring without immediately changing tools or collecting more data.

The goal is not to eliminate alerts. It is to make sure that relevant conditions receive attention, that administrators have enough context to investigate them and that the organization understands what needs to happen next.

The post SQL Server Monitoring Without Alert Fatigue: From Metrics to Operational Decisions appeared first on CraftedSQL.

Digital sovereignty is broader than database operations. It can also include legal, regulatory, commercial and strategic considerations that go well beyond SQL Server. This article does not attempt to define all of them. The focus here is narrower: operational control. For SQL Server digital sovereignty, that means asking how much control an organization actually retains over its data. It also means asking whether the organization can operate, protect and recover the database environment when normal conditions no longer apply.

A SQL Server can run inside the company’s own data center and still depend heavily on external services. Those services may provide identity, backup, remote administration or key management. At the same time, a cloud-based SQL workload can provide clearly defined controls over administration, encryption, backup and recovery. The deployment model therefore tells us something about responsibility, but it does not answer the sovereignty question on its own.

Data location is only one layer

Data residency is an obvious place to start because databases contain information that an organization needs to protect. Teams should know where production databases, backups and replicas reside. However, location alone does not explain who controls them or what the organization can still do during an incident.

A SQL Server environment usually extends beyond its primary database files. Backups may go to another storage platform, while monitoring systems may process operational data elsewhere. Administrators or service providers may connect remotely, and encryption can depend on an external key-management system. High availability can introduce further locations and dependencies. Once those components become part of normal operations, they also become part of the question of control.

Running SQL Server on-premises gives an organization direct responsibility for many infrastructure components. Even then, not every relevant dependency sits under the same control. Remote support services, identity providers, cloud backup platforms or externally managed infrastructure may still form part of the operating model.

The reverse is also true. Moving a workload to a cloud platform does not mean that an organization automatically gives up control. What matters is which responsibilities remain internal, which the provider assumes and which technical dependencies arise from that division.

This distinction becomes especially important during incidents. Under normal conditions, most dependencies remain largely invisible because they simply work. Operational control becomes easier to judge when one of them stops working. At that point, the organization may have to continue operating or recover the service without relying on the normal path.

What SQL Server digital sovereignty looks like in practice

A useful assessment therefore starts with concrete operational questions rather than a general cloud-versus-on-premises debate. Who can access the SQL Server environment with administrative privileges? Where are the database backups, and who controls those copies? Who controls the encryption keys? Which external accounts, network paths or services does the team need to administer the environment? Most importantly, could the organization recover an important database if one of those dependencies became unavailable?

Consider a SQL Server that runs on company-owned hardware. The organization keeps the database files locally, while an external service stores the backups. Administrators authenticate through a cloud identity provider, and another external system holds important encryption keys. The production database remains on-premises, but parts of its administration and recovery path do not. That does not make the architecture wrong. It means that an assessment of operational control has to look beyond the physical location of the SQL Server.

Now consider the opposite situation. A managed database platform may provide a defined regional deployment, restricted administrative access, encryption controls and a documented recovery model. Whether that architecture meets an organization’s sovereignty requirements depends on the requirements themselves. It also depends on which dependencies the organization is willing to accept. The word cloud does not answer that question any more than the word on-premises does.

For that reason, teams should define the required level of control before they use sovereignty as an argument for or against a platform. Otherwise, the architecture decision starts with a label. Only afterwards does the organization try to determine whether the operating model actually fits.

Backups reveal recovery dependencies

Backups are particularly useful when examining operational control because they connect production, security and recovery. A backup may exist and may complete successfully every night. It can still be difficult to use when it is needed.

For example, the backup files can be available while access depends on credentials owned by another team. Encryption keys may exist, but nobody has tested their recovery procedure. The backup destination might also rely on an identity service or network path that an incident has already made unavailable. None of these conditions makes the backup itself invalid. However, they change the question from “Do we have a backup?” to “Can we actually use it under recovery conditions?”

That is also why backup ownership matters. Someone needs to know where the backups reside and how the organization protects them. The team also needs to know which credentials recovery requires and how to obtain the necessary encryption keys. This is the same reason a SQL Server backup strategy should be judged by recovery readiness rather than successful jobs alone.

Encryption keys are part of operational control

Encryption introduces a similar dependency. A statement such as “the database is encrypted” or “the backups are encrypted” says little about who controls the keys. It also does not explain how administrators gain access to them or what happens when the normal key-management path fails.

SQL Server architectures can use different encryption and key-management approaches. The implementation details belong in a security or architecture review. From an operational perspective, however, the question is more direct: can the organization identify the keys required to recover its important databases? Can the responsible team access those keys when recovery is actually necessary?

For encrypted backups, the recovery dependency is explicit. Microsoft explains in its documentation on SQL Server backup encryption that the certificate or asymmetric key used for encryption must be available on the restore instance. Without it, the backup cannot be restored. This makes key custody part of the recovery design, not only a security setting.

This dependency also matters for SQL Server digital sovereignty. A database may rely on one key-management mechanism, while the backup platform uses another identity or access path. Such an architecture can be technically sound. Yet the organization may still have an operational blind spot if nobody has mapped or tested those dependencies.

Recovery makes operational control visible

Normal operations can hide those blind spots for years. Applications connect successfully, backup jobs complete, monitoring remains green and administrators sign in through the normal authentication path. None of that necessarily tests whether the organization could still operate after losing one of those services.

An incident changes the conditions. Identity services can become unavailable, network routes can fail and credentials may no longer work as expected. Administrators can also lose access to provider accounts. In a larger outage, several services that appear independent during normal operation may fail at the same time.

This is why recovery testing provides one of the most practical ways to examine operational control. It exposes which systems the organization actually needs. At the same time, it challenges assumptions that day-to-day operation rarely tests.

For an important workload, a restore test should therefore go beyond confirming that SQL Server can execute RESTORE DATABASE. The team also needs to obtain the required credentials and keys, reconnect the application and return the service to an acceptable state. A technically successful restore is important, but it represents only one part of service recovery.

If recovery depends on external components, that does not automatically make the design unsuitable. Most modern environments contain services and platforms outside a single team’s direct control. Removing every external dependency would often add more complexity than value. What matters is whether the organization knows those dependencies, understands their effect on recovery and has consciously accepted the resulting operational risk.

Platform choice should follow the control requirements

Sovereignty discussions can easily turn into platform discussions. On-premises SQL Server, SQL Server on virtual machines, managed Azure SQL services and other hosting models distribute responsibility differently. Each model gives an organization direct control over some components while transferring responsibility for others. Starting with a preferred platform can therefore reverse the decision process.

One organization may require strict control over administrative identities while accepting managed infrastructure. Another may need independent control over backup copies because of its recovery requirements. A third may consider workload portability an important part of its broader technology strategy. These are different requirements, even though all of them can appear in a sovereignty discussion.

Once teams define those requirements clearly, architects can compare platforms against the required level of control, operational complexity, support model, cost and recovery capability. Without that step, labels such as on-premises, European cloud or sovereign cloud provide only limited information. They do not explain how the SQL Server workload will actually operate or which dependencies remain outside the organization’s direct control.

The same principle applies to existing environments. An organization does not necessarily need to redesign the architecture simply because an external dependency exists. The more useful first step is to understand what that dependency does, who owns it and what happens if it becomes unavailable.

Assessing SQL Server digital sovereignty through operational control

A SQL Server digital sovereignty assessment does not have to remain an abstract strategy exercise. For an existing environment, a useful review can map where production data and backup copies reside. It can also identify which administrative identities have access, who controls encryption keys and which external services support normal operation and recovery.

The goal is not to produce another inventory for its own sake. Instead, the organization needs to understand whether the current operating model still provides enough control for its requirements.

That analysis often exposes issues that reach beyond the sovereignty discussion itself. Teams may discover unclear backup ownership, undocumented administrative access or recovery procedures that depend on individual employees. They may also find infrastructure choices that nobody has tested under failure conditions. Some of those dependencies will be perfectly acceptable; others may deserve a technical or management decision.

The important part is that these dependencies become visible before an incident forces a decision under pressure. A focused SQL Server architecture or operations review can help separate acceptable dependencies from risks that require action. It can also show where control exists mainly on paper because nobody has tested the operating and recovery processes under changed conditions.

Operational control is therefore not a complete definition of digital sovereignty, and it should not be presented as one. It is, however, a part that organizations can examine, test and improve in practical terms. For a SQL Server environment, that eventually leads to a question that is far more useful than a platform label:

If an important dependency became unavailable tomorrow, would we still have enough control to operate and recover this SQL Server environment?

Foto von Hans Westbeek auf Unsplash

The post SQL Server Digital Sovereignty: Why Operational Control Matters appeared first on CraftedSQL.

Those may all become relevant. But at that point, one important question is often still unanswered: what exactly are we trying to protect the service against?

A failed Windows node is not the same problem as losing a storage system. An unavailable SQL Server instance is different from losing an entire site. Planned maintenance creates another requirement again. If we do not separate those situations first, choosing the technology becomes partly guesswork. We are already discussing the architecture before we have defined what it actually needs to do.

SQL Server high availability starts with the failure the service needs to survive

High availability is not a single condition. A production application can become unavailable because the server hosting SQL Server fails, because Windows or the SQL Server service has a problem, or because storage becomes inaccessible. The network path between the application and database can disappear as well. SQL Server itself may be completely healthy while clients can no longer reach it.

The scale of the required protection also varies. One environment may only need to tolerate the loss of a single physical or virtual server. Storage, networking and the data center may already provide sufficient redundancy. Another workload may need to continue operating after the loss of a complete storage platform or location. Both are legitimate requirements, but they lead to different architectures.

This is where technologies such as Failover Cluster Instances and Availability Groups enter the discussion, although they solve different parts of the problem. An FCI provides redundancy for a SQL Server instance across Windows Server Failover Cluster nodes, while the database files remain on storage accessible to those nodes. An Availability Group maintains database replicas on separate SQL Server instances and can move the primary role between them.

That difference matters, but it still does not tell us which design is appropriate. If the relevant failure is the loss of a Windows node while the shared infrastructure remains available, one architecture may be sufficient. If the requirement also includes a separate copy of the databases or protection against failure of the original storage platform, the design has to cover a wider failure domain.

The same reasoning applies beyond SQL Server. Two database servers do not automatically remove every single point of failure. Both systems may still depend on the same storage platform, network components, DNS infrastructure, authentication services or physical location. That does not make such an architecture wrong; shared components may themselves be highly available. What matters is knowing where the common dependencies are and whether they sit inside or outside the failure scenario the design needs to handle.

When reviewing an HA design, I therefore find a different question more useful than simply asking whether two SQL Servers exist: which failure could remove both systems, or make both unreachable, at the same time?

That usually gives the architecture discussion a much clearer boundary.

RPO and RTO need to be requirements, not consequences

Once we understand the failure scenarios, the next question is what the organization expects to happen after one of them occurs. How much committed data can the business afford to lose, and how long may the service remain unavailable?

We normally describe these requirements as recovery point objective and recovery time objective. They should influence the architecture before the team selects a technology. They should not become numbers derived afterwards from whatever solution the team happened to implement.

A workload that can tolerate several minutes of potential data loss gives the architecture more options. A transactional system where losing acknowledged transactions would create a serious business problem has very different requirements. The same applies to recovery time. If an application can remain unavailable for an hour, the design does not need to behave like a system expected to resume operation within a few minutes.

Availability Groups provide a good example because the configuration itself changes the recovery characteristics. Synchronous and asynchronous commit modes make different trade-offs around transaction protection, latency and distance. A synchronized synchronous replica can support failover scenarios without losing committed transactions under the conditions covered by that design. An asynchronous replica, by contrast, may not yet contain the latest transactions when the primary fails.

Microsoft also provides guidance for monitoring and estimating RPO and RTO for Availability Groups. That is useful because these values depend on the actual configuration and data movement rather than on the product name alone.

RTO depends on much more than the SQL Server role change. After a failover, the new primary must become usable, clients need to reach the correct endpoint and application connections have to recover. Listener configuration, DNS, network paths, authentication, connection strings and client retry behavior can all influence what users actually experience.

This is why I would not define recovery time as the number of seconds required for SQL Server to complete a failover. The relevant measurement is the time until the service the business depends on works again. We looked at the same distinction from another direction in SQL Server Restore Validation: a database being ONLINE is an important technical state, but it does not prove that users can actually use the application service again.

The same separation is useful for backups. High availability can reduce interruption caused by certain infrastructure failures, but it does not provide the recovery options of a properly designed backup strategy. An accidental DELETE, an unwanted application change or another logical problem can reach additional replicas as part of normal data movement. If the requirement is to return to an earlier state, that is a recovery problem, not simply an HA problem.

This distinction is also important when looking at SQL Server backup strategy. High availability and backup can both support service continuity, but they protect against different failure scenarios. Teams should not treat them as substitutes for each other.

Maintenance is part of availability too

Unplanned failures naturally dominate high availability discussions, yet many production systems experience planned maintenance far more often than catastrophic infrastructure failure. Windows needs patching, SQL Server needs updates, virtualization hosts need maintenance and hardware eventually gets replaced.

Those activities belong in the architecture discussion because the chosen design determines how the workload can move and how much disruption routine maintenance creates.

If a service may only be unavailable for a few minutes, the team needs a practical and repeatable way to move production away from the component that needs maintenance. That includes more than issuing a failover command. Someone needs to know whether the target system is ready and whether application connections move as expected. The team also needs to understand how jobs and supporting services behave and what happens if it cannot complete the planned work.

A different environment may have a generous maintenance window and no business reason to eliminate every planned interruption. In that situation, additional HA components can create complexity without solving a requirement that actually exists.

That trade-off is easy to miss when the discussion starts with technology. More redundancy can remove failure points, but it also introduces additional components, configuration and operating procedures. Availability Groups, Windows clustering, listeners, endpoints, multiple SQL Server instances and possibly multiple locations all become part of the operating model. The team needs to monitor and understand them. During normal operation that complexity may remain almost invisible, but during an incident or maintenance window it suddenly becomes part of the recovery process.

For that reason, I consider operational capability part of the architecture rather than something to document afterwards.

This becomes particularly important in environments that have been running for many years. People change roles, applications evolve, teams replace infrastructure and the original reasons behind technical decisions become less obvious. An Availability Group or cluster may still be healthy according to monitoring while nobody is entirely comfortable performing a controlled failover because the team no longer fully understands the dependencies around it.

The technology has not necessarily become unreliable. The operating model around it has changed.

That is also one of the things worth looking at during a SQL Server Health Check. The existence of an HA configuration tells us relatively little on its own. Its purpose, dependencies, maintenance procedures and current level of operational understanding are much more informative.

Testing a SQL Server high availability design

Documentation and architecture diagrams can describe what should happen during a failure. A controlled failover shows what actually happens.

It verifies whether the expected node or replica can take over, but that is only the beginning of the test. The application also needs to reconnect, monitoring should recognize the role change and required SQL Server Agent jobs and supporting processes need to behave correctly. The team also needs a reliable way to decide whether the service is healthy after the transition.

Testing turns an assumed recovery time into something measurable. It may show that SQL Server changes roles within seconds while the application needs several additional minutes before users can work again. It can expose a DNS dependency, a connection string that still points directly to one server or an operational step that everyone assumed automation would handle.

Those findings are not arguments against the HA technology. They are information about the complete service.

This is why I am cautious with designs that look convincing on paper but that teams rarely exercise. If the team considers failover too risky to test during a controlled maintenance window, relying on the same process during an uncontrolled production incident deserves closer examination.

AG or FCI becomes a useful question after this

Once the failure domain, recovery objectives, maintenance requirements and operating model are clear, comparing SQL Server technologies becomes much more productive.

An FCI can be a natural fit where instance-level continuity is important and the surrounding storage architecture already provides the required availability. An Availability Group can fit a design that needs separate database replicas, database-level failover or replicas across different infrastructure or locations. In some environments, teams deliberately combine the technologies because they address different failure scenarios.

There are further differences around storage, networking, instance-level objects, licensing, readable replicas, administration and SQL Server version capabilities. Those details matter when evaluating a concrete architecture, but they are not a substitute for the requirements that lead to it.

A long AG-versus-FCI feature matrix can otherwise create a false sense of precision. A feature may be technically attractive without solving a problem the workload actually has. Conversely, a comparatively simple design can be completely appropriate when it matches the required failure domain, RPO, RTO and operating capabilities.

Before approving a SQL Server high availability design, I would therefore want to describe several scenarios in ordinary language. We should know what happens when one Windows node disappears, when storage becomes unavailable and when the primary location can no longer be used. For each relevant scenario, we should also understand how much data the business could lose and how long the application may remain unavailable. Finally, the team should have demonstrated the recovery process rather than only documented it.

That gives us something much more useful than starting with the question, “Should we use an Availability Group or an FCI?”

It tells us what the architecture actually needs to accomplish.

Once that is clear, choosing the SQL Server technology becomes a technical decision with defined boundaries rather than the starting point of the design.

Foto von huanyu chen auf Unsplash

The post SQL Server High Availability: Define the Failure Before Choosing the Technology appeared first on CraftedSQL.

The problem starts when people treat the plan as if it were the complete explanation for a performance incident.

Suppose users report that an application was slow around 10:00. Someone investigates an hour later, runs the query again and captures an actual execution plan. The query is fast now. The plan looks reasonable. There may still be useful clues in it, but we are already looking at a different execution under different conditions. If I want to understand what happened at 10:00, the plan captured at 11:00 is only one part of the evidence.

That distinction sounds obvious, but it matters because execution plans are very persuasive. They are visual, detailed and concrete. It is easy to find an operator that looks suspicious and start tuning from there, even when we have not yet established whether that operator had anything to do with the problem users experienced.

What SQL Server execution plans can tell you

An execution plan describes the strategy SQL Server selected for a statement. The optimizer makes that decision using the information available at compile time: statistics, indexes, cardinality estimates, parameter values and other conditions that can influence the plan.

An estimated plan shows that compiled strategy without running the query. An actual execution plan adds information from the execution itself, including actual row counts and, depending on the plan and SQL Server version, other runtime details. Microsoft explains the distinction in its documentation on displaying and saving execution plans.

For troubleshooting, I usually prefer the actual plan because I can compare what SQL Server expected with what it really processed. If SQL Server expected a few rows but processed several hundred thousand instead, that is worth investigating. The mismatch may affect join choices, memory requirements or the amount of work performed further up the plan.

But the difference itself is not yet a diagnosis. I still need to know whether it helps explain the slow execution I am investigating.

Parameter-sensitive workloads change the picture

This becomes especially relevant with parameter-sensitive workloads. A stored procedure may use the same cached plan for one parameter value that returns ten rows and another that returns several hundred thousand. The plan shape can remain almost unchanged while the actual workload is very different. Data distribution can make that difference larger, and so can changes in the surrounding workload. A plan that works perfectly well for one execution can be much less suitable for another without looking obviously broken when viewed in isolation.

The same caution applies in the other direction. A scan, a warning or a high estimated cost may look uncomfortable, but none of those things automatically explains the incident. A scan against a small table may be entirely appropriate. An expensive operation that runs once at night may matter less than a small query executed thousands of times during business hours.

What I am trying to establish is not whether the plan contains something that could be improved. On a sufficiently busy SQL Server, I can usually find something. I want to know whether the plan explains the behavior that actually caused the problem.

The surrounding workload changes what the plan means

A query can use the same execution plan and still take very different amounts of time.

Another transaction may block it. Storage latency may increase. CPU pressure can come from unrelated activity, while several normally harmless queries may start running at the same time and compete for the same resources. None of that necessarily changes the plan shape.

This is one reason I do not like looking at SQL Server execution plans completely on their own during a production incident. The plan shows what SQL Server intended to do with the query, but elapsed time also includes waiting. If the query spent most of that time waiting for a lock or for storage, tuning an operator may solve the wrong problem.

Wait statistics can help here because they add another view of what SQL Server was waiting for. They have the same limitation, though: they are evidence, not a diagnosis on their own. I wrote about that in SQL Server Wait Statistics Are Not a Diagnosis.

This is also where the timing of the investigation becomes important. If I have an actual plan from the affected execution, together with runtime metrics and information about blocking or resource pressure at the same time, the pieces can start to support each other. If I only have a plan captured later, I have to be much more careful about what I conclude from it.

That is often the difference between finding a plausible tuning opportunity and actually explaining an incident.

When SQL Server execution plans need history

Teams often investigate SQL Server performance problems after the interesting part has already happened.

The application was slow earlier in the morning. Users complained, perhaps monitoring raised an alert, and by the time someone starts looking closely everything appears normal again. CPU is back at its usual level, the blocking chain has disappeared and the query that supposedly caused trouble now finishes quickly.

At that point, current SQL Server execution plans can tell me how the query behaves now. What I really need is a way to compare the current behavior with the period where the problem existed.

Looking back with Query Store

Query Store helps with exactly that. It keeps query texts, execution plans and aggregated runtime statistics over time, which makes it possible to look back instead of relying only on what I can reproduce at the moment of investigation. Microsoft describes the collection process in How Query Store Collects Data.

I may find that the query changed plans shortly before duration increased. That does not prove the new plan caused the regression, but it gives me something concrete to investigate. I can compare both plans, look at the affected runtime intervals and see whether the timing fits.

Sometimes the more interesting finding is that the plan did not change at all.

If Query Store shows the same plan before, during and after the incident, forcing a different plan becomes much harder to justify. I would start looking more closely at the parameter values used during the slow period, concurrency, blocking or resource pressure. The unchanged plan does not tell me what the cause was, but it removes one attractive explanation from the top of the list.

That historical perspective is the reason I consider Query Store so useful in production troubleshooting. I covered that in more detail in SQL Server Query Store: Why Performance History Matters.

Without history, it is very easy to compare a bad user experience from 10:00 with a perfectly healthy execution from 11:00 and assume both represent the same situation.

They may not.

Before I change production, I want the story to make sense

A performance investigation eventually reaches the point where someone wants to change something. Maybe an index is missing. Maybe a different plan would work better. Perhaps a query needs to be rewritten, or a temporary mitigation is required because the application is already affected.

During an active incident, restoring service can take priority. There are situations where I will make a reversible operational change before I understand every detail of the root cause. That is different from deciding what the permanent fix should be.

Permanent tuning changes have consequences. An index helps reads but also affects writes and consumes storage. A hint limits the optimizer’s choices. A forced plan can stabilize a regression and later become a problem itself when the data or workload changes.

Before I make that kind of change, I want the evidence to fit together reasonably well. The plan should match the execution I am trying to explain, and the runtime behavior should support the hypothesis. Timing matters too. If historical data is available, I also want to know whether the behavior was unusual or simply normal workload seen at an inconvenient moment.

That does not require perfect certainty. Production troubleshooting rarely gives us that.

It does require enough context that I can explain why I expect the change to address the actual problem rather than merely improve something that looked suspicious in the plan.

For me, that is where SQL Server execution plans are most useful. They narrow the investigation, show me where SQL Server’s decisions deserve a closer look and give me something concrete to compare against runtime behavior and history.

They are strong evidence, but rarely the whole story.

Foto von David Kristianto auf Unsplash

The post SQL Server Execution Plans Need Runtime Context appeared first on CraftedSQL.

That sounds obvious, but SQL Server estates rarely grow as neatly as architecture diagrams suggest. A few systems may have been introduced years ago for applications that are still business-critical. Acquisitions, infrastructure changes or temporary projects may have added others along the way. Some run on physical servers, others on virtual machines, and ownership is not always as clear as it once was.

The result is not necessarily a badly managed environment. It may simply be an environment that has grown over time and now needs a clearer view.

Why visibility should come before migration

At some point, somebody asks a larger question. Which workloads should remain where they are? Which systems need an upgrade? Is there a reason to move anything to Azure? Are there SQL Server versions in use that require attention?

Those discussions become difficult when the inventory is incomplete or spread across several sources. As discussed in Why Workload Placement Matters More Than the Platform Label for SQL Server, a target platform should follow an understanding of the workload and the environment around it, rather than the other way around.

This is the part of Azure Arc SQL Server that I find more interesting than the migration story.

Azure Arc can bring SQL Server instances running outside Azure into the Azure management plane without moving the databases themselves. SQL Server continues to run on the existing server, whether that is on-premises or elsewhere, while Azure provides a central view of the connected instance. Microsoft describes the current scope in the Azure Arc-enabled SQL Server overview.

That distinction matters because it separates two decisions that often get mixed together: where a workload should run and how the organization wants to manage the SQL Server estate.

A SQL Server may have perfectly good reasons to remain on-premises. Latency, application dependencies, licensing, operational constraints or simply the absence of a convincing business case may all support that decision. None of those reasons prevent an organization from improving the way it inventories or governs that server.

For a mixed estate, that can already be useful long before migration becomes a serious discussion.

Azure Arc SQL Server and the inventory problem

Most organizations can produce a list of SQL Servers somehow. The more interesting question is how much confidence they have in that list.

If I am looking at an existing estate, I would want to know more than host names. I would want to understand which SQL Server instances are actually running, which versions and editions they use, which databases belong to them and whether the information is current enough to support a decision.

This becomes more important when environments span several locations or operational teams. A CMDB may contain one view, the monitoring platform another, while individual administrators maintain additional information because experience tells them that neither source shows the complete picture.

Azure Arc does not magically resolve those organizational differences. What it can provide is another technical source of inventory information based on systems that the organization has actually connected.

For SQL Server, this can include information about instances and databases and give teams a common Azure representation for servers that physically remain elsewhere.

That is useful, but I would be careful not to confuse inventory with understanding.

An old SQL Server version in a portal does not tell you whether the system can simply move to a newer release. A database name does not tell you which application depends on it. And a configuration that differs from a recommendation does not tell you whether changing it would improve the system or create another problem.

Those questions still require context. This is also where a broader SQL Server Health Check can become useful: not to create another inventory, but to understand which technical findings have an operational consequence and which ones simply describe the environment as it exists today.

Where central visibility becomes useful

The value becomes clearer when inventory information connects to an actual operational problem.

Imagine a company with SQL Servers in several locations where lifecycle reviews still depend heavily on manual work. Every few months, somebody collects version information, checks which systems still matter and tries to determine where upgrades deserve attention. A central inventory can remove part of that repeated effort.

The same applies when security, infrastructure and database teams need a common view of the environment. They may not need exactly the same level of technical detail, but they do need to be talking about the same systems.

Azure Arc can also extend the discussion beyond basic inventory. Microsoft provides additional SQL Server capabilities through the Azure extension for SQL Server, including assessment, management and security-related integrations. The available functions depend on the connected environment, configuration and licensing, so I would treat the current Microsoft documentation as the source of truth rather than assume that every Arc-connected SQL Server offers the same set of capabilities.

This is where I would resist the temptation to turn the discussion into a feature checklist. The interesting part is not how many functions the platform offers. It is whether one of them removes a problem that currently costs time, creates uncertainty or leads to weak decisions.

If an organization already has reliable inventory, good lifecycle management and established security processes, Arc may add comparatively little in that area. If those processes rely on manual work, differ between teams or leave important gaps, the calculation can look very different.

Azure Arc SQL Server also adds an operational layer

There is another part of the architecture that should not disappear behind the promise of central management. Azure Arc is not simply a passive view into an existing SQL Server estate.

To use it, an organization connects the servers to Azure. The Azure Connected Machine agent becomes part of the server environment, while SQL Server-specific functions use the Azure extension for SQL Server. Teams need to define permissions, provide the required connectivity and decide who owns the resulting Azure resources and operational processes. Microsoft documents those dependencies in the prerequisites for Azure Arc-enabled SQL Server.

None of this is unusual for an enterprise management platform, but it matters when deciding whether Arc actually makes the environment easier to operate.

I would therefore be reluctant to start an Arc project simply because the technology exists or because an organization already uses Azure elsewhere. I would first look at the current operating model and the problems people deal with today.

How difficult is it to identify the SQL Servers that exist? How much manual effort goes into lifecycle reviews? Do different teams maintain different inventories? Do important decisions slow down because somebody first has to collect basic information from several places?

If those questions expose a real gap, Azure Arc has something concrete to prove itself against. That is much more useful than starting with the product documentation and then looking for a reason to deploy the technology.

A hybrid SQL Server estate does not need one destination

There is also a broader architectural point here. Hybrid SQL Server environments are unlikely to disappear simply because cloud platforms continue to mature. Some workloads will move. Teams will replace some systems. Others will remain on SQL Server for a long time because that continues to be the appropriate place for them.

Treating every modernization discussion as a migration project therefore creates an unnecessarily narrow choice.

A company may decide that several SQL Server workloads should stay exactly where they are while still wanting better inventory, more consistent governance or closer integration with an Azure-based management model. Azure Arc makes that combination possible.

It does not decide whether a workload should migrate, and it does not remove the need to understand the applications, dependencies and operational risks behind the SQL Server instances it discovers. What it can do is make the estate easier to see while teams work through those decisions.

For me, that is the more useful way to think about Azure Arc-enabled SQL Server. It is not necessarily the first step of a cloud migration. It is one possible way to improve how a distributed SQL Server estate is understood and managed.

Sometimes that visibility may eventually support a migration. In other cases, the better outcome is simply having enough information to understand why a workload should stay where it is.

If the difficult part is not the technology itself but deciding how an existing SQL Server estate should evolve, the SQL Server consulting and modernization work at CraftedSQL focuses on that boundary between infrastructure, workload requirements, operational risk and the next reasonable technical step.

Foto von imgix auf Unsplash

The post Azure Arc-enabled SQL Server: Visibility Before Migration appeared first on CraftedSQL.

If a restore test only needs to prove that SQL Server can restore a backup file, reaching ONLINE may answer the immediate technical question. When the goal is to demonstrate recovery of a business-critical service, however, the database state provides only part of the evidence. Stopping the test at that point can create more confidence than the result really supports.

Backup and recovery are often discussed as though restoring the database marks the end of the process. From a SQL Server perspective, that may be true, but operationally the more useful question is what the organization can actually use once the restore has finished.

A successful restore proves something important, but not everything

The first task of a restore test is practical: confirm that the available backups can recreate the database. A backup job may run successfully for months and produce valid-looking backup files. Even so, it does not provide the same evidence as restoring those files under controlled conditions.

Depending on the recovery requirement, the technical validation may also confirm the expected backup chain and check the resulting database state. It may also need to establish which point in time the restore has recovered. Microsoft documents the SQL Server restore and recovery process in detail, although those technical steps still answer questions about the database rather than the service that depends on it.

The operational part begins once SQL Server has completed its work, because an application rarely depends on a restored database alone. It also needs to find the SQL Server instance, authenticate correctly and interact with the other components the workload requires.

That is where the difference between database restored and service recovered becomes visible.

The database is part of a larger dependency chain

Some dependencies an application needs do not live inside the restored database at all. SQL Server logins, SQL Agent jobs, credentials, linked servers and instance-level configuration may matter. Application configuration, certificates, DNS, network access or external services can introduce further dependencies outside SQL Server.

This does not mean that every restore test should become an exhaustive inventory of every possible server object or infrastructure component. The useful question is narrower: which dependencies does this particular service require, and does the recovery design include them?

During normal operation, many of those relationships remain largely invisible because everything is already in place. A recovery makes them much easier to see, especially when the database is technically available but the application still cannot use it.

Restore testing therefore provides value beyond validating the backup itself. It also shows how well the organization understands the system and the dependencies needed to bring it back into use.

Application connectivity deserves its own validation

A common gap appears when the database team checks the restored database, but nobody tests the application against the recovered environment. From the SQL Server side, everything may look reasonable: the database is online, queries run and the expected objects exist. None of those checks proves that the application can establish its own connection and perform the work for which the database exists.

Authentication may behave differently on the recovery system. A connection string may still reference another server, a required login may be missing or mapped incorrectly, or a network dependency may differ from production. In each case, the restore can succeed technically while the service remains unusable.

For a simple application, proving service availability may require little more than connecting through the application and executing a known function. In a more complex environment, the database team may not be able to make that judgement alone. Application support or a business owner may need to confirm that the relevant workflow behaves as expected.

The point is not to prescribe one universal test. Someone needs to validate the recovered environment from the perspective of the service, rather than only from the perspective of SQL Server.

The right database can still contain the wrong data

Another distinction appears when the database itself is healthy, but the restored point in time does not meet the business requirement.

A database can restore successfully and pass technical checks while still leaving the organization with more data loss than it intended to accept. Suppose the most recent usable recovery point is several hours old, while the agreed recovery point objective allows only a much smaller gap. In that case, the restore worked, but the recovery objective did not.

This is where RPO becomes operational rather than theoretical. The relevant question is not simply whether the organization can restore data. It also needs to know which data would actually be available after a realistic failure and whether that recovery point is acceptable for the affected process.

Backup frequency, transaction log backups, retention and the availability of the required backup chain all influence that result. Effective SQL Server restore validation should therefore make the recovered point in time visible. The database state alone does not prove that the recovery requirement has been met.

Otherwise, the technical team may correctly report that the restore succeeded, while the application owner later discovers that the available data is older than expected.

Recovery time does not stop when RESTORE finishes

The same distinction applies to recovery time, because the SQL Server restore represents only one part of the time needed to return a service to use. A useful SQL Server restore validation process should therefore measure more than the restore operation itself. Application checks, dependency validation and operational approval may add significant time before the service can resume.

A restore operation is easy to measure because it has a clear start and finish. Suppose the database takes 35 minutes to restore, but the teams then need another hour to resolve dependencies and reconnect the application. They may also need to validate the data and approve the return to service. In that case, 35 minutes remains useful technical information, but it is not the effective service recovery time.

For business continuity planning, the meaningful endpoint is the moment when the required service can actually resume. Reaching that point may involve several teams. Infrastructure may provide the platform, the DBA may restore and validate the database, and application support may verify connectivity and behaviour. The business owner may still need to decide whether the recovered state is acceptable.

When teams have never tested those handoffs, the organization may know how long SQL Server needs for a restore. It still may not know how long the complete recovery really takes.

Recovery needs a defined end condition

That leads to one of the less technical questions in the process: who decides that recovery is complete?

The DBA can confirm a successful database restore and verify that SQL Server sees the database as available. Infrastructure can confirm that the server and network work as expected, while application support can verify connectivity and application behaviour. Depending on the system, a business owner may also need to confirm that the recovered data and the relevant workflow are acceptable.

No universal division of responsibility fits every environment, nor does one need to. The boundary should simply be understood before an incident occurs. If every team considers its own technical task complete without a shared definition of the final outcome, several successful individual steps can still leave the service unavailable beyond the required recovery time.

A useful restore test therefore needs an operational end condition. Instead of ending with “the database is ONLINE,” the test should establish that the required data is available and the application can use it. The relevant dependencies also need to be in place, and the responsible people need enough evidence to return the service to operation.

That provides a different level of assurance, because it describes an operational outcome rather than a database state.

What SQL Server restore validation should actually prove

Backup strategy and restore validation are sometimes treated as separate administrative topics, although they address the same recovery question. Backup frequency, retention, protected storage, monitoring and transaction log handling exist because the organization expects to recover something from them when needed.

Restore testing allows the organization to test those assumptions against an actual outcome.

Can the team locate and access the required backups? Does the necessary backup chain exist, and can the team restore the database away from the original system if necessary? Are the important dependencies known? Can the application use the recovered database, and does the resulting recovery point meet the requirement?

Those questions provide more useful evidence than a green backup job alone. They connect the technical backup process to the service it is meant to protect.

The earlier CraftedSQL article SQL Server Backup Strategy: Why Successful Backups Are Not Enough looked at this from the backup side. Restore validation provides the corresponding recovery perspective: the backup process becomes much more meaningful once the organization has evidence of what it can actually recover from it.

The test should reflect the service you are trying to recover

No single restore-validation procedure fits every SQL Server environment, because recovery requirements differ substantially. A reporting database that may remain unavailable for several hours does not need the same validation process as an operational system with stricter recovery requirements. A self-contained application also has a different dependency chain from a service that spans several databases, interfaces and infrastructure components.

Good SQL Server restore validation therefore starts with the expected recovery outcome rather than with a generic checklist. What must be available again, and how much data loss can the organization accept? Which dependencies are required? Who can verify that the application works, and who is responsible for releasing the service back into operation?

Once those questions are clear, the team can test the restore process against them. That makes it much easier to define what a successful recovery test actually means.

A database reaching ONLINE remains an important milestone, but it is not the same thing as having recovered the service that depends on it.

Foto von Hyoshin Choi auf Unsplash

The post A Restored Database Is Not the Same as a Recovered Service appeared first on CraftedSQL.