репликация между двумя таблицами с разными именами и с разными именами столбцов. Можно ли создать такую ​​репликацию

По-видимому, ответ таков: «Когда вы определяете статью, вам нужно установить для параметра @vertical_partition значение true, а затем добавить нужные столбцы с помощью sp_articlecolumn».

Однако я должен спросить, почему вы это делаете. На мой взгляд, репликация — это не общий инструмент для перемещения данных между разными базами данных, а для синхронизации двух идентичных баз данных.

Другие идеи мозгового штурма:

• Вы можете создать новую исходную таблицу, которая соответствует целевой таблице, и использовать триггер для синхронизации исходной таблицы.
• Переместите исходную таблицу без изменений в место назначения и выполните MERGE в базе данных назначения.
• Репликация здесь может быть не совсем правильным решением. Каковы бизнес-правила и требования, которые требуют этого? Рассматривали ли вы возможность использования SSIS?
• Если есть необходимость в постоянной точной синхронизации двух таблиц, то каков канал изменений в исходной таблице — приложение? Похоже, что вашему приложению нужен новый уровень абстракции, уровень записи данных, который знает, как писать в два источника одновременно.

Попытка синхронизировать данные между двумя разными базами данных может быть проблемой. Могут быть всевозможные тонкие проблемы с условиями гонки, отсутствием распределенных транзакций (влияющих на согласованность и реакцию на сбои), проблемы с обходными путями, созданными для решения проблем с отсутствием распределенных транзакций, и так далее и тому подобное. Можете ли вы вместо этого создать связанный сервер и несколько представлений, которые фактически обеспечивают доступ к данным в одной базе данных в режиме реального времени из другой?

Пожалуйста, расскажите нам больше о ваших требованиях и почему вам нужно это сделать.

Обновить

Если вы идете по маршруту ручного обновления, обратите внимание, что вы не можете применять операции вставки, обновления и удаления периода времени в массовом порядке. Вы должны применять их по одному, по порядку. Если вместо этого вы работаете с текущим состоянием, а не с промежуточными операциями с данными, вы можете выполнять все строки одновременно. Я покажу вам пример 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 в сценарии на удаленном сервере.