Partager via

Statistiques persistantes pour les secondaires lisibles

S’applique à : SQL Server 2025 (17.x) Azure SQL Database

Le Magasin des requêtes pour les secondaires lisibles est disponible dans SQL Server 2025 (17.x) et Azure SQL Database, et les statistiques persistantes pour les fichiers secondaires lisibles utilisent l’infrastructure que le Magasin des requêtes a en place pour les secondaires lisibles.

Le Magasin des requêtes pour les secondaires lisibles est activé par défaut dans SQL Server 2025 (17.x) et Azure SQL Database.

Background

Sur les réplicas secondaires lisibles, les statistiques peuvent également être créées automatiquement lorsque l’option de création automatique de statistiques est activée, mais ces statistiques sont temporaires et disparaissent lorsqu’une instance est redémarrée. Lorsque des statistiques sur une base de données en lecture seule ou un instantané en lecture seule sont manquantes ou obsolètes, le moteur de base de données crée et gère des statistiques temporaires dans tempdb.

Lorsque le moteur de base de données crée des statistiques temporaires, le nom des statistiques est ajouté avec le suffixe _readonly_database_statistic pour différencier les statistiques temporaires des statistiques permanentes. Le suffixe _readonly_database_statistic est réservé aux statistiques générées par SQL Server. Cette approche a été adoptée pour traiter les charges de travail qui s'exécutent sur des répliques secondaires lisibles et qui peuvent nécessiter des statistiques distinctes inexistantes sur la réplique principale.

Les statistiques temporaires créées sur les réplicas secondaires restent visibles uniquement pour le réplica qui les a générés. Le réplica principal n’accède jamais directement à ces objets de statistiques temporaires et n’est conscient que de l’objet de statistiques permanent après la persistance. Lorsque les statistiques temporaires sont conservées sur le réplica principal, elles deviennent disponibles pour tous les réplicas du groupe de disponibilité via le mécanisme de synchronisation.

Le mécanisme de persistance utilise le Magasin des requêtes pour l’infrastructure secondaire lisible introduite dans SQL Server 2022 (16.x). Les informations sur les statistiques sont envoyées au réplica principal où elles sont conservées en tant que statistiques permanentes, puis synchronisées avec tous les réplicas secondaires. Ce processus se produit automatiquement sans nécessiter d’intervention manuelle.

Prise en charge des affichages catalogues

Pour prendre en charge la comparaison de la création ou de la mise à jour des statistiques entre secondaire et principal et pour vous aider à comprendre où les statistiques ont été créées, trois nouvelles colonnes ont été ajoutées à l’affichage sys.stats catalogue :

Nom de colonne Type de données Description
replica_role_id tinyint 1 = Primaire, 2 = Secondaire, 3 = Secondaire Géographique, 4 = Secondaire HA Géographique
replica_role_desc nvarchar(60) Primaire, Secondaire, Secondaire Géographique, Secondaire HA Géographique
replica_name sysname Nom de l’instance de la réplique dans le groupe de disponibilité. NULL pour le réplica principal

Ces colonnes suivent la propriété et l’origine des statistiques tout au long du cycle de vie de persistance. Lorsqu’un réplica secondaire crée des statistiques temporaires et qu’ils sont conservés dans le réplica principal, les colonnes replica_role_id et replica_name identifient le réplica d’origine. Si ces statistiques permanentes sont ultérieurement mises à jour sur le réplica principal, la propriété est transférée au principal, ce qui est reflété dans ces colonnes.

Comportement de persistance des statistiques

Lorsque les statistiques temporaires sont conservées d’un réplica secondaire vers le réplica principal, plusieurs comportements importants se produisent : les statistiques temporaires sur le réplica secondaire ne sont pas automatiquement supprimées après la persistance. Les requêtes qui ont déclenché la création de ces statistiques temporaires continuent de les utiliser jusqu’à ce que la requête soit recompilée ou que le réplica soit redémarré. Cela signifie que les versions temporaires et permanentes des mêmes statistiques peuvent coexister temporairement.

L’optimiseur ne prend pas en compte la propriété du réplica lorsque vous déterminez s’il faut utiliser des statistiques. Elle évalue toutes les statistiques disponibles en fonction de la couverture des colonnes et des estimations de sélectivité. Les informations de réplica sont conservées principalement à des fins de suivi et de résolution des problèmes.

Un scénario notable se produit lorsque les statistiques permanentes créées à partir de statistiques temporaires deviennent obsolètes. Si des modifications significatives des données se produisent sur les principales colonnes affectées par ces statistiques, les statistiques permanentes pourraient être considérées comme périmées. Lorsque des requêtes sur des réplicas secondaires font référence à ces colonnes, le secondaire met à jour les statistiques en fonction de sa vue des données, reflétant les modifications qui ont été appliquées via le processus de restauration automatique.

En bref, la persistance ne supprime pas la capacité du secondaire à actualiser les statistiques obsolètes ; il ajoute simplement un mécanisme pour partager des statistiques entre les réplicas.

Observability

Événements étendus

persisted_stats_operation (Canal opérationnel) est déclenché pour enqueued, dequeued, processed et failed événements. Cela peut être utile pour surveiller si un message de statistiques ne peut pas être conservé sur le serveur principal, ou s'il y a un intérêt pour la surveillance de l'installation de traitement des messages. Les statistiques temporaires restent dans tempdb sur les réplicas secondaires, tandis qu’un processus en arrière-plan réessaye d’envoyer le message en cas de problème de communication entre les réplicas principal et secondaire.

  • 9131 : Fonctionnalité désactivée au démarrage de SQL.
  • 9136 : Table ou index supprimé/modifié.
  • 9137 : Schéma modifié depuis le démarrage de la transaction d’instantané ; réessayer.
  • 9139 : Statistiques trop volumineuses pour envoyer au principal.

La requête suivante peut fournir une visibilité sur les statistiques d’une table, y compris les statistiques conservées à partir de réplicas secondaires :

SELECT sch.[name] AS SchemaName,
       obj.[name] AS TableName,
       s.[name] AS StatsName,
       CASE WHEN s.stats_id >= 2 AND s.auto_created = 1 THEN 'AUTO_STATS'
            WHEN s.stats_id >= 2 AND s.auto_created = 0 THEN 'USER_CREATED_STATS'
            ELSE 'INDEX_STATS'
       END AS type,
       s.is_temporary,
       CASE WHEN s.replica_name IS NULL
                 AND s.replica_role_desc = 'PRIMARY'
                 AND s.stats_id >= 2
                 AND s.auto_created = 1
                 THEN 'PRIMARY'
            ELSE s.replica_name
       END AS replica_name,
       s.replica_role_id,
       s.replica_role_desc
FROM sys.schemas AS sch
     INNER JOIN sys.objects AS obj
         ON sch.schema_id = obj.schema_id
     INNER JOIN sys.stats AS s
         ON obj.object_id = s.object_id
WHERE sch.[name] <> 'sys'
ORDER BY sch.[name], obj.[name], s.stats_id;

Considérations

Les statistiques persistantes pour les fonctionnalités secondaires lisibles sont activées par défaut tant que l’option de création automatique des statistiques est activée et que les READABLE_SECONDARY_TEMPORARY_STATS_AUTO_CREATEREADABLE_SECONDARY_TEMPORARY_STATS_AUTO_UPDATE options de configuration délimitées à la base de données sont activées, c’est-à-dire la configuration par défaut. Il n’existe aucune configuration délimitée à la base de données pour activer et désactiver la fonctionnalité.

Contenu connexe

  • Last updated on