SQL 2016 SQL Server Assertion: File: <pageref.cpp>, line=951 Failed Assertion

Olhando para o KB, você tem algumas opções/soluções alternativas:

1. Mude para o modelo de recuperação COMPLETA. Você diz "isso não é muito uma opção para um warehouse", mas na verdade é apenas uma questão de configurar os backups do log de transações regularmente, por exemplo, 15 minutos e depois descartá-los. SSIS/Planos de manutenção têm tarefas de estoque para fazer isso . Você perderá transações registradas em massa, mas nunca achei que elas fizessem uma grande diferença nos tempos de execução, apenas no tamanho do log. Você pode até fazer backup do log para nulo, o que não descreverei aqui. Se você não tiver certeza do que fazer, pergunte ao seu DBA local. O espaço em disco e a retenção de backup do log de transações são problemas mais fáceis de resolver do que erros fatais. Quando esse problema for resolvido, você poderá voltar.
2. A KB menciona "várias instruções BULK INSERT em uma única transação distribuída". Não está claro na sua pergunta como suas inserções em massa são configuradas. Você está usando o SSIS para executar tarefas 'Execute SQL' que usam oMERGEcomando? O que significa 'multiple BULK INSERTs' aqui? Existe uma maneira de converter sua abordagem em BULK INSERTs únicos, um de cada vez, por exemplo? No SSIS, você pode definir 'MaxConcurrentExecutables' como 1 temporariamente, por exemplo, veja se isso ajuda. Vincule-o a uma variável de configuração para que você possa alterá-lo novamente mais tarde. Obviamente, isso vai desacelerar as coisas, mas você prefere que seu ETL termine em vez de falhar rapidamente. Fazer as coisas em paralelo é um bom padrão e uma força real do SSIS, mas você só pode ir tão rápido quanto seu componente mais lento; digamos que você tenha 10 dimensões que levam um minuto e um fato que leva uma hora, seu ETL termina em uma hora em execução paralela ou 1 hora e 10 minutos em série.
3. MERGEé bom, mas tem alguns problemas. Você pode considerar a conversão de volta para INSERT/ UPDATE. Além disso, você deve usar HOLDLOCKwith MERGEde acordo com aqui . Você usa essa dica? Faz alguma diferença para este problema se você fizer isso? Tivemos um problema em uma versão inicial do SQL 2014 em que o uso MERGEcom DML ( OUTPUTcláusula) combinável em columnstore causava esse tipo de afirmação - fiz com que retirassem os índices columnstore das dimensões, que eles adicionaram sem me avisar.
4. Que tipo de tratamento de transação você está fazendo? Às vezes, com ETL, a posição é repetível apenas executando novamente. Às vezes, você precisa que ele falhe e retroceda. Como você implementou isso? Pode ser alterado para que não seja "transação distribuída única"?

Boa sorte.

Acredito que isso tenha sido resolvido em 2016 SP1 CU1.

Especificamente por KB3205964

Isso é corrigido aplicando a atualização cumulativa 1 (CU1) para MSSQL2016, consulte o link https://support.microsoft.com/en-us/kb/3164674

Acredito que encontramos outra solução alternativa. Estou postando minha resposta porque acho que pode ser útil e é diferente o suficiente da sugestão de wBob.

Alteramos a parte insert da instrução merge para que ela seja inserida em uma tabela temporária em vez do destino original.

Depois que a instrução merge é executada, inserimos da tabela # no destino.

Não é o ideal, mas pelo menos a mesclagem ainda lida com a complexidade do 'upsert' marcando as linhas que foram retiradas/expiradas.

Descobrimos que essa é uma compensação aceitável em comparação com reescrever completamente a mesclagem como inserções e atualizações separadas.

CREATE TABLE #Activity(
[ETL_ActivitySurrogateKey] [int] IDENTITY(1,1) NOT NULL,
[Field1] [varchar](255) NULL,
)

-- Insert statements for procedure here
INSERT INTO #Activity ( [Field1],2,3,etc )

SELECT [Field1],2,3,etc
FROM 
(
    MERGE [DDS_OZ_CC].[dimActivity] AS target 
    USING (
      SELECT [Field1],2,3,etc
      FROM [STAGE_OZ_CC].[Transform_Activity]
      ) as source
    ON
    (
      target.RowIsCurrent = source.RowIsCurrent
         AND target.[Field1] = source.[Field1]
    )
    WHEN MATCHED 
        AND (        
        EXISTS (SELECT target.Level5Id EXCEPT SELECT source.Level5Id)
    )
    THEN
      UPDATE SET 
        ETL_ValidToDateTime = source.ETL_ValidFromDateTime 
       ,ETL_RowIsCurrent = 0 
       ,ETL_LastTouchedBy = source.ETL_LastTouchedBy 
       ,ETL_RowChangeReason = 'SCD2 Retired' 

    WHEN NOT MATCHED THEN 
    INSERT 
    (    
     [Field1],2,3,etc
    )
    VALUES (      
      source.[Field1],2,3,etc
    )
       WHEN NOT MATCHED BY SOURCE AND target.ETL_RowIsCurrent = 1
       THEN UPDATE SET
       ETL_RowIsCurrent = 0 
       ,ETL_RowChangeReason = 'Fact Removed' 
       ,ETL_LastTouchedBy = 'Unknown'

  OUTPUT
    $action      
      ,source.[Field1],2,3,etc    

  ) AS MergeOutput
  (
    action  
    ,[Field1],2,3,etc   
  ) 

  WHERE ACTION = 'UPDATE' AND ETL_RowIsCurrent = 1

    INSERT INTO [DDS_OZ_CC].[dimActivity]
    ( [Field1],2,3,etc  )
    SELECT [Field1],2,3,etc
    FROM #Activity

    END