Considérations pour la réplication transactionnelle
Il existe un certain nombre de points à prendre en compte pour la réplication transactionnelle :
Espace du journal des transactions.
Espace disque pour la base de données de distribution.
Clés primaires pour chaque table publiée.
Déclencheurs.
Types de données LOB (Large object).
Abonnements pouvant être mis à jour (s'ils sont utilisés). Pour plus d'informations sur les points à prendre en compte pour les abonnements pouvant être mis à jour, consultez Abonnements pouvant être mis à jour pour la réplication transactionnelle.
Espace du journal des transactions
Assurez-vous que l'espace alloué au journal des transactions de chaque base de données qui sera publiée à l'aide de la réplication transactionnelle est suffisant. Le journal des transactions d'une base de données publiée peut nécessiter plus de place que celui d'une base identique non publiée, parce que les enregistrements du journal ne sont pas tronqués tant qu'ils n'ont pas été déplacés vers la base de données de distribution.
Lorsque la base de données de distribution n'est pas disponible, ou que l'Agent de lecture du journal n'est pas actif, le journal des transactions d'une base de données de publication continue à se remplir. Le journal ne peut pas être tronqué à partir de la plus ancienne transaction publiée non encore livrée à la base de données de distribution. Nous vous recommandons de définir le fichier journal des transactions avec l'option d'étendue automatique, afin que le journal puisse s'accommoder de ces circonstances. Pour plus d'informations, consultez CREATE DATABASE (Transact-SQL) et ALTER DATABASE (Transact-SQL).
Nous vous recommandons de sélectionner l'option sync with backup sur la base de données de distribution, ce qui suspend la troncature du journal sur la base de données de publication jusqu'à ce que les transactions correspondantes dans la base de données de distribution aient été sauvegardées. Il en résulte que le journal des transactions est plus volumineux dans la base de données de distribution. Pour plus d'informations sur cette option, consultez Stratégies de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée.
Espace disque pour la base de données de distribution
Assurez-vous que vous avez suffisamment d'espace disque pour stocker les transactions répliquées dans la base de données de distribution :
Si vous ne mettez pas immédiatement les fichiers de captures instantanées à la disposition des Abonnés (valeur par défaut) : les transactions sont stockées jusqu'à ce qu'elles aient été répliquées vers tous les Abonnés ou, si cette deuxième possibilité est plus courte, jusqu'à la fin de la période de rétention.
Si vous créez une publication transactionnelle et mettez immédiatement les fichiers de captures instantanées à la disposition des Abonnés : les transactions sont stockées jusqu'à ce qu'elles aient été répliquées vers tous les Abonnés ou, si cette deuxième possibilité est plus longue, jusqu'à ce que l'Agent de capture instantanée s'exécute et crée une nouvelle capture instantanée. Si le temps écoulé entre deux exécutions de l'Agent de capture instantanée est supérieur à la période de rétention de distribution maximale pour la publication, qui par défaut est de 72 heures, les transactions antérieures à la période de rétention sont supprimées de la base de données de distribution. Pour plus d'informations, consultez Expiration et désactivation des abonnements.
Bien que, grâce à la mise à disposition immédiate de la capture instantanée aux Abonnés, les nouveaux Abonnés aient accès plus rapidement à la publication, cette option peut nécessiter un espace disque plus important pour la base de données de distribution. Cela signifie également qu'une nouvelle capture instantanée est générée à chaque exécution de l'Agent de capture instantanée. Si cette option n'est pas utilisée, il n'est généré de nouvelle capture instantanée qu'en cas de nouvel abonnement.
Clés primaires pour chaque table publiée
Toutes les tables publiées dans la réplication transactionnelle doivent contenir une déclaration de clé primaire. Vous pouvez préparer les tables existantes pour la publication en ajoutant une clé primaire à l'aide de l'instruction Transact-SQLALTER TABLE (Transact-SQL).
Déclencheurs
Vous devez être conscient des problèmes suivants lorsque vous utilisez des déclencheurs sur une base de données d'abonnements :
Par défaut, les déclencheurs s'exécutent avec le paramètre XACT_ABORT défini à ON. Si une instruction dans un déclencheur provoque une erreur alors que l'Agent de distribution est en train d'appliquer des changements à l'Abonné, le traitement complet de changements échouera, et non pas seulement l'instruction incriminée. Dans une réplication transactionnelle, vous pouvez utiliser le paramètre -SkipErrors de l'Agent de distribution pour ignorer les instructions qui provoquent des erreurs. Si vous utilisez -SkipErrors avec XACT_ABORT ON, le traitement complet de changements est ignoré si une instruction provoque une erreur. À moins que vous n'ayez besoin que XACT_ABORT soit défini à ON dans les déclencheurs, nous vous recommandons de le définir à OFF si vous utilisez le paramètre -SkipErrors. Pour définir cette option à OFF, spécifiez SET XACT_ABORT OFF dans la définition du déclencheur. Pour plus d'informations sur XACT_ABORT, consultez SET XACT_ABORT (Transact-SQL). Pour plus d'informations sur le paramètre -SkipErrors, consultez Omission des erreurs lors de la réplication transactionnelle.
Nous vous déconseillons d'inclure des transactions explicites dans les déclencheurs au niveau de l'Abonné. La réplication transactionnelle groupe les transactions par traitements pour réduire le trafic sur le réseau et améliorer les performances. Si des déclencheurs comportant des instructions ROLLBACK sont ajoutés au niveau de l'Abonné, les traitements de transactions peuvent être annulés et l'erreur de serveur 266 peut se produire (Le compte des transactions après EXECUTE indique qu'il manque une instruction COMMIT ou ROLLBACK TRANSACTION. Compte précédent = %ld, compte courant = %ld.). Un traitement peut contenir des commandes de plusieurs transactions, ou faire partie d'une transaction volumineuse au niveau de l'Abonné, c'est pourquoi l'annulation de transactions risque de compromettre l'intégrité transactionnelle.
Si malgré cela vous incluez des transactions explicites, assurez-vous que toutes les instructions COMMIT d'un déclencheur sont associées à des instructions BEGIN TRANSACTION correspondantes. Une instruction COMMIT sans correspondance BEGIN TRANSACTION provoque l'application non transactionnelle des changements de lignes sur l'Abonné. En outre, un échec ultérieur peut intervenir si l'Agent de distribution rencontre l'erreur de serveur 266 et tente d'annuler une transaction ou un traitement de commandes pour pouvoir les appliquer de nouveau. Si l'agent tente d'appliquer des commandes qui ont déjà été appliquées, il provoque des échecs de clés en double.
Pour plus d'informations sur les déclencheurs, consultez Contrôle des contraintes, des identités et des déclencheurs avec l'option NOT FOR REPLICATION.
Types de données LOB (Large object)
La réplication transactionnelle prend en charge la publication des LOB et exécute des mises à jour partielles sur des colonnes LOB : si une colonne LOB est mise à jour, seul le fragment de données modifié est répliqué, et non pas toutes les données de la colonne.
Si une table publiée comporte des LOB, veillez à utiliser les paramètres suivants pour l'Agent de distribution : -UseOledbStreaming, -OledbStreamThreshold et -PacketSize. La façon la plus simple de définir ces paramètres est d'utiliser le profil d'Agent de distribution intitulé Profil de distribution pour le flux OLEDB. Pour plus d'informations, consultez Profils de l'Agent de réplication. Outre ce profil prédéfini, vous pouvez spécifier le paramètre dans un profil d'agent que vous créez ou que vous modifiez, ou sur la ligne de commande. Pour plus d'informations, consultez :
Types de données text, ntext et image
Dans le processus de réplication des types de données text, ntext et image dans une publication transactionnelle, les éléments suivants sont à prendre en compte : Nous vous recommandons d'utiliser les types de données varchar(max), nvarchar(max), varbinary(max) plutôt que text, ntext et image, respectivement.
Si cependant vous utilisez text, ntext ou image, sachez ceci :
Les instructions WRITETEXT et UPDATETEXT doivent être incluses dans des transactions explicites.
Les opérations de consignation de texte peuvent être répliquées à l'aide de WRITETEXT et UPDATETEXT avec l'option WITH LOG sur les tables publiées. L'option WITH LOG est obligatoire parce que la réplication transactionnelle enregistre les changements dans le journal des transactions.
Les opérations UPDATETEXT ne peuvent être utilisées que si tous les Abonnés sont en train d'exécuter SQL Server. Les opérations WRITETEXT sont répliquées sous forme d'instructions UPDATE, pour pouvoir être également utilisées par les Abonnés non-SQL Server.
Un paramètre configurable, max text repl size, contrôle la taille maximale (en octets) des données text, ntext, varchar(max), nvarchar(max) et image pouvant être répliquées. Ceci permet la prise en charge : des pilotes ODBC et des fournisseurs OLE DB ; des instances du moteur de base de données SQL Server ne pouvant pas traiter des valeurs de ces types de données, et les serveurs de distribution ayant des contraintes de ressources système (mémoire virtuelle). Quand une colonne d'un de ces types de données est publiée et qu'une opération INSERT, UPDATE, WRITETEXT ou UPDATETEXT est exécutée en dépassant la limite de configuration, cette opération échoue.
L'utilisation de la procédure stockée système sp_configure (Transact-SQL) permet de définir le paramètre max text repl size.
Lors de la publication de colonnes text, ntext et image, le pointeur de texte doit être récupéré dans la même transaction que l'opération UPDATETEXT ou WRITETEXT (avec la capacité de renouveler la lecture). Par exemple, ne récupérez pas le pointeur de texte dans une transaction pour l'utiliser dans une autre. Il s'est peut-être déplacé et est devenu non valide.
En outre, lorsque vous obtenez le pointeur de texte, vous ne devez pas effectuer d'opération pouvant modifier l'emplacement du texte pointé (comme la mise à jour de la clé primaire), avant d'exécuter l'instruction UPDATETEXT ou WRITETEXT.
Voici la méthode recommandée pour utiliser les opérations UPDATETEXT et WRITETEXT avec des données à répliquer :
Commencez la transaction.
Procurez-vous le pointeur de texte à l'aide de la fonction TEXTPTR() avec le niveau d'isolation REPEATABLE READ.
Utilisez le pointeur dans l'opération UPDATETEXT ou WRITETEXT.
Validez la transaction.
Notes
Si vous n'obtenez pas le pointeur dans la même transaction, les modifications sont autorisées sur le serveur de publication, mais elles ne sont pas publiées sur les Abonnés.
Par exemple :
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN DECLARE @mytextptr varbinary(16) SELECT @mytextptr = textptr(Notes) FROM Employees WHERE EmployeeID = '7' IF @mytextptr IS NOT NULL BEGIN UPDATETEXT Employees.Notes @mytextptr 0 NULL 'Terrific job this review period.' -- Dummy update to fire trigger that will update metadata and ensure the update gets propagated to other Subscribers. UPDATE Employees -- Set value equal to itself. SET Notes = Notes WHERE EmployeeID = '7' END COMMIT TRAN SET TRANSACTION ISOLATION LEVEL READ COMMITTED
Notes
Cet exemple est fondé sur la base de données Northwind, qui n'est pas installée par défaut. Pour plus d'informations sur l'installation de cette base de données, consultez Exemples de base de données Northwind et pubs sur le Centre de téléchargement Microsoft.
Lorsque vous dimensionnez les bases de données de l'Abonné, vous devez prendre en considération le fait que le pointeur de texte des colonnes text, ntext et image répliquées doit être initialisé sur les tables de l'Abonné, même lorsque celles-ci ne sont pas initialisées sur le serveur de publication. Par conséquent, chaque colonne text, ntext et image ajoutée à la table de l'Abonné par la tâche de distribution occupera environ 43 octets d'espace de stockage de base de données même si le contenu est vide.
Voir aussi