8.3 Monitoring with Database Watcher (Preview)

DP-300: Administering Microsoft Azure SQL Solutions Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current DP-300 Exam Facts 1.2 Skills Outline and Domain Weights 1.3 Study Strategy and Official Resources

2 Planning and Deploying Azure SQL Solutions

2.1 Choosing and Deploying Azure SQL Database Offerings 2.2 Automated Deployment, Azure Arc, and SQL Database in Microsoft Fabric 2.3 Table Partitioning and Sharding Strategy 2.4 Hybrid SQL Server and IaaS Patching

3 Configuring Resources for Scale and Performance

3.1 Configuring Azure SQL Database for Scale and Performance 3.2 Configuring Azure SQL Managed Instance for Scale and Performance 3.3 Configuring SQL Server on Azure VMs for Scale and Performance 3.4 Configuring Table Partitioning and Data Compression

4 Planning and Implementing a Migration Strategy

4.1 Evaluating Migration Requirements and Strategies 4.2 Implementing Online, Offline, and Azure Migrations 4.3 Migrating Between Azure SQL Services and Troubleshooting

5 Configuring Database Authentication and Authorization

5.1 Microsoft Entra ID Authentication for Azure SQL 5.2 Authentication for SQL on Azure VMs and Managed Instance; Troubleshooting 5.3 Security Principals and Entra-Backed Users 5.4 Permissions, Least Privilege, and T-SQL Management

6 Implementing Security for Data at Rest and in Transit

6.1 Transparent Data Encryption and Object-Level Encryption 6.2 Always Encrypted and VBS Enclaves 6.3 Firewall Rules, Private Links, and Service Endpoints

7 Implementing Compliance Controls for Sensitive Data

7.1 Data Classification and Server/Database Auditing 7.2 Change Data Tracking and Dynamic Data Masking 7.3 Row-Level Security and Ledger in Azure SQL

8 Monitoring Resource Activity and Performance

8.1 Operational Baselines and Performance Metric Sources 8.2 Interpreting Metrics and Configuring Activity Monitoring 8.3 Monitoring with Database Watcher (Preview) 8.4 Monitoring with Extended Events

9 Monitoring and Optimizing Query Performance

9.1 Configuring and Monitoring with Query Store 9.2 Session Blocking and Dynamic Management Views 9.3 Index Changes and Execution Plan Review 9.4 Query Construct Modifications and Intelligent Insights

10 Configuring Database Solutions for Optimal Performance

10.1 Index, Statistics, and Integrity Maintenance 10.2 Automatic Tuning and Database-Scoped Configuration 10.3 Server Settings and Resource Governor 10.4 Compute/Storage Scaling and Intelligent Query Processing

11 Creating and Managing SQL Server Agent Jobs

11.1 Schedules for Regular Maintenance Jobs 11.2 Job Alerts, Notifications, and Agent Troubleshooting 11.3 Automating Deployment with ARM and Bicep Templates

12 Automating Deployments and Database Tasks in Azure

12.1 Azure PowerShell, Azure CLI, and Deployment Monitoring 12.2 Elastic Jobs for Cross-Database Automation 12.3 Azure Automation Runbooks, Alerts, and Troubleshooting Automated Tasks

13 Planning an HA/DR Strategy and Backup and Restore

13.1 Recommending HA/DR Strategy from RPO and RTO 13.2 Hybrid and Azure-Specific HA/DR Solutions and Testing 13.3 Backup and Restore Strategy with Native Tools 13.4 Point-in-Time Restore and Recovery Operations

14 Configuring HA/DR: Long-Term Retention, Geo-Replication, and Failover Groups

14.1 Long-Term Retention, T-SQL Backup/Restore, and Cloud Storage 14.2 Active Geo-Replication 14.3 Failover Groups

15 Advanced HA/DR: Availability Groups, FCIs, Log Shipping, and Troubleshooting

15.1 Always On Availability Groups on SQL Managed Instance and Azure VMs 15.2 Always On Failover Cluster Instances and Log Shipping 15.3 Monitoring and Troubleshooting HA/DR Solutions

8.3 Monitoring with Database Watcher (Preview)

Key Takeaways Explain This Topic AI

Database watcher (preview) is a managed, centralized monitoring service for Azure SQL Database and Azure SQL Managed Instance only - SQL Server on Azure VMs and on-premises SQL Server are not supported targets

A watcher has four components: the watcher resource itself, SQL targets (the databases, elastic pools, or managed instances to watch), built-in datasets collected from over 70 catalog views and DMVs, and a data store - either an Azure Data Explorer database or Real-Time Analytics in Microsoft Fabric, never a Log Analytics workspace

Built-in datasets cover resource usage, active sessions, wait statistics, top queries, index and table metadata, backup history, and SQL Agent job state - you do not author T-SQL collection queries yourself as you would for a custom DMV script

Limits are 100 SQL targets per watcher and 20 watchers per subscription; watchers are free and dashboards are free, so the cost is the Azure Data Explorer cluster or Fabric capacity behind the data store

Database Watcher is in preview; expect feature gaps, regional limitations, and no production SLA - the official Microsoft guidance is to evaluate it for new monitoring designs but not to retire existing DMV-based monitoring until it goes GA

Last updated: August 2026

What Database Watcher Is

Azure Database Watcher (in preview as of the current exam) is a managed monitoring service built specifically for the Azure SQL family. Instead of each database being monitored in isolation through diagnostic settings and DMV scripts, a watcher is a regional Azure resource that you point at a set of SQL targets; it runs built-in collection sets on a schedule, lands the results in a central data store , and presents prebuilt dashboards on top. The goal is a unified, at-scale view of a fleet of databases and instances without authoring and maintaining a custom collection pipeline.

