Partager via

Amélioration des performances de réplication de fusion

  • Article

Mis à jour : 12 décembre 2006

Après avoir considéré les conseils en matière de performances qui sont décrits dans la rubrique Amélioration des performances générales de la réplication, considérez ces autres aspects spécifiques à la réplication de fusion.

Création de bases de données

  • Colonnes d'index utilisées dans des filtres de lignes et des filtres de jointure.
    Si vous utilisez un filtre de ligne sur un article publié, créez un index sur chacune des colonnes utilisées dans la clause WHERE du filtre. S'il n'y a pas d'index, Microsoft SQL Server doit lire chaque ligne de la table pour déterminer si la ligne doit être incluse dans la partition. Avec un index, SQL Server peut localiser rapidement les lignes à inclure. Le traitement le plus rapide s'effectue si la réplication peut résoudre complètement la clause WHERE du filtre à partir de l'index seul.
    L'indexation de toutes les colonnes utilisées dans des filtres de jointure est également importante. À chaque exécution, l'Agent de fusion recherche dans la table de base quelles lignes de la table parente et quelles lignes des tables associées sont incluses dans une partition. La création d'un index sur les colonnes jointes dispense SQL Server de devoir lire chaque ligne de la table à chaque exécution de l'Agent de fusion.
    Pour plus d'informations sur le filtrage, consultez Filtrage des données publiées en vue de la réplication de fusion.
  • Envisagez de surnormaliser les tables qui incluent des types de données LOB.
    Lors d'une synchronisation, l'Agent de fusion peut avoir besoin de lire et de transférer la totalité de la ligne de données à partir d'un serveur de publication ou d'un Abonné. Si la ligne contient des colonnes utilisant des données de type LOB, ce processus peut nécessiter un surcroît d'allocation de mémoire et nuire aux performances, même si ces colonnes peuvent ne pas avoir été mises à jour. Pour limiter la probabilité d'une perte de performance, vous pouvez envisager de placer les colonnes LOB dans une table indépendante en les reliant aux autres données de la ligne avec une relation un-à-un. Les types de données text, ntext et image sont abandonnés. Si vous incluez des données de type LOB, il est recommandé d'utiliser respectivement les types de données varchar(max), nvarchar(max), varbinary(max).

Conception de la publication

  • Utilisez un niveau de compatibilité de publication de 90RTM (SQL Server 2005).
    À moins qu'un ou plusieurs Abonnés utilisent une version différente de SQL Server, spécifiez que la publication doit prendre en charge seulement SQL Server 2005. Ceci permet à la publication de bénéficier des nouvelles fonctionnalités et optimisations des performances. Pour plus d'informations, consultez la section « Niveau de compatibilité pour les publications de fusion » de la rubrique Utilisation de plusieurs versions de SQL Server dans une topologie de réplication.
  • Utilisez les paramètres de rétention de publication appropriés.
    La période de rétention de publication, qui est la quantité maximale de temps avant qu'un abonnement doive être synchronisé, détermine le temps pendant lequel les métadonnées de suivi sont stockées. Une valeur élevée peut affecter les performances en matière de stockage et de traitement. Pour plus d'informations sur la définition de la période de rétention des publications, consultez Expiration et désactivation des abonnements.
  • Utilisez des articles en téléchargement seulement sur les tables qui sont modifiées seulement sur le serveur de publication. Pour plus d'informations, consultez Optimisation des performances de la réplication de fusion avec les articles en téléchargement seul.

