Collection de données et jeux de données de l’observateur de base de données (préversion)

S’applique à :Azure SQL DatabaseAzure SQL Managed Instance

L’observateur de base de données collecte les données de monitoring à partir des vues système SQL et les ingère dans le magasin de données sous la forme de jeux de données. Chaque jeu de données est formé à l’aide des données d’une ou plusieurs vues système SQL. Le magasin de données comporte une table distincte pour chaque jeu de données.

Collection de données

L’observateur de base de données collecte des données de monitoring à intervalles réguliers à l’aide de requêtes T-SQL. Les données collectées lors de chaque exécution d’une requête sont appelées échantillon. La fréquence de collection d’échantillon varie selon le jeu de données. Par exemple, les données changeant fréquemment telles que les compteurs de performance SQL peuvent être collectées toutes les 10 secondes, tandis que les données statiques telles que la configuration de la base de données peuvent être collectées toutes les cinq minutes. Pour en savoir plus, consultez Jeux de données.

L’observateur de base de données tire parti de l’ingestion en streaming dans Azure Data Explorer et Real-Time Analytics dans Microsoft Fabric pour fournir un monitoring en quasi-temps réel. En général, les données de monitoring SQL collectées sont disponibles pour le reporting et l’analyse en moins de 10 secondes. Vous pouvez monitorer la latence d’ingestion des données sur les tableaux de bord de l’observateur de base de données, à l’aide du lien Statistiques d’ingestion.

Interactions entre l’observateur de base de données et les charges de travail d’application

L’activation de l’observateur de base de données n’a probablement pas d’impact observable sur les performances des charges de travail d’application. Les requêtes de monitoring les plus fréquentes s’exécutent généralement sous la seconde, tandis que les requêtes qui pourraient nécessiter plus de temps, par exemple pour renvoyer des jeux de données volumineux, s’exécutent à des intervalles peu fréquents.

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;

Les requêtes de monitoring permettent d’éviter les conflits d’accès concurrentiel tels que les blocages et les interblocages entre les charges de travail de collection de données et de base de données s’exécutant sur vos ressources Azure SQL à l’aide de délais d’attente de verrou courts et d’une faible priorité d’interblocage. En cas de conflit d’accès concurrentiel, la priorité est donnée aux requêtes de charge de travail d’application.

Vous pouvez observer des lacunes dans les données collectées dans les scénarios suivants :

• Si l’utilisation globale des ressources est élevée ou si des conflits d’accès concurrentiel entre les requêtes de surveillance et les charges de travail d’application se produisent. Dans ce cas, les requêtes de surveillance sont déprioritisées en faveur des charges de travail d’application.
• Si vous disposez d’une automatisation qui met fin à de longues sessions. Pour éviter les lacunes dans les données collectées, excluez toute session où la program_name colonne de la vue système sys.dm_exec_sessions est SQLExternalMonitoring ou x_ms_reserved_sql_external_monitoring.

Collection de données dans des pools élastiques

Pour monitorer un pool élastique, vous devez désigner une base de données dans le pool comme base de données d’ancrage. Un observateur se connecte à la base de données d’ancrage. Comme l’observateur détient l’autorisation VIEW SERVER PERFORMANCE STATE, les vues système de la base de données d’ancrage fournissent des données de monitoring pour le pool dans son ensemble.

Les données collectées dans la base de données d’ancrage comportent des mesures au niveau du pool et, pour chaque base de données du pool, certaines mesures de performance au niveau de la base de données, comme l’utilisation des ressources et les mesures de taux de requête par base de données. Pour certains scénarios, l’ajout d’une cible SQL de pool élastique pour monitorer un pool élastique dans son ensemble peut rendre inutile le monitoring de chaque base de données individuelle dans le pool.

Certaines données de monitoring telles que l’utilisation du processeur, de la mémoire et du stockage au niveau du pool, ainsi que les statistiques d’attente ne sont collectées qu’au niveau du pool élastique, car elles ne peuvent pas être attribuées à une base de données individuelle dans un pool. À l’inverse, certaines autres données telles que les statistiques d’exécution des requêtes, les propriétés de base de données et les métadonnées de table et d’index sont disponibles seulement si vous ajoutez des bases de données individuelles en tant que cibles SQL.

Si vous ajoutez des bases de données individuelles à partir d’un pool élastique en tant que cibles SQL, vous devez également ajouter le pool élastique en tant que cible SQL. Ainsi, vous bénéficiez d’une vue plus complète des performances de la base de données et du pool.

Monitorer des pools élastiques denses

Un pool élastique dense comporte de nombreuses bases de données, mais a une taille de calcul relativement petite. Cette configuration permet aux clients d’réaliser des économies substantielles en conservant au minimum l’allocation des ressources de calcul.

