Очевидно, ответ таков: «Когда вы определяете статью, вам нужно установить для параметра @vertical_partition значение true, а затем добавить нужные столбцы с помощью sp_articlecolumn."
Однако я должен спросить, почему ты это делаешь. Репликация, на мой взгляд, не является общим инструментом для перемещения данных между разными базами данных, но для синхронизации двух идентичных баз данных.
Другие идеи мозгового штурма:
- Вы можете создать новую исходную таблицу, которая соответствует целевой таблице, и использовать триггер для синхронизации исходной таблицы.
- Переместите исходную таблицу без изменений в пункт назначения и выполните MERGE в базе данных назначения.
- Репликация не может быть правильным решением, здесь. Каковы бизнес-правила и требования, которые требуют этого? Рассматривали ли вы использование SSIS?
- Если необходимо, чтобы две таблицы постоянно находились в точной синхронизации, тогда каков канал изменений исходной таблицы - приложения? Похоже, что вашему приложению нужен новый уровень абстракции, уровень записи данных, который знает, как писать в два источника одновременно.
Проблема синхронизации данных между двумя различными базами данных может быть проблемой. Могут быть все виды тонких проблем с условиями гонки, отсутствием распределенных транзакций (влияющих на согласованность и реакцию на сбои), проблемами с обходными путями, созданными для решения проблемы отсутствия распределенных транзакций, и так далее, и так далее. Можно ли вместо этого создать связанный сервер и некоторые представления, которые фактически обеспечивают доступ к данным в одной базе данных в реальном времени из другой?
Пожалуйста, расскажите нам больше о ваших требованиях и о том, почему вам нужно это сделать.
Update
Если вы собираетесь указать маршрут обновления вручную, вы не можете применять операции вставки, обновления и удаления периода времени в массовом порядке. Вы должны применять их по одному, в порядке . Если вместо этого вы работаете с текущим состоянием , а не с промежуточными операциями с данными, то вы можете выполнять все строки одновременно. Я покажу вам пример MERGE, а не историю воспроизведения.
BEGIN TRAN;
DELETE D
FROM LinkedServer.dbo.Dest D WITH (TABLOCKX, HOLDLOCK)
WHERE
NOT EXISTS (
SELECT *
FROM Source S
WHERE D.Key = S.Key
);
UPDATE D
SET
D.Col1 = S.Col4,
D.Col2 = S.Col5,
D.Col3 = S.Col6,
D.Col4 = S.Col7,
FROM
LinkedServer.dbo.Dest D
INNER JOIN Source S ON D.Key = S.Key
WHERE
D.Col1 <> S.Col4
OR EXISTS (
SELECT D.Col2, D.Col4
EXCEPT
SELECT S.Col3, S.Col6
); -- or some other way to handle comparison of nullable columns
INSERT LinkedServer.dbo.Dest (Col1, Col2, Col3)
SELECT Col4, Col5, Col6
FROM Source S WITH (TABLOCK, HOLDLOCK)
WHERE
NOT EXISTS (
SELECT *
FROM LinkedServer.dbo.Dest D
WHERE S.Key = D.Key
);
COMMIT TRAN;
Может оказаться, что лучше перенести всю таблицу и выполнить операцию слияния на конечном сервере.
Подсказки на блокировку, которые я вставил в первый запрос, важны, если вы хотите получить согласованный моментальный снимок на определенный момент времени. Если вас это не волнует, уберите подсказки о блокировке.
Если вы обнаружите, что обновления на связанном сервере выполняются медленно, поместите всю таблицу в один фрагмент во временную промежуточную таблицу на удаленном сервере и выполните MERGE в сценарии полностью на удаленном сервере.