Datainsamling och datauppsättningar för database watcher (förhandsversion)

gäller för:Azure SQL DatabaseAzure SQL Managed Instance

Database Watcher samlar in övervakningsdata från SQL-systemvyer och matar in dem i datalagret i form av datauppsättningar. Varje datauppsättning skapas med hjälp av data från en eller flera SQL-systemvyer. För varje datauppsättning finns det en separat tabell i datalagret.

Datainsamling

Database Watcher samlar in övervakningsdata med jämna mellanrum med hjälp av T-SQL-frågor. Data som samlas in vid varje körning av en sökfråga kallas för ett prov. Exempelinsamlingsfrekvensen varierar beroende på datauppsättning. Till exempel kan data som ändras ofta, till exempel SQL-prestandaräknare, samlas in var 10:e sekund, medan mestadels statiska data som databaskonfiguration kan samlas in var femte minut. Mer information finns i Datauppsättningar.

Database watcher drar nytta av streaming-ingestion i Azure Data Explorer och Real-Time Analytics i Microsoft Fabric för att möjliggöra övervakning i nära realtid. Vanligtvis blir insamlade SQL-övervakningsdata tillgängliga för rapportering och analys på mindre än 10 sekunder. Du kan övervaka latensen för datainmatning på databasövervakaren instrumentpaneler, med hjälp av länken Inmatningsstatistik.

Interaktion mellan databasskådare och programarbetsbelastningar

Det är inte troligt att aktivering av databasövervakare har en märkbar inverkan på programmets arbetsbelastningsprestanda. Vanligare övervakningsfrågor körs vanligtvis i intervallet under sekunden, medan frågor som kan kräva mer tid, till exempel för att returnera stora datamängder, körs med sällan förekommande intervall.

USE master;
GO

CREATE OR ALTER FUNCTION dbo.dbw_classifier()
RETURNS sysname
WITH SCHEMABINDING
AS
BEGIN

DECLARE @WorkloadGroupName sysname = 'default';

IF APP_NAME() IN (N'SQLExternalMonitoring',N'x_ms_reserved_sql_external_monitoring')
    SET @WorkloadGroupName = N'database_watcher_workload_group'

RETURN @WorkloadGroupName;

END;
GO

BEGIN TRY

IF EXISTS (
          SELECT 1
          FROM sys.resource_governor_configuration
          WHERE classifier_function_id <> 0 OR is_enabled <> 0
          )
    THROW 50001, 'A resource governor configuration is already present. No changes were made.', 1;

CREATE RESOURCE POOL database_watcher_resource_pool
WITH (MIN_CPU_PERCENT = 5, MAX_CPU_PERCENT = 10, CAP_CPU_PERCENT = 30);

CREATE WORKLOAD GROUP database_watcher_workload_group
WITH (REQUEST_MAX_MEMORY_GRANT_PERCENT = 10)
USING database_watcher_resource_pool;

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.dbw_classifier);

ALTER RESOURCE GOVERNOR RECONFIGURE;

END TRY
BEGIN CATCH
    THROW;
END CATCH;

För att undvika samtidighetskonflikter som blockeringar och dödlägen mellan datainsamling och databasarbetsbelastningar som körs på dina Azure SQL-resurser använder övervakningsfrågorna korta låstidsgränser och låg dödlägesprioritet. Om det finns en samtidighetskonflikt ges prioritet till programarbetsbelastningsfrågorna.

Du kan observera luckor i insamlade data i följande scenarier:

• Om den totala resursanvändningen är hög eller om samtidighetskonflikter uppstår mellan övervakningsfrågor och programarbetsbelastningar. I dessa fall deprioriteras övervakningsfrågor till förmån för programarbetsbelastningar.
• Om du har automatisering som avslutar långvariga sessioner. Undvik luckor i insamlade data genom att exkludera alla sessioner där program_name kolumnen i sys.dm_exec_sessions systemvyn är SQLExternalMonitoring eller x_ms_reserved_sql_external_monitoring.

Datainsamling i elastiska pooler

Om du vill övervaka en elastisk pool måste du ange en databas i poolen som den ankardatabasen. En bevakare ansluter till fästpunktsdatabasen. Eftersom bevakaren har behörigheten VIEW SERVER PERFORMANCE STATE ger systemvyer i ankardatabasen övervakningsdata för hela poolen.

Data som samlas in från ankardatabasen innehåller mått på poolnivå och vissa prestandamått på databasnivå för varje databas i poolen, till exempel resursanvändning och mått för begärandefrekvens för varje databas. För vissa scenarier kan det göra det onödigt att övervaka varje enskild databas i poolen genom att lägga till ett SQL-mål för elastisk pool för att övervaka en elastisk pool som helhet.

Vissa övervakningsdata som processor på poolnivå, minne, lagringsanvändning och väntestatistik samlas bara in på elastisk poolnivå eftersom de inte kan hänföras till en enskild databas i en pool. Omvänt är vissa andra data, till exempel frågekörningsstatistik, databasegenskaper, tabell- och indexmetadata, endast tillgängliga om du lägger till enskilda databaser som SQL-mål.