Database watcher is the replacement for the older Log Analytics monitoring solutions. SQL Insights (preview) was retired on 31 December 2024 , and Azure SQL Analytics is a legacy Azure Monitor solution that is no longer in active development; Microsoft's documented recommendation for Azure SQL Database and Azure SQL Managed Instance is database watcher. Do not confuse the retired SQL Insights monitoring solution with the SQLInsights resource log category , which is Intelligent Insights and is unrelated. The architectural difference is that the retired solutions depended on each target's diagnostic settings streaming logs into a Log Analytics workspace, whereas database watcher performs its own scheduled collection directly from targets.

Watcher Components

A watcher has four moving parts, and the exam expects you to know what each does:

Component Role
Watcher The Azure resource itself, created in a region; it owns the schedule, identity, and configuration

SQL target A database, elastic pool, or SQL managed instance to monitor. Only Azure SQL Database and Azure SQL Managed Instance are supported - SQL Server on Azure VMs and on-premises SQL Server are not. Targets can span subscriptions within one Entra tenant; the limit is 100 targets per watcher

Datasets Built-in collections drawn from more than 70 catalog views and DMVs (active sessions, resource usage, wait statistics, top queries, index and table metadata, backup history, SQL Agent job state, and more). Microsoft defines them; you do not write the T-SQL yourself

Data store Where collected data lands - an Azure Data Explorer database or Real-Time Analytics in Microsoft Fabric . A Log Analytics workspace is not a valid database watcher data store. Prebuilt Azure Workbooks dashboards query this store

The watcher authenticates to targets using a managed identity that you grant the appropriate read permissions on the target SQL resources. This is a security property worth noting: Database Watcher does not store credentials; it uses Azure AD / Microsoft Entra identity to connect.

Enabling and Configuring

The high-level flow:

Create the watcher resource in the same region as (or a region reachable from) your targets.

Create a Microsoft Entra login for the watcher's managed identity on each logical server or managed instance. On Azure SQL Database, grant exactly the three server roles ##MS_ServerPerformanceStateReader## , ##MS_DefinitionReader## , and ##MS_DatabaseConnector## ; on SQL Managed Instance, grant the equivalent server permissions plus SELECT on the msdb backup and SQL Agent tables. Granting more than the documented permissions is not harmless - the watcher validates its permission set on connect and disconnects if unnecessary permissions are present .

Add SQL targets to the watcher - identified by their Azure resource IDs.

Choose the data store - an Azure Data Explorer database or Real-Time Analytics in Microsoft Fabric - and grant the watcher access to it.

Start the watcher. A newly created watcher is not started automatically, which is the single most common reason a new deployment shows no data.

Review the dashboards - estate-level and resource-level Azure Workbooks that read from the data store.

No agent, no VM, no extension to install on the SQL target: the watcher reaches out from Azure using its managed identity and runs the built-in collection T-SQL directly.

Built-in Collection Sets

Microsoft ships collection sets covering the most-needed performance categories:

Performance and resource counters - CPU, memory, IO at the database and instance level.

Wait statistics - aggregated waits by type, to identify the dominant bottleneck category.

Query statistics - top queries by CPU, duration, and IO, sourced from Query Store when available.

Blocking and deadlocks - active blocking chains and deadlock occurrences.

Configuration snapshots - server/database configuration, database files, and sizing.

Because the collection sets are built-in, you avoid the maintenance burden of custom DMV scripts (which break when DMV schema changes, when targets move, or when new versions add new columns). The tradeoff is flexibility: if you need a metric the built-in sets do not cover, you fall back to custom diagnostics or DMV queries alongside the watcher.

When to Choose Database Watcher

The decision pattern the exam tests:

Situation Recommended tool
One database, single incident, right now sys.dm_exec_requests , sys.dm_db_resource_stats , Query Store

A few databases, custom alerts, tight integration with Azure Monitor Diagnostic settings + Log Analytics + metric alert rules

Fleet of Azure SQL databases/instances across many servers, centralized dashboards, low maintenance Database watcher (preview)

Monitoring SQL Server on Azure VMs or on-premises Not database watcher - use DMVs, the SQL IaaS Agent extension, and Azure Monitor

Compliance/audit of who did what SQL Auditing / Defender for SQL, not database watcher

The key advantage of database watcher over the retired Log Analytics solutions is that it performs its own scheduled collection rather than depending on each target's diagnostic settings being configured correctly; you configure the watcher once and it covers all its targets.

Limitations and Preview Status

Because Database Watcher is in preview, the exam expects you to know the practical implications:

No production SLA; the service may have outages and breaking changes between releases.

Regional availability is limited; you can only create watchers in a subset of Azure regions, although a watcher in one region can monitor targets in another.

Limits are subject to change during preview; today they are 100 SQL targets per watcher and 20 watchers per subscription.

Watchers and dashboards themselves are free. The cost sits in the data store - an Azure Data Explorer cluster or Fabric capacity - plus alert rules and any cross-region bandwidth.

If a monitored database, pool, or instance sits near 100% CPU, collection queries can be starved and leave gaps in the collected data.

Operational guidance: use Database Watcher for new fleet-wide monitoring designs where the preview limitations are acceptable, but do not retire existing diagnostic-settings-based monitoring or DMV scripts until the service reaches GA and you have validated that the built-in collection sets cover your needs. Keep at least one target on the older pipeline as a parallel-run control.