Tabelas temporais versionadas pelo sistema com tabelas otimizadas para memória

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

As tabelas temporais versionadas para sistemas para tabelas otimizadas para memória proporcionam uma solução económica para cenários em que são necessárias auditoria de dados e análise temporal pontual sobre dados recolhidos com cargas de trabalho OLTP em memória.

Note

As tabelas temporais com otimização de memória só estão disponíveis no SQL Server e na Instância Gerenciada SQL do Azure. Tabelas com otimização de memória e tabelas temporais estão disponíveis independentemente no Banco de Dados SQL do Azure.

Overview

As tabelas temporais versionadas pelo sistema mantêm automaticamente um histórico completo das alterações de dados e expõem extensões de Transact-SQL convenientes para análise point-in-time. Num cenário típico, o histórico de dados é mantido durante muito tempo (vários meses, até anos), mesmo que não seja consultado regularmente.

A auditoria de dados e a análise baseada no tempo podem ser exigidas em diferentes ambientes, especialmente em sistemas OLTP que processam um número extremamente elevado de pedidos e onde é utilizada tecnologia OLTP em memória. No entanto, o uso de tabelas otimizadas para memória em cenários temporais é um desafio porque uma enorme quantidade de dados históricos gerados geralmente excede o limite de RAM disponível. Ao mesmo tempo, usar a RAM para armazenar dados históricos somente leitura que são acessados com menos frequência à medida que envelhecem não é uma solução ideal.

Tabelas temporais versões do sistema para tabelas otimizadas para memória proporcionam alta taxa de transferência e concorrência sem bloqueios. Pode armazenar uma grande quantidade de dados históricos usando tabelas em memória para armazenar dados atuais (a tabela temporal) e tabelas em disco para dados históricos. O efeito nas operações DML é reduzido usando uma tabela de preparo interna otimizada para memória gerada automaticamente que armazena o histórico recente e permite que DMLs sejam executadas a partir de código compilado nativamente.

O diagrama a seguir ilustra essa arquitetura.

Diagrama da arquitetura in-memory temporal.

Detalhes da implementação

Ao criar uma tabela com versão do sistema otimizada para memória, esteja ciente das seguintes considerações. Para opções de sintaxe e para um exemplo, veja CREATE TABLE.

  • Somente tabelas com otimização de memória durável podem ser versionadas pelo sistema (DURABILITY = SCHEMA_AND_DATA).

  • A tabela de histórico de uma tabela com versões geridas pelo sistema otimizada para a memória tem de ser baseada em disco, quer seja criada por si quer pelo sistema.

  • Podes usar consultas que afetam apenas a tabela atual em memória em módulos T-SQL compilados nativamente. Módulos compilados nativamente não suportam a FOR SYSTEM TIME cláusula, mas consultas ad hoc e módulos não nativos podem usar a cláusula contra tabelas otimizadas para memória.

  • Com SYSTEM_VERSIONING = ON, o sistema cria automaticamente uma tabela interna de staging otimizada para memória para aceitar as alterações mais recentes versionadas pelo sistema, que resultam de operações de atualização e eliminação numa tabela otimizada para memória atual.

  • Uma tarefa de limpeza de dados assíncrona move regularmente os dados da tabela interna de staging otimizada para memória para a tabela de histórico baseada em disco. Esse mecanismo de liberação de dados mantém os buffers de memória interna em menos de 10% do consumo de memória de seus objetos pai. Pode acompanhar o consumo total de memória de uma tabela temporal otimizada para a memória e versão do sistema, consultando sys.dm_db_xtp_memory_consumers e resumindo os dados para a tabela interna de estágios otimizada para memória e para a tabela temporal atual.

  • Para realizar manualmente uma limpeza de dados, execute sp_xtp_flush_temporal_history.

  • Com SYSTEM_VERSIONING = OFF, ou quando modifica o esquema de uma tabela com versão controlada pelo sistema, adicionando, eliminando ou alterando colunas, todo o conteúdo do buffer interno de preparação é transferido para a tabela de histórico em disco.

  • A consulta de dados históricos está efetivamente sob o nível de isolamento de instantâneo e sempre retorna uma união entre o buffer de preparação em memória e a tabela em disco sem duplicatas.

  • ALTER TABLE As operações que alteram internamente o esquema da tabela têm de realizar uma limpeza de dados, o que pode prolongar a operação.

A tabela de estágio otimizada para memória interna

O sistema cria uma tabela de preparação interna otimizada para memória para otimizar as operações DML.

  • O nome da tabela utiliza o seguinte formato: Memory_Optimized_History_Table_<object_id> onde <object_id> é o identificador da tabela temporal atual.

  • A tabela replica o esquema da tabela temporal atual mais uma coluna bigint . Esta coluna extra garante a unicidade das linhas movidas para o buffer interno de histórico.

  • A coluna extra tem o seguinte formato de nome: Change_ID[<suffix>], onde <suffix> é opcionalmente adicionado no caso de a tabela já ter uma coluna Change_ID.

  • O tamanho máximo da linha para uma tabela com versão do sistema e otimização de memória é reduzido em 8 bytes devido à coluna bigint extra na tabela de preparação. O máximo é agora de 8.052 bytes.

  • A tabela interna de staging otimizada para memória não aparece no Object Explorer do SQL Server Management Studio.

  • Pode encontrar metadados sobre esta tabela e a sua ligação com a tabela temporal atual em sys.internal_tables.

A tarefa de liberação de dados

A tarefa de limpeza de dados executa-se regularmente e verifica se alguma tabela otimizada para memória cumpre uma condição baseada no tamanho da memória para o movimento de dados. A movimentação de dados começa quando o consumo de memória da tabela interna de preparação atinge oito por cento do consumo de memória da tabela temporal corrente.

A tarefa de liberação de dados é ativada regularmente com um cronograma que varia de acordo com a carga de trabalho existente. Com uma carga de trabalho pesada, a tarefa é executada a cada 5 segundos. Com uma carga de trabalho leve, a frequência sobe para cada minuto. Um thread é gerado para cada tabela de preparo interna otimizada para memória que precisa de limpeza.

O esvaziamento de dados exclui todos os registos do buffer interno em memória que são mais antigos do que a transação mais antiga atualmente em execução, de modo a mover esses registos para a tabela de histórico baseada em disco.

Você pode executar uma liberação de dados executando sp_xtp_flush_temporal_history e especificando o esquema e o nome da tabela:

EXEC sys.sp_xtp_flush_temporal_history <schema_name>, <object_name>;

O mesmo processo de movimentação de dados é invocado assim como quando o sistema executa a tarefa de esvaziamento de dados na sua agenda interna.