Les instructions UPDATE peuvent être répliquées en tant que paires DELETE/INSERT

Cet article décrit que les instructions Update peuvent être répliquées en tant que paires DELETE/INSERT.

Version du produit d’origine : SQL Server
Numéro de la base de connaissances d’origine : 238254

Résumé

Si une colonne faisant partie d’une contrainte unique est mise à jour, SQL Server implémente la mise à jour en tant que « mise à jour différée », ce qui signifie comme une paire d’opérationsDELETE/INSERT. Cette « mise à jour différée » entraîne l’envoi d’une paire d’instructions DELETE/INSERT aux abonnés. Il existe également d’autres situations qui peuvent entraîner une mise à jour différée. Par conséquent, toute logique métier que vous implémentez dans vos UPDATE déclencheurs ou procédures stockées personnalisées sur l’Abonné doit également être incluse dans les DELETE/INSERT déclencheurs ou les procédures stockées personnalisées.

Plus d’informations

Le comportement par défaut dans la réplication transactionnelle consiste à utiliser INSERTet UPDATEDELETE des procédures stockées personnalisées pour appliquer des modifications aux abonnés.

INSERT les instructions effectuées sur le serveur de publication sont appliquées aux abonnés par le biais d’un appel de INSERT procédure stockée. De même, une DELETE instruction est appliquée via un DELETE appel de procédure stockée.

Toutefois, lorsqu’une UPDATE instruction est exécutée en tant que « mise à jour différée », l’agent logreader place une paire d’appels de procédure stockée dans la base de données de DELETE/INSERT distribution à appliquer aux Abonnés plutôt qu’un appel de procédure stockée de mise à jour. Par exemple, supposons que vous disposez d’une table de publication, nommée TABLE1, avec les trois colonnes suivantes :

• col1 int
• col2 int
• col3 varchar(30)

La seule contrainte unique sur TABLE1 est définie sur col1 par le biais d’une contrainte de clé primaire. Supposons que vous avez un enregistrement (1,1, « Dallas »).

Lorsque vous exécutez ce code :

UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'

L’instruction UPDATE est implémentée par SQL Server en tant que paire d’instructionsINSERTDELETE/, car vous mettez à jour col1, qui a un index unique défini. Ainsi, le logreader place une paire d’appels dans la base de DELETE/INSERT données de distribution. Cela peut avoir un impact sur toute logique métier présente dans les déclencheurs ou les procédures stockées personnalisées sur l’Abonné. Vous devez incorporer la logique métier supplémentaire dans DELETE et INSERT déclencheurs ou procédures stockées pour gérer cette situation.

Si vous préférez utiliser une logique unique et que vous souhaitez que toutes vos UPDATE commandes soient répliquées sous forme DELETE/INSERT de paires, vous pouvez activer un indicateur de trace.

En outre, si vous utilisez un filtre horizontal dans votre composition et si la ligne mise à jour ne répond pas à une condition de filtre, seul un DELETE appel de procédure est envoyé aux abonnés. Si la ligne mise à jour ne répondait pas à la condition de filtre, mais qu’elle remplit la condition après la mise à jour, seul l’appel de procédure INSERT est envoyé via le processus de réplication.

Dans l’exemple précédent, supposons que vous disposez également d’un filtre horizontal défini sur TABLE1: where col3 = 'Dallas'. Si vous exécutez ce code :

UPDATE table1 set col3 = 'New York' where col1 = 3

l’agent logreader place uniquement un DELETE appel de procédure stockée à appliquer aux abonnés, car la ligne mise à jour ne répond pas aux critères de filtre horizontal.

Maintenant, si vous exécutez ce code :

UPDATE table1 set col3 = 'Dallas' where col1 = 3

le logreader génère uniquement l’appel INSERT de procédure stockée, car la ligne ne remplit pas précédemment la condition de filtre.

Bien qu’une UPDATE opération ait été effectuée sur le serveur de publication, seules les commandes appropriées sont appliquées à l’Abonné.