Partager via

Optimiser les performances des bases de données mises en miroir à partir de SQL Server

Cet article comprend des étapes importantes pour optimiser les performances de la base de données source et de la base de données mise en miroir à partir de SQL Server dans Microsoft Fabric.

Contrôler les performances de l’analyse

Lorsque la mise en miroir est activée sur des tables d’une base de données, un processus d’analyse capture régulièrement les modifications en collectant le journal des transactions. Ce processus commence au LSN de la transaction validée non répliquée la plus ancienne et analyse les transactions répliquées N-1 suivantes, où N représente le nombre de transactions spécifiées à l’aide du @maxtrans paramètre dans sys.sp_change_feed_configure_parameters. La maxtrans valeur du paramètre indique le nombre maximal de transactions à traiter dans chaque cycle d’analyse.

Dans les situations où la latence d’analyse est très élevée, l’utilisation d’une valeur plus élevée maxtrans peut être avantageuse, tandis que dans les cas impliquant des transactions partiellement répliquées ou relativement volumineuses, un paramètre inférieur maxtrans peut être préférable. La fonctionnalité de transactions maximales dynamiques simplifie ce processus en déterminant automatiquement la valeur optimale maxtrans pendant chaque analyse en fonction d’autres facteurs tels que l’utilisation du journal, la latence d’analyse et la charge de travail. Lorsque le paramètre de dynamicmaxtrans flux de modification est activé, Fabric ajuste dynamiquement le paramètre maxtrans, ce qui garantit des performances d’analyse optimales.

Vérifiez le paramètre de la fonctionnalité de transactions maximales dynamiques avec sys.sp_help_change_feed_settings, ou utilisez repl_logscan_dynamic_maxtrans un événement étendu pour surveiller les valeurs d’exécution de chaque analyse.

Pour activer la fonctionnalité de transactions maximales dynamiques, définie sur @dynamicmaxtrans1. Par exemple:

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
  @dynamicmaxtrans=1;

Pour modifier les limites maximales et inférieures pour la fonctionnalité de transactions maximales dynamiques, utilisez @maxtrans et @dynamicmaxtranslowerbound utilisez respectivement. Par exemple:

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters
  @dynamicmaxtrans=1
, @dynamicmaxtranslowerbound=5
, @maxtrans=5000;

Considérations relatives au paramètre de transactions maximales dynamiques

La fonctionnalité de transactions maximales dynamiques est activée par défaut dans SQL Server 2025. La fonctionnalité de transactions maximales dynamiques est activée et ne peut pas être gérée ou désactivée dans Azure SQL Database et Azure SQL Managed Instance.

Lorsque le nombre maximal dynamique est activé, la mise en miroir traite jusqu’à 10 000 transactions (par défaut) ou la valeur maximale configurée des transactions pendant la phase d’analyse du journal. Pour éviter que cette phase ne s’exécute trop longtemps, un délai d’expiration de trois minutes est appliqué. Toutes les transactions traitées avant l’expiration du délai d’expiration sont publiées dans la base de données mise en miroir, et les transactions restantes seront capturées lors de l’analyse suivante.

Les valeurs optimales pour la fonctionnalité de transactions maximales dynamiques varient en fonction de la charge de travail, de la latence et d’autres facteurs. Envisagez d’activer la fonctionnalité maxtrans dynamique lorsque la latence est plus élevée que souhaitée et transaction_count , dans chaque lot, est supérieure au paramètre lié inférieur (200, par défaut). Cela peut être surveillé à l’aide de la latency colonne dans sys.dm_change_feed_log_scan_sessions ou à l’aide de l’événement repl_logscan_dynamic_maxtrans étendu pour voir si le current_maxtransmaxtrans jeu atteint. Si la latence est toujours élevée, envisagez d’augmenter la maxtrans limite supérieure à l’aide de sys.sp_help_change_feed_settings.

Utilisez l’événement repl_logscan_dynamic_maxtrans étendu pour surveiller si des délais d’expiration se produisent fréquemment. Le champ prev_phase2_scan_termination_reason aura une valeur LogScanTerminationReason_MaxScanDurationReached lorsqu’un délai d’expiration de l’analyse se produit. Envisagez de maxtrans réduire ou de désactiver le maxtrans dynamique à l’aide de sys.sp_help_change_feed_settings si vous remarquez des délais d’expiration fréquents.

Gestionnaire de ressources pour la mise en miroir SQL Server

Dans SQL Server 2025, vous pouvez créer un pool resource governor pour gérer et limiter la charge de travail de mise en miroir Fabric sur votre serveur SQL Server. Vous pouvez utiliser resource governor pour gérer la consommation des ressources du moteur de base de données et appliquer des stratégies pour les charges de travail utilisateur. Resource Governor vous permet de réserver ou de limiter différentes ressources serveur, notamment la quantité d’UC, de mémoire et d’E/S physiques que les charges de travail de requête utilisateur peuvent utiliser. De cette façon, vous pouvez protéger vos charges de travail métier principales contre la pression de la collecte de données de flux de modification de Fabric Mirroring. Pour plus d’informations, consultez Resource Governor.

Pour commencer à configurer des groupes de charges de travail dans SQL Server 2025 pour la mise en miroir Fabric, utilisez les exemples de script et d’instructions suivants.

  • Vous pouvez choisir n’importe quel nom pour le RESOURCE POOL.
  • Cet exemple de script configure une limite pour un pourcentage souhaité d’UC pour permettre la mise en miroir fabric. L’exemple suivant utilise 50 50 pour cent. Cette valeur est la bande passante processeur moyenne maximale que toutes les requêtes du pool de ressources peuvent recevoir lorsqu’il existe une contention du processeur. Utilisez une valeur inférieure pour limiter davantage la mise en miroir Fabric.
  • Les WORKLOAD GROUP noms doivent correspondre aux valeurs de l’exemple de script. Chaque groupe de charge de travail est destiné à une phase spécifique de la mise en miroir. Chaque groupe de charges de travail peut se trouver dans le même pool ou un pool différent en fonction de la façon dont vous planifiez vos pools et charges de travail Resource Governor.
  • Avant de configurer le gouverneur de ressources pour la première fois sur votre instance SQL Server, passez en revue attentivement la documentation resource governor, des exemples et des meilleures pratiques.
--Create resource pool for Fabric mirroring
CREATE RESOURCE POOL [ChangeFeedPool] WITH (MAX_CPU_PERCENT = 50);

--Create workload groups for Fabric mirroring. Do not modify.
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_snapshot_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_capture_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_publish_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_commit_group] USING [ChangeFeedPool];
CREATE WORKLOAD GROUP [x_ms_reserved_changefeed_notification_group] USING [ChangeFeedPool];

Pour appliquer les modifications et activer le gouverneur de ressources, comme d’habitude :

ALTER RESOURCE GOVERNOR RECONFIGURE

Contenu connexe

  • Last updated on