MERGE rodando lentamente

Criei instruções MERGE para transferir diferenças com um conjunto mínimo de colunas necessárias do banco de dados de produção para um banco de dados de teste. As tabelas mescladas são planejadas para serem usadas por diferentes cenários de relatório e análise (somente leitura). Todo o processo de obter as diferenças nas tabelas de teste deve ser rápido (pelo menos muito mais rápido do que a maneira atual de obter todo o conteúdo da tabela todos os dias fazendo um DELETE seguido de INSERT INTO para todos os dados, independentemente da quantidade de fato dados alterados que estimo em cerca de 5%).

Aqui está uma amostra:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET NOCOUNT ON

IF NOT exists(select 1 from StagingDB.sys.tables t join StagingDB.sys.schemas s on t.schema_id = s.schema_id WHERE t.name like 'A' and s.name like 'staging') 
BEGIN
        SELECT Top 0 [ID],[OID]
        INTO [StagingDB].[staging].[A]
        From [LiveDB].[dbo].[A];
END;

MERGE INTO [StagingDB].[staging].[A] AS Target
USING ( 
    SELECT [ID], [OID] From [LiveDB].[dbo].[A] where X = 0
) AS Source ([ID],[OID])
ON (Target.[ID] = Source.[ID])
WHEN MATCHED AND (Target.[OID] <> Source.[OID]) THEN
    UPDATE SET [OID] = Source.[OID]
WHEN NOT MATCHED BY TARGET  THEN
    INSERT([ID],[OID]) VALUES(Source.[ID],Source.[OID])
WHEN NOT MATCHED BY SOURCE THEN 
    DELETE;


IF NOT EXISTS(
    SELECT * FROM sys.indexes ix Where ix.name = 'PK_A' AND ix.object_id = OBJECT_ID('[StagingDB].[staging].[A]')
)
BEGIN
        ALTER TABLE [StagingDB].[staging].[A] add constraint PK_A primary key CLUSTERED ([ID])
END

Isso é executado MUITO RAPIDAMENTE para a maioria das minhas tabelas. Infelizmente, existem duas tabelas que têm muito mais linhas e, além disso, muito mais colunas dessas duas tabelas estão sendo usadas posteriormente no processo de geração de relatórios, portanto, tenho que transferir muito mais dados.

Embora eu possa executar esse tipo de comando de mesclagem para 71 tabelas em menos de um minuto, as duas instruções MERGE problemáticas são executadas por cerca de 2 horas cada. Ainda não consegui descobrir o porquê.

Desconfio da quantidade de datas, mas também da forma como comparo as diferenças das tabelas. Para descobrir se devo executar uma instrução UPDATE, faço uma comparação para cada coluna incluída na instrução Merge. Portanto, caso eu tenha 10 colunas, a condição UPDATE do MERGE fica assim:

WHEN MATCHED AND (Target.[OID] <> Source.[OID] OR Target.[OID1] <> Source.[OID2]  OR Target.[Text1] <> Source.[Text1] OR Target.[varcharlong1] <> Source.[varcharlong1] )  etc...

Acontece que esse tipo de verificação de condição de atualização inclui todas as colunas e não terá um índice. As tabelas de preparação sempre têm uma chave primária agrupada em identificador único e (até agora) nenhum índice adicional.

Minha pergunta é: embora a instrução MERGE esteja sendo executada de maneira muito rápida e eficiente para a maioria de nossas tabelas, parece que esse procedimento não é adequado para as duas tabelas maiores, incluindo várias colunas. Estou usando a instrução MERGE corretamente neste caso usando a cláusula OR para garantir que as linhas precisem ser atualizadas ou existe uma maneira melhor? Existe uma maneira melhor de obter rapidamente o delta (alterações) para um subconjunto de colunas em uma tabela de preparo? todas as minhas tabelas têm um ROWVERSION, talvez isso possa ser usado para descobrir as linhas que foram alteradas de alguma forma?