Om du lägger till enskilda databaser från en elastisk pool som SQL-mål bör du även lägga till den elastiska poolen som ETT SQL-mål. På så sätt får du en mer fullständig vy över databasens och poolens prestanda.

Övervaka kompakta elastiska pooler

En kompakt elastisk pool innehåller ett stort antal databaser, men har en relativt liten beräkningsstorlek. Med den här konfigurationen kan kunderna uppnå betydande kostnadsbesparingar genom att hålla beräkningsresursallokeringen till ett minimum.

Det är viktigt att den här metoden förutsätter att endast ett litet antal databaser i poolen har frågor som körs samtidigt.

Om du vill övervaka en tät elastisk pool aktiverar du övervakning på poolnivå genom att lägga till den elastiska poolen som ett SQL-mål. Genom att minska det totala antalet övervakningsfrågor i den elastiska poolen undviker du risken för att påverka programarbetsbelastningar, samtidigt som du samlar in åtgärdsbara data på poolnivå i sql-datauppsättningarna för elastiska pooler.

Datainsamling i serverlösa databaser

Om en serverlös databas har automatisk paus inaktiverad, övervakar databasbevakaren den precis som en etablerad databas.

Om du aktiverar automatisk paus på en serverlös databas, stoppas databasövervakningsinsamlingen när databasen pausas. Övervakningsfrågor för databasbevakare förhindrar inte att en serverlös databas pausas om den är berättigad att pausas annars.

Kort efter att en serverlös databas övergår till ett pausat tillstånd ändras dess status på instrumentpanelen för visningssammanfattning till Inte samla in. Tidigare insamlade data för databasen finns kvar i bevakardatalagret och är tillgängliga via instrumentpaneler och frågor.

Datainsamlingen återupptas inom några minuter efter att databasen har övergått från läget Pausad till Online .

Datalagringsplats

Kunder kan välja att lagra insamlade SQL-övervakningsdata i någon av tre typer av datalager:

• En databas i ett Azure Data Explorer kluster. Som standard skapas ett nytt Azure Data Explorer-kluster för varje ny bevakare och finns i samma Azure-region som bevakaren.

  Kunder kan välja den specifika Azure-regionen i ett Azure-geografiskt område som plats för sitt Azure Data Explorer-kluster och databasen. Mer information om datareplikeringsfunktioner i Azure Data Explorer finns i Översikt över affärskontinuitet och haveriberedskap.

• En databas i ett kostnadsfritt Azure Data Explorer-kluster.

  Kunder kan välja den specifika Azure-geografin, men inte den specifika Azure-regionen som plats för sitt kostnadsfria Azure Data Explorer-kluster och databasen. Datareplikering till en annan region eller geografi stöds inte.

• En databas i Real-Time Analytics i Microsoft Fabric.

  Kunder kan inte välja databasens geografiska plats.

För att fullständigt kontrollera datahemvist för insamlade SQL-övervakningsdata måste kunderna välja en databas i ett Azure Data Explorer-kluster som datalager.

Kunder kan anpassa geografin och regionen för sitt Azure Data Explorer-kluster till geografin och regionen för De Azure SQL-resurser som övervakas. När Azure SQL-resurserna finns i flera regioner kan kunderna behöva skapa flera bevakare och flera Azure Data Explorer-kluster för att uppfylla sina krav på datahemvist.

Datauppsättningar

I det här avsnittet beskrivs de datauppsättningar som är tillgängliga för varje SQL-måltyp, inklusive insamlingsfrekvenser och tabellnamn i datalagret.

Vanliga kolumner

För varje SQL-måltyp har datauppsättningar vanliga kolumner, enligt beskrivningen i följande tabeller.

En datauppsättning har både sample_time_utc och collection_time_utc kolumner om den innehåller exempel som observerats innan raden samlades in av databasskådaren. Annars är observationstiden och insamlingstiden desamma och datauppsättningen innehåller endast kolumnen sample_time_utc.

Till exempel härrör datauppsättningen sqldb_database_resource_utilization från den dynamiska hanteringsvyn sys.dm_db_resource_stats (DMV). DMV innehåller kolumnen end_time, vilket är observationstiden för varje rad som rapporterar aggregerad resursstatistik för ett intervall på 15 sekunder. Tiden rapporteras i kolumnen sample_time_utc. När en bevakare gör en förfrågan till denna DMV-tabell kan resultaten innehålla flera rader, varje med ett annorlunda end_time. Alla dessa rader har samma collection_time_utc värde.

Relaterat innehåll

• Övervaka Azure SQL-arbetsbelastningar med databasövervakare (förhandsversion)
• Snabbstart: Skapa en bevakare för att övervaka Azure SQL (förhandsversion)
• Skapa och konfigurera en bevakare (förhandsversion)
• Analysera data från databasövervakare (förhandsversion)
• Database Watcher-aviseringar (förhandsversion)
• Vanliga frågor och svar om Database Watcher