Транзакционная репликация – мощная функция в SQL Server, которая позволяет реплицировать данные из одной базы данных в другую практически в режиме реального времени. Однако иногда могут возникать проблемы, когда схема подписчика не синхронизируется со схемой издателя после добавления столбца в издателе. Это может вызвать несоответствия данных и ошибки в процессе репликации.

Чтобы отслеживать и предотвращать возникновение этой проблемы, можно предпринять несколько шагов. Во-первых, важно отслеживать журналы и сравнивать схемы издателя и подписчика при синхронизации репликации. Это поможет определить, когда происходит несоответствие схемы и позволит устранить проблему.

Давайте рассмотрим тестовый пример, чтобы понять, как мы можем устранить проблему и предотвратить ее возникновение. Мы создадим тестовую таблицу в тестовой среде и установим для нее транзакционную репликацию в другую тестовую среду:

CREATE TABLE tblPubSubTest(
    OurIDColumn INT,
    OurVCColumn VARCHAR(100),
    ColumnWeDropped VARCHAR(1)
)

INSERT INTO tblPubSubTest
VALUES (1,'One','1'),
       (2,'Two','2')

После настройки репликации между издателем и подписчиком давайте удалим столбец в таблице подписчика, который в настоящее время реплицируется, не удаляя его в издателе. Затем добавим еще одно значение в издателе:

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

В таблице MSdistribution_history в базе данных распределения вы увидите две ошибки, если еще реплицируются записи. Эти ошибки указывают на то, что столбец в таблице подписчика был удален:

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

Сравнивая временные метки ошибок и изменения DDL в таблице MSdistribution_history, вы можете определить, когда произошло несоответствие схемы и, возможно, определить причину проблемы. Кроме того, отслеживание схем издателя и подписчика с использованием INFORMATION_SCHEMA может помочь предотвратить и обнаружить эти проблемы.

Для сред, которые публикуют полные таблицы, вы можете использовать следующий запрос для проверки количества столбцов от источника к назначению:

SELECT
    p.publication AS PublicationName,
    pubs.srvname AS SourceServer,
    subs.srvname AS DestinationServer,
    p.publisher_db AS SourceDatabase,
    s.subscriber_db AS DestinationDatabase,
    a.source_owner AS SourceSchema,
    CASE
        WHEN a.destination_owner IS NULL THEN a.source_owner 
        ELSE a.destination_owner
    END AS DestinationSchema,
    a.source_object AS SourceTable,
    a.destination_object AS DestinationTable,
    '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 SourceCheck,
    '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 DestinationCheck
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

Установка оповещений о несоответствии схемы или использование таблицы конфигурации для проверки схем с использованием INFORMATION_SCHEMA поможет вам обнаружить и предотвратить эти проблемы. Запуск этих проверок до и после выпуска, развертывания или изменения может гарантировать соответствие схем и бесперебойную репликацию.

Следуя этим шагам и отслеживая схемы издателя и подписчика, вы можете эффективно предотвратить и устранить проблемы с транзакционной репликацией SQL Server.