Aparentemente, la respuesta es:"Cuando definas el artículo, deberás configurar @vertical_partition parámetro a verdadero y luego agregue las columnas que desee con sp_articlecolumn ."
Sin embargo, tengo que preguntar por qué estás haciendo esto. En mi opinión, la replicación no es una herramienta general para mover datos entre bases de datos diferentes, sino para mantener sincronizadas dos bases de datos idénticas.
Otras ideas de lluvia de ideas:
- Podría crear una nueva tabla de origen que coincida con la tabla de destino y usar un disparador para mantener la tabla de origen sincronizada.
- Envíe la tabla de origen intacta al destino y realice la FUSIÓN en la base de datos de destino.
- Es posible que la replicación no sea realmente la solución correcta aquí. ¿Cuáles son las reglas comerciales y los requisitos que exigen que se haga esto? ¿Ha considerado usar SSIS?
- Si SÍ es necesario que las dos tablas estén sincronizadas todo el tiempo, ¿cuál es el canal de cambios en la tabla de origen:una aplicación? Casi parece que su aplicación necesita un nuevo nivel de abstracción, una capa de escritura de datos que sepa cómo escribir en dos fuentes al mismo tiempo.
Intentar mantener los datos sincronizados entre dos bases de datos diferentes puede ser un problema. Puede haber todo tipo de problemas sutiles con las condiciones de carrera, la falta de transacciones distribuidas (que afectan la consistencia y la respuesta a fallas), problemas con las soluciones alternativas creadas para lidiar con la falta de transacciones distribuidas, etc. ¿Puede crear un servidor vinculado y algunas vistas que realmente hagan que los datos en una base de datos sean accedidos en tiempo real desde la otra?
Cuéntenos más sobre sus requisitos y por qué necesita hacer esto.
Actualizar
Si va por la ruta de actualización manual, tenga en cuenta que no puede aplicar las operaciones de inserción, actualización y eliminación de un período de tiempo en masa. Tienes que aplicarlos uno a la vez, en orden . Si, en cambio, está trabajando con estado actual en lugar de operaciones de datos intermedias, puede hacer todas las filas a la vez. Le mostraré el ejemplo de MERGE, no el de reproducción de historial.
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;
Puede que le resulte mejor enviar toda la tabla y realizar la operación de fusión en el servidor de destino.
Las sugerencias de bloqueo que puse en la primera consulta son importantes si va a tener una instantánea coherente de un momento dado. Si no te importa eso, elimina las sugerencias de bloqueo.
Si encuentra que las actualizaciones en el servidor vinculado son lentas, envíe toda la tabla en una sola pieza a una tabla de preparación temporal en el servidor remoto y realice la FUSIÓN en un script completamente en el servidor remoto.
