Arrêter de répliquer les transactions importantes dans SQL Server

Question

J'ai une question sur la façon d'empêcher qu'une transaction importante chez l'éditeur soit distribuée aux abonnés. Imaginons que quelqu'un mette accidentellement à jour tous les enregistrements d'une table contenant 50 millions d'enregistrements et que, lorsqu'il se rende compte de son erreur, il rétablisse tous les enregistrements. Dans ce cas, les modifications seraient distribuées à deux abonnés dans une configuration de réplication transactionnelle. Le système indique que la réplication vers les abonnés prendra deux jours, mais quelle est la meilleure façon de résoudre ce problème ?

J'ai vu qu'il est possible, et en fait très facile, de sauter une commande en utilisant l'option de transaction xact_seqno , sp_helpsubscriptionerrors y sp_setsubscriptionxactseqno . Cependant, que se passerait-il si cela était utilisé sur une transaction en cours de distribution ? Faut-il arrêter quelque chose ?

Si ce n'est pas la meilleure façon de résoudre le problème, quelle serait-elle ?

Answer 1

Je n'ai cependant pas testé ce point en particulier : L'arrêt d'une transaction en cours, en soi, ne causera pas nécessairement de problèmes et fera marche arrière - toute sorte de transaction, y compris les transactions répliquées sur un abonné à partir d'un éditeur. Cela est dû aux propriétés ACID qui s'appliquent toujours aux transactions, en particulier, la propriété A être Atomicité - Soit tout se passe dans une transaction, soit rien ne se passe. Ainsi, une transaction arrêtée ou ayant échoué sera totalement annulée.

Je ne connais pas d'autre moyen d'empêcher la réplication de la transaction, mais il faut utiliser sp_setsubscriptionxactseqno avec prudence, car non seulement vous devez vous assurer que le LSN est correct, mais quoi qu'il arrive, cela signifie que votre éditeur et votre abonné ne sont plus vraiment synchronisés. Dans la pratique, cela peut ne pas avoir d'importance, mais il faut en tenir compte.

Si vous ne l'avez pas encore fait, jetez un coup d'oeil à Technet / MSDN (plus ou moins le même article selon que vous préférez Tnet ou devNet), si vous ne l'avez pas déjà fait, et cet article de blog sur MSDN ça va nous aider. N.B. sp_setsubscriptionxactseqno doit être exécuté sur l'abonné (et sur chaque abonné sur lequel vous voulez qu'il saute).

L'alternative, et en l'absence d'autres informations, ce que je recommanderais, c'est de le laisser fonctionner. Ce n'est peut-être pas idéal, mais c'est la solution la plus sûre et la moins coûteuse. Le système est-il à ce point critique et dépendant du temps que ces deux jours causeront des problèmes importants ?

Enfin, à titre de conseil général, si vous n'êtes pas sûr de ce que vous devez faire, laissez la décision à votre supérieur hiérarchique. Présentez les options, le travail à accomplir et les risques/impacts (y compris l'option consistant à ne rien faire), et blâmez (de manière subtile et adaptée à la politique du bureau) la personne qui a provoqué l'"accident" initial (à moins qu'il ne s'agisse de vous, auquel cas vous ne voudrez peut-être pas en parler aux supérieurs).

Answer 2

Aucun impact sur la transaction active ou non. Puisque cela n'affectera pas la façon dont une transaction fonctionne, cela ne fait que sauter cette transaction et causera des problèmes d'intégrité des données .

L'agent de lecture des journaux lit tous les enregistrements mis à jour dans l'éditeur et les met à jour dans la BD du distributeur, puis les marque comme étant validés...

Maintenant, l'agent de distribution applique toutes les commandes qui ont un horodatage plus élevé que la colonne transaction_timestamp dans la table msreplication_subscriptions.

select publisher_database_id, xact_id, xact_seqno, entry_time from msrepl_transactions order by publisher_database_id

Donc, fondamentalement, nous parlons de, comment faire pour que l'abonné commence à partir d'une autre commande ou même sauter ceux Vous pouvez utiliser la commande ci-dessous à la base de données des abonnés pour sauter cette transaction .

sp_setsubscriptionxactseqno [ @publisher = ] 'publisher'  
        , [ @publisher_db = ] 'publisher_db'  
        , [ @publication = ] 'publication'  
        , [ @xact_seqno = ] xact_seqno

Answer 3

Quelle est l'importance de l'intégrité de vos données et quelle est votre capacité de récupération ? Avec quelle taille de lot avez-vous défini votre réplication ? Vous pouvez arrêter les planificateurs et laisser le xact actuel se terminer pour ne pas avoir à effectuer un rollback sur les abonnés. Vous pouvez accéder aux tables de l'éditeur et vider les transactions, mais cela supprimera également tous les autres changements qui ont été enregistrés. Vous devrez peut-être réaligner les données par la suite. La réplication elle-même devrait avoir divisé les mises à jour en petits numéros de transaction (xact_seqno). Ensuite, vous pouvez supprimer les enregistrements des files d'attente. Assurez-vous qu'il n'y a pas de backlog dans les files d'attente elles-mêmes. 50M pourrait pousser les limites du stockage que vous avez donné aux tables de file d'attente de distribution, donc une fois que vous commencez à nettoyer par xact_secno, vérifiez qu'il n'y en a aucun qui est encore en cours d'écriture. Vous pouvez vérifier quelles commandes sont présentes et voir si elles proviennent de la même mise à jour massive ou d'une nouvelle activité. Et, soyez prêt à perdre toutes les autres réplications de données provenant d'autres tables ou de celle-ci pendant que vous le faites (selon la façon dont vous avez configuré les transactions). Et ayez un plan de réalignement pour les abonnés une fois que vous avez terminé avant de redémarrer la réplication.

Answer 4

Selon la taille de la table, l'abandon/le rajout de cet article peut être plus rapide. Comme l'instantané utilise la copie en masse pour transférer les lignes vers l'abonné, il devrait être assez rapide.