Database watcher-gegevensverzameling en gegevenssets (preview)

van toepassing op:Azure SQL DatabaseAzure SQL Managed Instance-

Database watcher verzamelt bewakingsgegevens van SQL-systeemweergaven en neemt deze op in het gegevensarchief in de vorm van gegevenssets. Elke gegevensset wordt gevormd met behulp van de gegevens uit een of meer SQL-systeemweergaven. Voor elke gegevensset is er een afzonderlijke tabel in het gegevensarchief.

Dataverzameling

Database watcher verzamelt bewakingsgegevens met periodieke intervallen met behulp van T-SQL-query's. Gegevens die worden verzameld bij elke uitvoering van een query, worden een voorbeeld genoemd. Frequentie van voorbeeldverzameling verschilt per gegevensset. Het is bijvoorbeeld mogelijk dat gegevens zoals SQL-prestatiemeteritems elke 10 seconden worden verzameld, terwijl meestal statische gegevens, zoals databaseconfiguratie, elke vijf minuten worden verzameld. Zie Gegevenssets voor meer informatie.

Database watcher maakt gebruik van streamingopname in Azure Data Explorer en Real-Time Analytics in Microsoft Fabric om bijna realtime bewaking te bieden. Verzamelde SQL-bewakingsgegevens zijn doorgaans beschikbaar voor rapportage en analyse in minder dan 10 seconden. U kunt de latentie van gegevensopname op de dashboards van de database-watcher bewaken met behulp van de koppeling Gegevensopnamestatistieken .

Interactie tussen database-watcher en toepassingsworkloads

Het inschakelen van database watcher heeft waarschijnlijk geen waarneembare invloed op de prestaties van de toepassingsworkload. Meer frequente bewakingsquery's worden doorgaans uitgevoerd in het onder de seconde bereik, terwijl query's waarvoor mogelijk meer tijd nodig is, bijvoorbeeld om grote gegevenssets te retourneren, met infrequente intervallen worden uitgevoerd.

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;

Om gelijktijdigheidsconflicten, zoals blokkeren en deadlocks tussen gegevensverzameling en databaseworkloads die op uw Azure SQL-resources draaien, te voorkomen, gebruiken de bewakingsquery's korte lock timeouts en een lage deadlock prioriteit. Als er een gelijktijdigheidsconflict is, krijgen de toepassingsworkloadquery’s prioriteit.

In de volgende scenario's ziet u mogelijk hiaten in de verzamelde gegevens:

• Als het totale resourcegebruik hoog is of als gelijktijdigheidsconflicten optreden tussen bewakingsquery's en toepassingsworkloads. In deze gevallen worden monitoring queries gedeprioritiseerd ten behoeve van applicatieworkloads.
• Als u een automatiseringssysteem hebt dat langdurige sessies beëindigt. Om hiaten in verzamelde gegevens te voorkomen, sluit u een sessie uit waarin de program_name kolom in de sys.dm_exec_sessions systeemweergave is SQLExternalMonitoring of x_ms_reserved_sql_external_monitoring.

Gegevensverzameling in elastische pools

Als u een elastische pool wilt bewaken, moet u één database in de pool aanwijzen als ankerdatabase. Een watcher maakt verbinding met de ankerdatabase. Omdat de watcher de machtiging VIEW SERVER PERFORMANCE STATE, bieden systeemweergaven in de ankerdatabase bewakingsgegevens voor de pool als geheel.

Gegevens die worden verzameld uit de ankerdatabase bevatten metrische gegevens op poolniveau en bepaalde metrische gegevens op databaseniveau voor elke database in de pool, zoals resourcegebruik en metrische gegevens voor aanvraagsnelheid voor elke database. Voor sommige scenario's kan het toevoegen van een SQL-doel voor een elastische pool om een elastische pool als geheel te bewaken, het onnodig maken om elke afzonderlijke database in de pool te bewaken.

Bepaalde bewakingsgegevens, zoals CPU op poolniveau, geheugen, opslaggebruik en wachtstatistieken, worden alleen verzameld op het niveau van de elastische pool, omdat deze niet kunnen worden toegeschreven aan een afzonderlijke database in een pool. Daarentegen zijn bepaalde andere gegevens, zoals queryruntimestatistieken, database-eigenschappen, tabel- en indexmetagegevens, alleen beschikbaar als u afzonderlijke databases als SQL-doelen toevoegt.

Als u afzonderlijke databases uit een elastische pool als SQL-doelen toevoegt, moet u de elastische pool ook toevoegen als een SQL-doel. Op deze manier krijgt u een volledigere weergave van de prestaties van de database en de pool.

Dichte elastische pools bewaken

Een dichte elastische pool bevat een groot aantal databases, maar heeft een relatief kleine rekenkracht. Met deze configuratie kunnen klanten aanzienlijke kostenbesparingen realiseren door de toewijzing van rekenresources tot een minimum te beperken.

