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
O OLTP in-memory fornece durabilidade completa para tabelas com otimização de memória. Quando uma transação que alterou uma tabela com otimização de memória é confirmada, o SQL Server (como faz para tabelas baseadas em disco), garante que as alterações sejam permanentes (elas sobrevivem a uma reinicialização de banco de dados), desde que o armazenamento subjacente esteja disponível. Há dois principais componentes de durabilidade: log de transações e persistência das alterações de dados para armazenamento em disco.
Para obter detalhes sobre quaisquer limitações de tamanho para tabelas duráveis, consulte Estimar requisitos de memória para tabelas otimizadas para memória.
Log de transações
Todas as alterações feitas nas tabelas baseadas em disco ou tabelas duráveis com otimização de memória são capturadas em um ou mais registros de log de transações. Quando uma transação é confirmada, o SQL Server grava os registros de log associados à transação no disco antes de comunicar ao aplicativo ou à sessão de usuário que a transação foi confirmada. Isso garante que as alterações feitas pela transação sejam duráveis. O log de transações para tabelas com otimização de memória está totalmente integrado ao mesmo fluxo de log usado por tabelas baseadas em disco. Essa integração permite que as operações de backup, recuperação e restauração de log de transações existentes continuem funcionando sem a necessidade de etapas adicionais. No entanto, como o In-Memory OLTP pode aumentar significativamente a taxa de transferência de transações da sua carga de trabalho, a E/S de log pode se tornar um gargalo de desempenho. Para manter essa taxa de transferência maior, verifique se o subsistema de E/S de log pode lidar com o aumento de carga.
Arquivos delta e de dados
Os dados nas tabelas com otimização de memória são armazenados como as linhas de dados de forma livre em uma estrutura de dados de heap na memória, e são vinculadas por meio de um ou mais índices na memória. Não há nenhuma estrutura de página para linhas de dados, como as usadas para tabelas baseadas em disco. Para a persistência de longo prazo e para permitir o truncamento do log de transações, as operações em tabelas com otimização de memória são mantidas em um conjunto de dados e de arquivos delta. Esses arquivos são gerados com base no log de transações, usando um processo assíncrono em segundo plano. Os dados e os arquivos delta estão localizados em um ou mais contêineres (com o mesmo mecanismo usado para dados FILESTREAM). Esses contêineres fazem parte de um grupo de arquivos com otimização de memória.
Os dados são gravados nesses arquivos de maneira estritamente sequencial, o que minimiza a latência do disco na rotação da mídia. Você pode usar vários contêineres em discos diferentes para distribuir a atividade de E/S. Os arquivos de dados e delta em vários contêineres em discos diferentes aumentam o desempenho de restauração/recuperação do banco de dados quando os dados são lidos dos arquivos de dados e delta no disco para a memória.
As transações de usuário não acessam diretamente os dados e os arquivos delta. Todas as leituras e gravações de dados usam estruturas de dados na memória.
O arquivo de dados
Um arquivo de dados contém linhas de uma ou mais tabelas com otimização de memória que foram inseridas por várias transações como parte das operações INSERT ou UPDATE. Por exemplo, uma linha pode ser de uma tabela com otimização de memória T1 e a linha seguinte pode ser da tabela com otimização de memória T2. As linhas são acrescentadas ao arquivo de dados na ordem das transações no log de transações, tornando o acesso aos dados sequencial. Isso permite uma taxa de transferência de E/S significativamente melhor em comparação com a E/S aleatória.
Quando o arquivo de dados estiver cheio, as linhas inseridas por novas transações serão armazenadas em outro arquivo de dados. Com o tempo, as linhas de tabelas duráveis com otimização de memória são armazenadas em um ou mais arquivos de dados, e cada arquivo de dados contendo linhas forma um intervalo descontínuo, mas contíguo de transações. Por exemplo, um arquivo de dados com o carimbo de data/hora de confirmação de transação no intervalo de (100, 200) tem todas as linhas inseridas por transações com o carimbo de data/hora de confirmação maior que 100 e menor que ou igual a 200. O carimbo de data/hora de confirmação é um número monotonicamente crescente atribuído a uma transação quando está pronto para confirmação. Cada transação tem um carimbo de data/hora de confirmação exclusivo.
Quando uma linha é excluída ou atualizada, a linha não é removida ou alterada in-loco no arquivo de dados, mas as linhas excluídas são rastreadas em outro tipo de arquivo: o arquivo delta. As operações de atualização são processadas como uma tupla de operações de exclusão e inserção para cada linha. Isso elimina a E/S aleatória no arquivo de dados.
Tamanho: cada arquivo de dados é dimensionado aproximadamente para 128 MB para computadores com mais memória que 16 GB e 16 MB para computadores com menos que ou igual a 16 GB. No SQL Server 2016 (13.x), o SQL Server pode usar o modo de ponto de verificação grande se considerar que o subsistema de armazenamento é suficientemente rápido. No modo de ponto de verificação grande, os arquivos de dados são dimensionados em 1 GB. Isso permite uma maior eficiência no subsistema de armazenamento para cargas de trabalho com alta taxa de transferência.
O arquivo delta
Cada arquivo de dados é emparelhado com um arquivo delta que tem o mesmo intervalo de transações e rastreia as linhas excluídas inseridas por transações nesse intervalo. Esse arquivo delta e de dados é chamado de CFP (Par de Arquivos de Ponto de Verificação) e é a unidade de alocação e desalocação, bem como a unidade para operações de mesclagem. Por exemplo, um arquivo delta correspondente ao intervalo de transações (100, 200) armazena linhas excluídas que foram inseridas por transações no intervalo (100, 200). Assim como os arquivos de dados, o arquivo delta é acessado sequencialmente.
Quando uma linha é excluída, a linha não é removida do arquivo de dados, mas uma referência à linha é acrescentada ao arquivo delta associado ao intervalo de transações em que essa linha de dados foi inserida. Como a linha de dados a ser excluída já existe no arquivo de dados, o arquivo delta armazena apenas as informações de referência {inserting_tx_id, row_id, deleting_tx_id} e segue a ordem do log transacional das operações de exclusão ou atualização originais.
Tamanho: cada arquivo de dados é dimensionado aproximadamente para 16 MB para computadores com mais memória que 16 GB e 1 MB para computadores com menos que ou igual a 16 GB. Desde o SQL Server 2016 (13.x), o SQL Server pode usar o modo de ponto de verificação grande se considerar que o subsistema de armazenamento é suficientemente rápido. No modo de ponto de verificação grande, os arquivos delta são dimensionados em 128 MB.
Preencher dados e arquivos delta
Os arquivos delta e de dados são populados com base nos registros do log de transações gerados por transações confirmadas em tabelas com otimização de memória e anexa informações sobre as linhas inseridas e excluídas em arquivos delta e de dados apropriados. Diferentemente das tabelas baseadas em disco, nas quais páginas de dados/índice são liberadas com E/S aleatória quando o ponto de verificação é realizado, a persistência da tabela com otimização de memória é uma operação em segundo plano contínua. Vários arquivos delta são acessados, pois uma transação pode excluir ou atualizar qualquer linha que foi inserida por qualquer transação anterior. As informações de exclusão sempre são anexadas no final do arquivo delta. Por exemplo, uma transação com um carimbo de data/hora de confirmação de 600 insere uma nova linha e exclui linhas inseridas por transações com um carimbo de data/hora de confirmação de 150, 250 e 450, conforme mostrado na imagem a seguir. Todas as quatro operações de E/S de arquivo (três para linhas excluídas e 1 para as linhas recém-inseridas) são operações somente de acréscimo aos arquivos delta e de dados correspondentes.
Acessar dados e arquivos delta
Os pares de arquivos de dados e delta são acessados quando os eventos a seguir ocorrem.
Trabalhadores de ponto de verificação offline
Esse thread acrescenta inserções e exclusões às linhas de dados com otimização de memória, aos pares de arquivos de dados e delta correspondentes. O SQL Server 2014 (12.x) tem um trabalhador de ponto de verificação offline. O SQL Server 2016 (13.x) e versões posteriores têm vários trabalhos de ponto de verificação.
Operação de mesclagem
A operação mescla um ou mais pares de arquivos delta e de dados, além de criar um novo par de arquivos de dados e delta.
Durante a recuperação de pane
Quando o SQL Server é reiniciado ou o banco de dados é reativado, os dados com otimização de memória são preenchidos usando os pares de arquivos de dados e delta. O arquivo delta atua como um filtro para as linhas excluídas ao ler as linhas do arquivo de dados correspondente. Como cada par de arquivos delta e de dados é independente, esses arquivos são carregados paralelamente para reduzir o tempo necessário para popular os dados na memória. Depois que os dados são carregados na memória, o mecanismo In-Memory OLTP aplica os registros do log de transações ativos que ainda não foram cobertos pelos arquivos de ponto de verificação, de forma que os dados otimizados para memória estejam completos.
Durante a operação de restauração
Os arquivos de ponto de verificação de OLTP na memória são criados com base no backup do banco de dados e, em seguida, um ou mais backups de log de transações são aplicados. Assim como acontece com a recuperação de falhas, o mecanismo OLTP In-Memory carrega dados na memória em paralelo, para minimizar o efeito no tempo de recuperação.
Mesclar dados e arquivos delta
Os dados de tabelas com otimização de memória são armazenados em um ou mais pares de arquivos delta e de dados (também denominados pares de arquivos de ponto de verificação ou CFP). Os arquivos de dados armazenam linhas inseridas e os arquivos delta referenciam linhas excluídas. Durante a execução de uma carga de trabalho OLTP, enquanto as operações DML atualizam, inserem e excluem linhas, novos CFPs são criados para persistir as novas linhas e a referência às linhas excluídas é anexada aos arquivos delta.
Com o tempo, com operações DML, o número de arquivos de dados e delta aumenta, causando maior uso de espaço em disco e maior tempo de recuperação.
Para ajudar a evitar essas ineficiências, os dados fechados mais antigos e os arquivos delta são mesclados, com base em uma política de mesclagem descrita posteriormente neste artigo, para que a matriz de armazenamento seja compactada para representar o mesmo conjunto de dados, com um número reduzido de arquivos.
A operação de mesclagem usa como entrada um ou mais CFPs (pares de arquivos de ponto de verificação fechado) adjacentes, que são pares de dados e arquivos delta (chamados de fonte de mesclagem) com base em uma política de mesclagem definida internamente e produz um CFP resultante, chamado de destino de mesclagem. As entradas em cada arquivo delta dos CFPs de origem são usadas para filtrar linhas do arquivo de dados correspondente para remover as linhas de dados que não são necessárias. As linhas restantes nos CFPs de origem são consolidadas em um CFP de destino. Após a conclusão da mesclagem, o CFP de destino resultante da mesclagem substitui os CFPs de origem (fontes de mesclagem). Os CFPs de origem de mesclagem passam por uma fase de transição antes de serem removidos do armazenamento.
No exemplo a seguir, o grupo de arquivos de tabela com otimização de memória tem quatro pares de arquivos delta e de dados no carimbo de data/hora 500 contendo dados de transações anteriores. Por exemplo, as linhas no primeiro arquivo de dados correspondem a transações com carimbo de data/hora superior a 100 e inferior ou igual a 200; alternativamente representados como (100, 200]. O segundo e terceiro arquivos de dados apresentam menos de 50% de utilização após a contagem das linhas marcadas como excluídas. A operação de mesclagem combina esses dois CFPs e cria um novo CFP que contém transações com carimbo de data/hora superior a 200 e inferior ou igual a 400, que é o intervalo combinado desses dois CFPs. Você vê outro CFP com intervalo (500, 600] e o arquivo delta não vazio do intervalo de transações (200, 400] mostra que a operação de mesclagem pode ser realizada junto com atividades transacionais, incluindo a exclusão de mais linhas dos CFPs de origem.
Um thread de segundo plano avalia todos os CFPs fechados usando uma política de mesclagem e, em seguida, inicia uma ou mais solicitações de mesclagem para os CFPs de qualificação. Essas solicitações de mesclagem são processadas pelo thread de ponto de verificação offline. A avaliação da política de mesclagem é feita periodicamente e também quando um ponto de verificação é fechado.
Política de mesclagem do SQL Server
O SQL Server implementa a seguinte política de mesclagem:
Uma mesclagem será agendada se dois ou mais CFPs consecutivos puderem ser consolidados, após a contabilização de linhas excluídas, de forma que as linhas resultantes caibam em um CFP de tamanho alvo. O tamanho de destino de dados e arquivos delta corresponde ao dimensionamento original, conforme descrito anteriormente.
Um único CFP poderá ser automesclado caso o arquivo de dados dobre o tamanho de destino e mais da metade das linhas serão excluídas. Um arquivo de dados pode crescer mais do que o tamanho de destino se, por exemplo, uma única transação ou várias transações simultâneas inserir ou atualizar uma grande quantidade de dados, forçando o arquivo de dados a crescer além de seu tamanho de destino, porque uma transação não pode abranger vários CFPs.
Aqui estão alguns exemplos que mostram os CFPs a serem mesclados de acordo com a política de mesclagem.
| Arquivos de origem de CFPs adjacentes (% completo) | Seleção de mesclagem |
|---|---|
| CFP0 (30%), CFP1 (50%), CFP2 (50%), CFP3 (90%) | (CFP0, CFP1) O CFP2 não é escolhido, pois torna o arquivo de dados resultante maior que 100% do tamanho ideal. |
| CFP0 (30%), CFP1 (20%), CFP2 (50%), CFP3 (10%) | (CFP0, CFP1, CFP2). Os arquivos são escolhidos a partir da esquerda. O CFP3 não é escolhido, pois torna o arquivo de dados resultante maior que 100% do tamanho ideal. |
| CFP0 (80%), CFP1 (30%), CFP2 (10%), CFP3 (40%) | (CFP1, CFP2, CFP3). Os arquivos são escolhidos a partir da esquerda. CFP0 é ignorado porque, se combinado com CFP1, o arquivo de dados resultante é maior que 100% do tamanho ideal. |
Nem todos os CFPs com o espaço disponível se qualificam para mesclagem. Por exemplo, se dois CFPs adjacentes tiverem 60% de capacidade, eles não são elegíveis para mesclagem e cada um desses CFPs tem 40% de armazenamento não utilizado. Na pior das hipóteses, todos os CFPs estão 50% cheios, resultando em uma utilização de armazenamento de apenas 50%. Embora as linhas excluídas possam existir no armazenamento pois os CFPs não atendem aos critérios para mesclagem, as linhas excluídas já podem ter sido removidas da memória pela coleta de lixo em memória. O gerenciamento de armazenamento e de memória é independente da coleta de lixo. O espaço de armazenamento ocupado por CFPs ativos (nem todos os CFPs estão sendo atualizados) pode ser até duas vezes maior do que o tamanho de tabelas persistentes na memória.
Ciclo de vida de um CFP
Os CFPs passam por vários estados antes de poderem ser desalocados. Os backups de log e de pontos de verificação do banco de dados devem ocorrer para fazer a transição dos arquivos pelas fases e, por fim, limpar os arquivos que não são mais necessários. Para obter uma descrição dessas fases, consulte sys.dm_db_xtp_checkpoint_files.
Você pode forçar manualmente o ponto de verificação seguido pelo backup de log para acelerar a coleta de lixo. Em cenários de produção, os pontos de verificação automáticos e os backups de log feitos como parte da estratégia de backup fazem a transição perfeita de CFPs por essas fases sem a necessidade de nenhuma intervenção manual. O efeito do processo de coleta de lixo é que bancos de dados com tabelas com otimização de memória podem ter um tamanho de armazenamento maior em comparação com seu tamanho na memória. Se os backups de ponto de verificação e de log não acontecerem, o volume de arquivos de ponto de verificação no disco continuará aumentando.