Conception et utilisation des filtres

  • Limitez la complexité des clauses des filtres de lignes.
    La limitation de la complexité des critères de filtrage permet un gain de performance lorsque l'Agent de fusion évalue les modifications de lignes à envoyer aux Abonnés. Évitez l'utilisation de sous-sélections dans les clauses des filtres de lignes de fusion. Envisagez plutôt l'utilisation de filtres de jointure, généralement plus efficaces pour le partitionnement des données d'une table à partir de la clause de filtre de ligne d'une autre table. Pour plus d'informations sur le filtrage, consultez Filtrage des données publiées en vue de la réplication de fusion.
  • Utilisez des partitions précalculées avec des filtres paramétrés (cette fonctionnalité est utilisée par défaut). Pour plus d'informations, consultez Optimisation des performances des filtres paramétrés avec des partitions précalculées.
    Les partitions précalculées imposent plusieurs limitations au fonctionnement du filtrage. Si votre application ne peut pas s'adapter à ces limitations, définissez l'option keep_partition_changes à True, ce qui permet d'obtenir un gain de performances. Pour plus d'informations, consultez Filtres de lignes paramétrés.
  • Utilisez des partitions qui ne se chevauchent pas si les données sont filtrées mais pas partagées entre les utilisateurs.
    La réplication peut optimiser les performances pour les données qui ne sont pas partagées entre des partitions ou des abonnements. Pour plus d'informations, consultez Filtres de lignes paramétrés.
  • Ne créez pas de hiérarchies de filtres de jointure complexes.
    Les filtres de jointure avec cinq tables ou plus peuvent avoir un impact significatif sur les performances lors du processus de fusion. Il est recommandé d'envisager d'autres solutions si vous générez des filtres de jointure impliquant cinq tables ou plus :
    • Évitez de filtrer les tables qui sont essentiellement des tables de recherche, des tables de taille réduite et des tables qui ne font pas l'objet de modifications. Intégrez ces tables dans la publication dans leur globalité. Il est recommandé d'utiliser des filtres de jointure seulement entre des tables qui doivent être partitionnées entre des Abonnés. Pour plus d'informations, consultez Filtres de jointure.
    • Envisagez la dénormalisation du design de la base de données ou l'utilisation d'une table de mappage s'il y a un grand nombre de tables dans une jointure. Par exemple, si un commercial a seulement besoin des données relatives à ses clients mais que six jointures sont nécessaires pour associer un client avec un commercial, envisagez d'ajouter une colonne à la table des clients pour identifier le commercial. Les données du commercial sont alors redondantes, mais les coûts liés à la dénormalisation des tables peuvent être compensés par les gains de performance pour le partitionnement de la réplication.
    • Pour améliorer les performances des partitions précalculées lorsque des lots contiennent un grand nombre de données modifiées, concevez votre application avec soin. Assurez-vous que les modifications apportées aux données de la table parente dans un filtre de jointure ont lieu avant les modifications correspondantes dans les tables enfants.
  • Définissez l'option join_unique_key à 1 si la logique le permet.
    La définition de ce paramètre à 1 indique que la relation entre les tables enfants et parent dans un filtre de jointure est « un à un » ou « un à plusieurs ». Définissez ce paramètre à 1 seulement si vous avez une contrainte sur la colonne de jointure dans la table enfant qui garantit l'unicité. Si ce paramètre est incorrectement défini à 1, il peut se produire une non-convergence des données. Pour plus d'informations, consultez Filtres de jointure.
  • Évitez d'exécuter des lots avec un grand nombre de modifications lorsque vous utilisez des partitions précalculées.
    Lorsque vous exécutez l'Agent de fusion après avoir exécuté un lot avec un grand nombre de données modifiées, l'agent tente de scinder le lot en question en lots plus petits. Au cours de cette opération, d'autres processus de l'Agent de fusion peuvent être bloqués. Si possible, réduisez le nombre de modifications dans un lot et exécutez l'Agent de fusion entre les lots. Si cela est impossible, augmentez la valeur generation_leveling_threshold de la publication.

Considérations sur les abonnements

Paramètres de l'Agent de fusion

  • Mettez à niveau tous les Abonnés pour les abonnements par extraction de données (pull) vers SQL Server 2005.
    La mise à niveau de l'Abonné vers SQL Server 2005 met à niveau l'Agent de fusion utilisé par les abonnements sur cet Abonné. Pour tirer parti des nombreuses nouvelles fonctionnalités et optimisations des performances, l'Agent de fusion SQL Server 2005 est requis.
  • Si un abonnement est synchronisé via une connexion rapide et que des modifications sont envoyées depuis le serveur de publication et depuis l'Abonné, utilisez le paramètre –ParallelUploadDownload pour l'Agent de fusion.
    SQL Server 2005 a un nouveau paramètre pour l'Agent de fusion : –ParallelUploadDownload. La définition de ce paramètre permet à l'Agent de fusion de traiter en parallèle les modifications chargées vers le serveur de publication et celles qui sont téléchargées vers l'Abonné. Ceci est utile dans les environnements où les volumes sont élevés, avec une bande passante réseau élevée. Les paramètres des agents peuvent être spécifiés dans des profils d'agent et sur la ligne de commande. Pour plus d'informations, consultez :
  • Lorsque vous synchroniser des lignes de données avec une grande quantité de données (par exemple, des lignes avec des colonnes LOB), la synchronisation Web peur exiger une allocation supplémentaire de mémoire et nuire aux performances. Cette situation se produit lorsque l'Agent de fusion génère un message XML qui contient trop de lignes de données avec de gros volumes de données. Si l'Agent de fusion consomme trop de ressources lors de la synchronisation Web, réduisez le nombre de lignes transmises dans un seul message de l'une des manières suivantes :
    • Utilisez le profil de liaison lente de l'Agent de fusion. Pour plus d'informations, consultez Profils de l'Agent de réplication.
    • Diminuez les paramètres -DownloadGenerationsPerBatch et -UploadGenerationsPerBatch de l'Agent de fusion à une valeur de 10 ou moins. La valeur par défaut de ces paramètres est 50.