Belangrijk is dat bij deze benadering wordt ervan uitgegaan dat slechts een klein aantal databases in de pool tegelijkertijd query's uitvoert.

Als u een dichte elastische pool wilt bewaken, schakelt u bewaking op poolniveau in door de elastische pool zelf toe te voegen als een SQL-doel. Door het totale aantal bewakingsquery's in de elastische pool te verminderen, voorkomt u het risico dat dit van invloed is op toepassingsworkloads, terwijl u nog steeds bruikbare gegevens op poolniveau in de gegevenssets van de elastische SQL-pool verzamelt.

Gegevensverzameling in serverloze databases

Als een serverloze database automatisch pauzeren is uitgeschakeld, controleert de databasemonitor deze net zoals een ingerichte database.

Als u automatisch onderbreken inschakelt voor een serverloze database, stopt het verzamelen van database-watchergegevens wanneer de database wordt onderbroken. Database watcher-bewakingsqueries verhinderen niet dat een serverloze database gepauzeerd wordt als deze in aanmerking komt om gepauzeerd te worden.

Kort nadat een serverloze database is overgezet naar een onderbroken status, verandert de status op het overzichtsdashboard van de watcher in Niet verzamelen. De eerder verzamelde gegevens voor de database blijven in het watcher-gegevensarchief en zijn toegankelijk via dashboards en query's.

Het verzamelen van gegevens wordt binnen enkele minuten hervat nadat de database is overgegaan van de pausestand naar de online toestand.

Gegevensopslaglocatie

Klanten kunnen ervoor kiezen om verzamelde SQL-bewakingsgegevens op te slaan in een van de drie typen gegevensarchieven:

• Een database in een Azure Data Explorer-cluster . Er wordt standaard een nieuw Azure Data Explorer-cluster gemaakt voor elke nieuwe watcher en bevindt zich in dezelfde Azure-regio als de watcher.

  Klanten kunnen de specifieke Azure-regio in een Azure-geografie kiezen als de locatie van hun Azure Data Explorer-cluster en de database. Zie het overzicht van bedrijfscontinuïteit en herstel na noodgevallen voor meer informatie over mogelijkheden voor gegevensreplicatie in Azure Data Explorer.

• Een database op een gratis Azure Data Explorer-cluster.

  Klanten kunnen de specifieke Azure-geografie kiezen, maar niet de specifieke Azure-regio als de locatie van hun gratis Azure Data Explorer-cluster en de database. Gegevensreplicatie naar een andere regio of geografie wordt niet ondersteund.

• Een database in Real-Time Analytics in Microsoft Fabric.

  Klanten kunnen de geografische locatie van de database niet kiezen.

Om de gegevenslocatie voor verzamelde SQL-bewakingsgegevens volledig te beheren, moeten klanten een database kiezen in een Azure Data Explorer-cluster als het gegevensarchief.

Klanten kunnen de geografie en regio van hun Azure Data Explorer-cluster afstemmen op de geografie en regio van de Azure SQL-resources die worden bewaakt. Wanneer de Azure SQL-resources zich in meerdere regio's bevinden, moeten klanten mogelijk meerdere watchers en meerdere Azure Data Explorer-clusters maken om te voldoen aan hun vereisten voor gegevenslocatie.

Gegevensverzamelingen

In deze sectie worden de gegevenssets beschreven die beschikbaar zijn voor elk SQL-doeltype, inclusief verzamelingsfrequenties en tabelnamen in het gegevensarchief.

Algemene kolommen

Voor elk TYPE SQL-doel hebben gegevenssets gemeenschappelijke kolommen, zoals beschreven in de volgende tabellen.

Een gegevensset bevat zowel sample_time_utc- als collection_time_utc-kolommen als het voorbeelden bevat die zijn waargenomen voordat de rij door databasewatcher is verzameld. Anders zijn de observatietijd en verzamelingstijd hetzelfde en bevat de gegevensset alleen de sample_time_utc kolom.

De gegevensset wordt bijvoorbeeld sqldb_database_resource_utilization afgeleid van de sys.dm_db_resource_stats dynamische beheerweergave (DMV). De DMV bevat de end_time kolom, die de observatietijd voor elke rij toont, waarbij de verzamelde resource-statistieken gedurende een interval van 15 seconden worden gerapporteerd. Deze tijd wordt gerapporteerd in de sample_time_utc kolom. Wanneer een watcher deze DMV opvraagt, kan de resultatenset meerdere rijen bevatten, elk met een andere end_time. Al deze rijen hebben dezelfde collection_time_utc waarde.

Verwante inhoud

• Azure SQL-workloads bewaken met databasemonitor (voorbeeldversie)
• Quickstart: Een watcher maken om Azure SQL te bewaken (preview)
• Een watcher maken en configureren (preview)
• Bewakingsgegevens van database-watcher analyseren (preview)
• Database Watcher-waarschuwingen (preview)
• Veelgestelde vragen over Database Watcher