Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a: SQL Server 2016 (13.x) e versões posteriores
da Instância Gerenciada de SQL do Azure
Tabelas temporais versionadas por sistema para tabelas otimizadas para memória fornecem uma solução econômica para cenários onde auditoria de dados e análise pontual são necessárias além dos dados coletados 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 de 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 oferecem extensões convenientes de Transact-SQL para análise de ponto no tempo. Em um cenário típico, o histórico de dados é mantido por muito tempo (vários meses, até anos), mesmo que não seja consultado regularmente.
Auditoria de dados e análise baseada em tempo podem ser exigidas em diferentes ambientes, especialmente em sistemas OLTP que processam um número extremamente grande de requisições e onde a tecnologia OLTP em memória é utilizada. 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 de somente leitura, que são acessados com menos frequência à medida que ficam mais antigos, não é uma solução ideal.
Tabelas temporais com controle de versão do sistema para tabelas otimizadas para memória oferecem alta taxa de transferência transacional e concorrência sem bloqueios. Você pode armazenar uma grande quantidade de dados históricos usando tabelas em 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.
Detalhes da implementação
Ao criar uma tabela com otimização de memória versionada pelo sistema, esteja ciente das seguintes considerações. Para opções de sintaxe e para um exemplo, consulte CREATE TABLE.
Apenas as tabelas com otimização de memória duráveis podem ser versionadas pelo sistema (
DURABILITY = SCHEMA_AND_DATA).A tabela de histórico para uma tabela com controle de versão do sistema otimizada para memória deve ser baseada em disco, seja criada por você ou pelo sistema.
Você pode 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 TIMEclá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 de preparação interna otimizada para memória para receber as alterações com controle de versão do sistema mais recentes, resultantes de operações de atualização e exclusão em uma tabela otimizada para memória atual.Uma tarefa assíncrona de liberação de dados move regularmente os dados da tabela de preparação interna otimizada para memória para a tabela de histórico baseada em disco. Esse mecanismo de limpeza de dados mantém os buffers internos da memória em menos de 10% do consumo de memória de seus objetos pai. Você pode monitorar o consumo total de memória de uma tabela temporal com controle de versão do sistema otimizada para memória consultando sys.dm_db_xtp_memory_consumers e resumindo os dados da tabela de preparação interna otimizada para memória e da tabela temporal atual.
Para realizar manualmente uma limpeza de dados, execute sp_xtp_flush_temporal_history.
Com
SYSTEM_VERSIONING = OFF, ou quando você modifica o esquema de uma tabela versionada do sistema adicionando, removendo ou alterando colunas, todo o conteúdo do buffer de preparação interno é movido para a tabela de histórico baseada 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 preparo na memória e a tabela com base em disco sem duplicatas.
ALTER TABLEOperações que alteram internamente o esquema da tabela devem realizar uma limpeza de dados, o que pode prolongar a 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 usa 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 . Essa 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>], em que<suffix>é adicionado, opcionalmente, caso a tabela já tenha uma colunaChange_ID.O tamanho máximo de linha para uma tabela com otimização de memória com controle da versão do sistema é reduzido em oito bytes, devido à coluna bigint extra na tabela de preparo. O máximo agora é de 8.052 bytes.
A tabela interna de staging otimizada para memória não aparece no Pesquisador de Objetos do SQL Server Management Studio.
Você pode encontrar metadados sobre essa tabela e sua conexão com a tabela temporal atual em sys.internal_tables.
A tarefa de limpeza de dados
A tarefa de limpeza de dados é executada regularmente, e isso verifica se alguma tabela otimizada para memória atende a uma condição baseada no tamanho da memória para movimento de dados. A movimentação de dados começa quando o consumo de memória da tabela de preparação interna atinge oito por cento 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 é executado da mesma forma que quando o sistema executa a tarefa de descarregamento de dados de acordo com sua programação interna.
Conteúdo relacionado
- Tabelas temporais
- Primeiros passos com tabelas temporais versionadas pelo sistema
- Cenários de uso da tabela temporal
- Verificações de consistência do sistema de tabela temporal
- Partição com tabelas temporais
- Considerações e limitações da tabela temporal
- Segurança da tabela temporal
- Gerenciar a retenção de dados históricos em tabelas temporárias com versão do sistema
- Exibições e funções de metadados de tabela temporal