Considérations sur les captures instantanées

  • Créez une colonne ROWGUIDCOL sur les grandes tables avant la génération de la capture instantanée initiale.
    La réplication de fusion exige que chaque table publiée possède une colonne ROWGUIDCOL. Si aucune colonne ROWGUIDCOL n'existe dans la table avant que l'Agent Capture instantanée ne crée les premiers fichiers de capture instantanée, l'Agent doit tout d'abord ajouter et remplir la colonne ROWGUIDCOL. Pour bénéficier d'une amélioration des performances lors de la génération de captures instantanées, créez la colonne ROWGUIDCOL sur chaque table avant de procéder à la publication. La colonne peut porter n'importe quel nom (le rowguid est utilisé par défaut par l'Agent de capture instantanée), mais elle doit présenter les caractéristiques suivantes du point de vue des types de données :
    • Un type de données UNIQUEIDENTIFIER.
    • Une valeur par défaut NEWSEQUENTIALID() ou NEWID(). NEWSEQUENTIALID() est recommandée car elle peut améliorer les performances lorsque des modifications sont effectuées et suivies.
    • La propriété ROWGUIDCOL définie.
    • un index unique sur la colonne.
  • Prégénérez des captures instantanées et/ou permettez aux Abonnés de demander la génération et l'application d'une capture instantanée la première fois qu'ils se synchronisent.
    Utilisez l'une ou l'autre de ces options ou les deux pour fournir des captures instantanées pour les publications qui utilisent des filtres paramétrés. Si vous ne spécifiez pas une de ces options, les abonnements sont initialisés à l'aide d'une série d'instructions SELECT et INSERT au lieu d'utiliser l'utilitaire bcp, ce processus étant beaucoup plus lent. Pour plus d'informations, consultez Captures instantanées des publications de fusion avec des filtres paramétrés.

Considérations sur la maintenance et sur l'analyse

  • Réindexez occasionnellement les tables système d'une réplication de fusion
    Dans le cadre de la gestion d'une réplication de fusion, contrôlez de temps en temps le développement des tables système associées à cette réplication : MSmerge_contents, MSmerge_genhistory, MSmerge_tombstone, MSmerge_current_partition_mappings et MSmerge_past_partition_mappings. Réindexez périodiquement ces tables. Pour plus d'informations, consultez Réorganisation et reconstruction d'index.
  • Analysez les performances de la synchronisation à l'aide de l'onglet Historique de synchronisation dans le moniteur de réplication.
    Pour la réplication de fusion, le moniteur de réplication affiche des statistiques détaillées dans l'onglet Historique de synchronisation pour chaque article traité lors de la synchronisation, notamment la quantité de temps passé dans chaque phase du traitement (chargement des modifications, téléchargement des modifications, etc.). Il peut être utile d'identifier les tables spécifiques qui provoquent les ralentissements ; il s'agit du meilleur observatoire pour résoudre les problèmes de performance avec les abonnements de fusion. Pour plus d'informations sur l'affichage des statistiques détaillées, consultez Procédure : afficher des informations et effectuer des tâches pour les agents associés à un abonnement (Moniteur de réplication).

Voir aussi

Concepts

Amélioration des performances de la réplication

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

12 décembre 2006
Nouveau contenu :
  • Ajout de recommandations de performance sur l'exécution de lots volumineux à l'aide de partitions précalculées.

17 juillet 2006
Nouveau contenu :
  • Ajout de recommandations concernant les performances de la synchronisation de données d'objets volumineux par synchronisation Web.