Il est important de noter que cette approche suppose que seul un petit nombre de bases de données du pool ont des requêtes en cours d’exécution en même temps.

Pour surveiller un pool élastique dense, activez la surveillance au niveau du pool en ajoutant le pool élastique lui-même en tant que cible SQL. En réduisant le nombre total de requêtes de surveillance dans le pool élastique, vous évitez le risque d’impact sur les charges de travail d’application, tout en collectant des données au niveau du pool actionnable dans les jeux de données de pool élastique SQL.

Collecte de données dans des bases de données serverless

Si une base de données serverless a l’auto-pause désactivée, l’observateur de base de données la surveille comme une base de données provisionnée.

Si vous activez la pause automatique sur une base de données serverless, la collecte de données de l’observateur de base de données s’arrête lorsque la base de données s’interrompt. Les requêtes de surveillance de l’observateur de base de données n’empêchent pas une base de données serverless d’être suspendue si elle est autrement éligible pour être mise en pause.

Peu après la transition d'une base de données serverless vers un état suspendu, son état sur le tableau de bord récapitulatif de l’observateur passe à Pas de collecte. Les données précédemment collectées pour la base de données restent dans le magasin de données observateur et sont accessibles via des tableaux de bord et des requêtes.

La collecte de données reprend en quelques minutes après la transition de la base de données de l’état suspendu vers l’état en ligne .

Résidence des données

Les clients peuvent choisir de stocker les données de monitoring SQL collectées dans l’un des trois types de magasins de données :

• Une base de données sur un cluster Azure Data Explorer. Par défaut, un nouveau cluster Azure Data Explorer est créé pour chaque observateur et se trouve dans la même région Azure que ce dernier.

  Les clients peuvent choisir la région Azure spécifique dans une zone géographique Azure comme emplacement pour leur cluster Azure Data Explorer et la base de données. Pour en savoir plus sur les fonctionnalités de réplication des données dans Azure Data Explorer, consultez Présentation de la continuité d’activité et de la reprise d’activité.

• Une base de données sur un cluster Azure Data Explorer gratuit.

  Les clients peuvent choisir la zone géographique Azure spécifique, mais pas la région Azure spécifique comme emplacement pour leur cluster Azure Data Explorer gratuit et la base de données. La réplication des données vers une autre région ou zone géographique n’est pas prise en charge.

• Une base de données dans Real-Time Analytics dans Microsoft Fabric.

  Les clients ne peuvent pas choisir l’emplacement géographique de la base de données.

Pour pleinement contrôler la résidence des données pour les données de monitoring SQL collectées, les clients doivent choisir une base de données sur un cluster Azure Data Explorer comme magasin de données.

Les clients peuvent aligner la zone géographique et la région de leur cluster Azure Data Explorer sur la zone géographique et la région des ressources Azure SQL monitorées. Lorsque les ressources Azure SQL se trouvent dans plusieurs régions, les clients peuvent avoir besoin de créer plusieurs observateurs et clusters Azure Data Explorer pour répondre à leurs besoins de résidence des données.

Jeux de données

Cette section décrit les jeux de données disponibles pour chaque type de cible SQL, y compris les fréquences de collection et les noms de table dans le magasin de données.

Colonnes courantes

Pour chaque type de cible SQL, les jeux de données comportent des colonnes courantes, comme décrit dans les tableaux suivants.

Un jeu de données comporte à la fois des colonnes sample_time_utc et collection_time_utc s’il comporte des échantillons observés avant la collection de la ligne par l’observateur de base de données. Sinon, l’heure d’observation et l’heure de collection sont identiques, et le jeu de données ne comporte que la colonne sample_time_utc.

Par exemple, le jeu de données sqldb_database_resource_utilization est dérivé de la vue de gestion dynamique (DMV) sys.dm_db_resource_stats. La DMV comporte la colonne end_time, qui correspond à l’heure d’observation de chaque ligne rapportant les statistiques de ressources agrégées pour un intervalle de 15 secondes. Cette heure est rapportée dans la colonne sample_time_utc. Lorsqu'un veilleur interroge cette DMV, le jeu de résultats peut contenir plusieurs lignes, chacune avec une valeur différente end_time. Toutes ces lignes ont la même valeur collection_time_utc.

Contenu associé

• Surveiller les charges de travail Azure SQL avec l’observateur de base de données (préversion)
• Démarrage rapide : Créer un observateur pour surveiller Azure SQL (préversion)
• Créer et configurer un surveillant (aperçu)
• Analyser les données de monitoring de l’observateur de base de données (préversion)
• Alertes de l’observateur de base de données (préversion)
• FAQ sur l’observateur de base de données