Partilhar via

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

  • Artigo

Aplica-se a: SQL Server 2016 (13.x) e posterior Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

As tabelas temporais com controle de versão do sistema para tabelas com otimização de memória são uma solução econômica para cenários nos quais há a necessidade de auditoria de dados e análise pontual sobre os dados coletados com cargas de trabalho OLTP in-memory.

Visão geral

As tabelas temporais com controle de versão do sistema mantêm um histórico completo de alterações de dados e expõem extensões Transact-SQL convenientes para a análise pontual. Em um cenário típico, o histórico de dados é retido por um período longo (vários meses, até mesmo anos), embora não seja consultado regularmente.

A auditoria de dados e a análise baseada em tempo podem ser solicitadas em ambientes diferentes, especialmente em sistemas OLTP que processam quantidades extremamente grandes de solicitações e nos quais a tecnologia de OLTP in-memory é usada. No entanto, o uso de tabelas com otimização de memória em cenários temporais é um desafio, pois uma grande quantidade de dados históricos gerados normalmente excede o limite de RAM disponível. Ao mesmo tempo, usar RAM para armazenar dados históricos somente leitura acessados com menos frequência à medida que envelhecem, não é a solução ideal.

As tabelas temporais com controle de versão do sistema para tabelas com otimização de memória fornecem alta produtividade transacional e simultaneidade sem bloqueios. Eles oferecem a capacidade de armazenar uma grande quantidade de dados históricos usando tabelas na memória para armazenar dados atuais (a tabela temporal) e tabelas baseadas em disco para dados históricos. O efeito sobre as operações DML é reduzido com o uso de uma tabela de preparo com otimização de memória interna gerada automaticamente que armazena o histórico recente e permite a execução de DMLs a partir do código compilado nativamente.

O diagrama a seguir ilustra essa arquitetura.

Diagrama da arquitetura temporal na memória.

Detalhes de implementação

Ao criar uma tabela com otimização de memória com controle de versão do sistema, lembre-se das considerações a seguir. Para obter opções de sintaxe e um exemplo, confira CREATE TABLE.

  • Apenas as tabelas com otimização de memória duráveis podem ter controle de versão do sistema (DURABILITY = SCHEMA_AND_DATA).

  • A tabela de histórico para a tabela com controle da versão do sistema com otimização de memória deve ter base em disco, independentemente de ter sido criada pelo usuário final ou o sistema.

  • Consultas que afetam apenas a tabela atual na memória podem ser usadas em módulos T-SQL compilados nativamente. Não há suporte a consultas temporais usando a cláusula FOR SYSTEM TIME em módulos compilados nativamente. O uso da cláusula FOR SYSTEM TIME com tabelas com otimização de memória em consultas ad hoc e módulos não nativos é possível.

  • Quando SYSTEM_VERSIONING = ON, uma tabela interna de preparo com otimização de memória é criada automaticamente para aceitar as alterações de versão do sistema mais recentes, as quais resultam de operações de atualização e exclusão na tabela atual com otimização de memória.

  • Dados da tabela interna de preparo com otimização de memória são movidos regularmente para a tabela de histórico com base em disco por uma tarefa de limpeza de dados assíncrona. Esse mecanismo de liberação de dados tem o objetivo de manter os buffers internos da memória em menos de 10% do consumo de memória de seus objetos pai. Você pode acompanhar o consumo total de memória da tabela temporal com controle de versão do sistema com otimização de memória consultando sys.dm_db_xtp_memory_consumers e resumindo os dados da tabela interna de preparo com otimização de memória e a tabela temporal atual.

  • É possível executar uma liberação de dados manualmente executando sp_xtp_flush_temporal_history.

  • Quando SYSTEM_VERSIONING = OFF ou quando o esquema da tabela com controle de versão do sistema é modificado pela adição, remoção ou alteração de colunas, todo o conteúdo do buffer de preparo interno é movido para a tabela de histórico com base em disco.

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

  • As operações ALTER TABLE que alteram o esquema da tabela internamente devem executar uma limpeza de dados, o que pode prolongar a duração da operação.

A tabela de preparo com otimização de memória interna

O sistema cria uma tabela de preparo com otimização de memória interna para otimizar operações DML.

  • O nome da tabela é gerado no 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. Essa coluna extra garante a exclusividade das linhas movidas para o buffer de histórico interno.

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

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

  • A tabela de preparo interna com otimização de memória não é representada no Pesquisador de Objetos do SQL Server Management Studio.

  • Os metadados sobre essa tabela, bem como sua conexão com a tabela temporal atual, podem ser encontrados em sys.internal_tables.

A tarefa de limpeza de dados

A limpeza de dados é uma tarefa ativada regularmente que verifica se alguma tabela com otimização de memória atende a uma condição de memória baseada no tamanho para movimentação de dados. A movimentação de dados começa quando o consumo de memória da tabela de preparo interna atinge 8% do consumo de memória da tabela temporal atual.

A tarefa de limpeza de dados será ativada regularmente com uma agenda que varia com base na 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 aumenta a cada minuto. Um thread é gerado para cada tabela de preparo interna com otimização de memória que precisa de limpeza.

A limpeza de dados exclui todos os registros de buffer interno de memória mais antigos do que a transação mais antiga em execução no momento para mover esses registros para a tabela de histórico com base 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 quando a tarefa de liberação de dados é invocada pelo sistema na agenda interna.

Conteúdo relacionado