Desempenho de tabelas temporais com controle de versão do sistema e otimização de memória

  • Artigo

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores Banco de Dados SQL do AzureInstância Gerenciada de SQL do Azure

Este tópico aborda algumas considerações de desempenho específicas ao usar tabelas temporais com versão do sistema e otimização de memória.

  • Quando você adiciona controle de versão a uma tabela não temporal existente, espera impacto de desempenho nas operações de atualização e exclusão porque a tabela de histórico é atualizada automaticamente.

  • Cada atualização e exclusão é registrada na tabela de histórico otimizada na memória interna, portanto você pode experimentar consumo de memória inesperado se sua carga de trabalho usar muito essas duas operações. Portanto, aconselhamos que você faça o seguinte:

    • Não execute grandes exclusões da tabela atual para aumentar a RAM disponível limpando o espaço. Considere a exclusão de dados em vários lotes com fluxos de dados invocados manualmente entre eles invocando sp_xtp_flush_temporal_historyou enquanto SYSTEM_VERSIONING = OFF.
    • Não execute grandes atualizações de tabela de uma só vez, pois isso pode resultar em consumo de memória duas vezes maior que a quantidade de memória necessária para atualizar uma tabela de otimização de memória não temporal. O consumo duplicado de memória é temporário, pois a tarefa de liberação de dados funciona regularmente para manter o consumo de memória da tabela de preparo interna dentro dos limites projetados no estado estável (cerca de 10% do consumo de memória da tabela temporal atual). Considere a possibilidade de fazer atualizações grandes em vários lotes ou durante SYSTEM_VERSIONING = OFF, por exemplo, usando atualizações para definir os padrões de colunas recém-adicionadas.

  • O período de ativação para a tarefa de fluxo de dados não é configurável, mas você pode impor o processo invocando sp_xtp_flush_temporal_history.

  • Considere usar columnstore clusterizado como uma opção de armazenamento de tabela de histórico com base em disco, especialmente se você planeja executar análise de consultas em dados históricos que usam funções de agregação ou janelas. Nesse caso, columnstore clusterizado será uma opção ideal para a tabela de histórico, uma vez que oferece compactação de dados e o comportamento "inserção amigável" que está de acordo com a forma pela qual os dados de histórico estão senso gerados.

Consulte Também