XML rápido, XML lento

Nosso aplicativo Windows de atualização de banco de dados precisa transferir alguns dados entre dois bancos de dados como parte do processo para uma determinada atualização única. Escolhi o XML como intermediário para mover os dados.

O processo funciona selecionando um bloco de linhas da origem como XML, que é passado pelo aplicativo para o servidor de destino, onde é fragmentado em uma tabela temporária global. (Os bancos de dados de origem e destino podem estar em 2 instâncias diferentes.) Esse processo se repete até que todos os dados necessários estejam na tabela temporária da instância de destino. Por fim, os registros da tabela temporária são consolidados na tabela de banco de dados de destino real.

O problema que estamos tendo é que, em algumas situações, o segundo bloco é extremamente lento, com uso muito alto da CPU e simplesmente não leva a lugar nenhum. Conseguimos reproduzir o problema em nosso ambiente de hospedagem, mas não no desenvolvedor ou no controle de qualidade. Alguns de nossos clientes também estão tendo esse problema - um deles o deixou rodar durante a noite e finalmente o desligou na manhã seguinte, depois de rodar por 18 (!) horas. Nesse caso, não tenho certeza de quanto avançou; Não consigo passar da segunda parte da hospedagem depois de esperar cerca de 2 horas.

Este é o lote de instruções para o primeiro bloco:

SET NOCOUNT ON;

DECLARE @src xml;
SET @src = CAST(@P1 AS xml);

SELECT
    n.x.value(N'field1[1]', 'uniqueidentifier') AS field1,
    n.x.value(N'field2[1]', 'smallint') AS field2,
    ... (8 more fields of various types) ...
    INTO [##target_2994] /*******/
    FROM @src.nodes('Rows[1]/Row') n(x);

E este é o lote para o segundo e subseqüentes pedaços, que é o problema:

SET NOCOUNT ON;

DECLARE @src xml;
SET @src = CAST(@P1 AS xml);

INSERT INTO [dbo].[##target_2994] /*******/
    SELECT
        n.x.value(N'field1[1]', 'uniqueidentifier') AS field1,
        n.x.value(N'field2[1]', 'smallint') AS field2,
        ... (8 more fields of various types) ...
        FROM @src.nodes('Rows[1]/Row') n(x);

Aqui está o que eu olhei até agora:

• Não é um problema de bloqueio: as estatísticas de espera são de 99% SOS_SCHEDULER_YIELDna INSERTinstrução.
• sys.dm_io_virtual_file_statsno alvo tempdbmostra que está basicamente ocioso, então não é um problema de E/S.
• Todos os dados têm apenas colunas de largura fixa, portanto, não há campos de texto muito longos.
• O tamanho do bloco de dados é atualmente de 25.000 linhas e podemos reduzi-lo, mas isso não explica a diferença porque testamos com alguns dos mesmos conjuntos de dados perfeitamente. A maior tabela necessária para ser transferida é de aproximadamente 725.000 linhas, o que testou bem.
• Os planos de consulta são idênticos* entre problema e sem problema (fiz uma comparação de arquivo do XML).
• As opções de sessão SETsão as mesmas entre problema e sem problema.
• A versão não parece ser um fator: a hospedagem é 2008 R2 SP1 Enterprise x64; testamos sem problemas em 2005 SP4+ Standard x64 até 2008 R2 SP1+ Developer x86. Os clientes com problemas são 2008 RTM/SP1 Standard/Enterprise x64 (até agora).
• A virtualização não parece ser um fator: hospedagem e controle de qualidade são virtualizados; dev é parcialmente virtualizado; clientes com problemas são físicos. MAXDOPnão está definido para nenhum dos nossos servidores (max = 4 processadores lógicos); Não tenho certeza sobre as configurações dos clientes.
• Os dois bancos de dados que estão no mesmo servidor versus servidores diferentes não fazem diferença.
• Executar o aplicativo de atualização em uma caixa TS versus localmente não faz diferença.
• As configurações do banco de dados Tempdb são idênticas.
• Os agrupamentos de instância e banco de dados são idênticos.
• Alterar o nível de compatibilidade do tempdb no servidor de destino para 90 não ajudou. (Por resposta de Mark )
• Não há diferenças significativas na configuração da instância. (Por resposta de Jimbo )

Alguém pode sugerir outras coisas para olhar?

_{* As expressões calculadas receberam nomes diferentes e houve uma diferença < 1% em um dos tamanhos de linha estimados, mas todo o resto foi o mesmo, incluindo as estimativas de custo geral.}