La réplication transactionnelle est une fonctionnalité puissante dans SQL Server qui vous permet de répliquer des données d’une base de données à une autre en quasi temps réel. Cependant, des problèmes peuvent parfois survenir lorsque le schéma de l’abonné n’est pas synchronisé avec le schéma de l’éditeur après l’ajout d’une colonne à l’éditeur. Cela peut entraîner des incohérences de données et des erreurs dans le processus de réplication.

Pour suivre et prévenir ce problème, vous pouvez suivre quelques étapes. Tout d’abord, il est important de surveiller les journaux et de comparer les schémas de l’éditeur et de l’abonné lors de la synchronisation de la réplication. Cela peut aider à identifier quand le désaccord de schéma se produit et vous permettre de résoudre le problème.

Jetons un coup d’œil à un exemple de test pour comprendre comment nous pouvons résoudre et prévenir ce problème. Nous allons créer une table de test dans un environnement de test et la configurer pour une réplication transactionnelle vers un autre environnement de test :

CREATE TABLE tblPubSubTest(
    NotreColonneID INT,
    NotreColonneVC VARCHAR(100),
    ColonneSupprimée VARCHAR(1)
)

INSERT INTO tblPubSubTest
VALUES (1,'Un','1'),
       (2,'Deux','2')

Une fois la réplication configurée entre l’éditeur et l’abonné, supprimons une colonne sur la table de l’abonné qui est actuellement en cours de réplication sans la supprimer sur l’éditeur. Ensuite, ajoutons une autre valeur à l’éditeur :

INSERT INTO tblPubSubTest
VALUES (3,'Trois','3')

Dans la table MSdistribution_history de la base de données de distribution, vous verrez deux erreurs s’il y a encore des enregistrements en cours de réplication immédiatement. Ces erreurs indiquent que la colonne sur la table de l’abonné a été supprimée :

SELECT 
    [start_time],
    [time],
    [comments]
FROM MSdistribution_history
ORDER BY [time] DESC

En comparant les horodatages des erreurs et les modifications DDL dans la table MSdistribution_history, vous pouvez identifier quand le désaccord de schéma s’est produit et potentiellement déterminer la cause du problème. De plus, surveiller les schémas de l’éditeur et de l’abonné à l’aide de INFORMATION_SCHEMA peut aider à prévenir et détecter ces problèmes.

Pour les environnements qui publient des tables complètes, vous pouvez utiliser la requête suivante pour vérifier le nombre de colonnes de la source à la destination :

SELECT
    p.publication AS NomPublication,
    pubs.srvname AS ServeurSource,
    subs.srvname AS ServeurDestination,
    p.publisher_db AS BaseDeDonnéesSource,
    s.subscriber_db AS BaseDeDonnéesDestination,
    a.source_owner AS SchémaSource,
    CASE
        WHEN a.destination_owner IS NULL THEN a.source_owner 
        ELSE a.destination_owner
    END AS SchémaDestination,
    a.source_object AS TableSource,
    a.destination_object AS TableDestination,
    'SELECT COUNT(COLUMN_NAME) AS SourceColumnCount FROM ' + p.publisher_db + '.INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = ''' + a.source_object + ''' AND TABLE_SCHEMA = ''' + a.source_owner + '''' AS VérificationSource,
    'SELECT COUNT(COLUMN_NAME) AS SourceColumnCount FROM ' + s.subscriber_db + '.INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = ''' + a.destination_object + ''' AND TABLE_SCHEMA = ''' + CASE WHEN a.destination_owner IS NULL THEN a.source_owner ELSE a.destination_owner END  + '''' AS VérificationDestination
FROM distribution.dbo.MSarticles a
INNER JOIN distribution.dbo.MSpublications p ON a.publication_id = p.publication_id
INNER JOIN distribution.dbo.MSsubscriptions s ON s.publication_id = p.publication_id
    AND s.article_id = a.article_id
INNER JOIN master..sysservers subs ON s.subscriber_id = subs.srvid
INNER JOIN master..sysservers pubs ON s.publisher_id = pubs.srvid

La configuration d’alertes pour les désaccords de schéma ou l’utilisation d’une table de configuration pour vérifier les schémas à l’aide de INFORMATION_SCHEMA peut vous aider à détecter et prévenir ces problèmes. Exécuter ces vérifications avant et après une version, un déploiement ou un changement peut garantir que les schémas correspondent et que la réplication se poursuit sans problème.

En suivant ces étapes et en surveillant les schémas de l’éditeur et de l’abonné, vous pouvez prévenir et résoudre efficacement les problèmes de réplication transactionnelle SQL Server.