Durabilidade para tabelas de Memory-Optimized

In-Memory OLTP fornece durabilidade total 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 (sobreviverão a uma reinicialização de banco de dados), desde que o armazenamento subjacente esteja disponível. Há dois componentes principais de durabilidade: registro em log de transações e alterações de dados persistentes no armazenamento em disco.

Log de Transações

Todas as alterações feitas em 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 se comunicar com o aplicativo ou a sessão de usuário confirmada pela transação. 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 é 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 In-Memory OLTP pode aumentar significativamente a taxa de transferência da sua carga de trabalho, você precisa garantir que o armazenamento de log de transações esteja configurado adequadamente para lidar com os requisitos de E/S aumentados.

Dados e Arquivos Delta

Os dados em tabelas otimizadas para memória são armazenados como linhas de dados de forma livre que estão vinculadas por meio de um ou mais índices em memória. Não há estruturas de página para linhas de dados, como as usadas para tabelas baseadas em disco. Quando o aplicativo estiver pronto para confirmar a transação, o In-Memory OLTP gerará os registros de log para a transação. A persistência de tabelas com otimização de memória é feita com um conjunto de dados e arquivos delta usando um thread em segundo plano. Os arquivos delta e de dados estão localizados em um ou mais contêineres (usando o mesmo mecanismo usado para dados FILESTREAM). Esses contêineres são mapeados para um novo tipo de grupo de arquivos, chamado de grupo de arquivos com otimização de memória.

Os dados são gravados nesses arquivos de forma estritamente sequencial, o que minimiza a latência do disco para a mídia giratória. 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, aumentarão o desempenho da recuperação quando os dados forem lidos dos arquivos de dados e delta no disco para a memória.

Um aplicativo não acessa diretamente dados e arquivos delta. Todas as leituras e gravações de dados usam 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 da tabela T1 com otimização de memória e a próxima linha pode ser da tabela T2 com otimização de memória. As linhas são acrescentadas ao arquivo de dados na ordem das transações no log de transações, tornando o acesso a dados sequencial. Isso permite uma taxa de transferência de E/S significativamente melhor em uma ordem de grandeza, em comparação com E/S aleatória. Cada arquivo de dados é dimensionado aproximadamente a 128 MB para computadores com memória maior que 16 GB e 16 MB para computadores com menos ou igual a 16 GB. Depois que 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 contém linhas de um intervalo disjunto, mas contíguo de transações. Por exemplo, um arquivo de dados com carimbo de data/hora de confirmação de transação no intervalo de (100, 200) tem todas as linhas inseridas por transações que têm 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 entrada/saída aleatória no arquivo de dados.

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 no intervalo de transações. 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) armazenará 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 a ser excluída já existe no arquivo de dados, o arquivo delta armazena apenas as informações {inserting_tx_id, row_id, deleting_tx_id } de referência e segue a ordem de log transacional das operações de exclusão ou atualização de origem.

População de Dados e Arquivos Delta

Os dados e o arquivo delta são preenchidos por um thread em segundo plano chamado ponto de verificação offline. Esse thread lê os registros de log de transações gerados por transações confirmadas em tabelas com otimização de memória e acrescenta informações sobre as linhas inseridas e excluídas em dados apropriados e arquivos delta. Ao contrário das tabelas baseadas em disco, onde as páginas de dados/índice são esvaziadas com E/S aleatória durante o ponto de verificação, a persistência da tabela otimizada para memória é uma operação contínua em segundo plano. Vários arquivos delta são acessados porque uma transação pode excluir ou atualizar qualquer linha inserida por qualquer transação anterior. As informações de exclusão são sempre acrescentadas 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 abaixo. Todas as 4 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.

Acessando dados e arquivos delta

Os pares de arquivos delta e de dados são acessados quando ocorre o seguinte.

Thread de ponto de verificação offline Esse thread acrescenta inserções e exclusões a linhas de dados com otimização de memória, aos pares de dados e arquivos delta correspondentes.

Operação de mesclagem A operação mescla um ou mais pares de arquivos delta e de dados e cria um novo par de arquivos delta e de dados.

Durante a recuperação após falha, quando o SQL Server é reiniciado ou o banco de dados é reconectado, os dados com otimização de memória são preenchidos usando 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 dados e arquivos delta é independente, esses arquivos são carregados em paralelo para reduzir o tempo necessário para preencher dados na memória. Depois que os dados forem carregados na memória, o mecanismo OLTP In-Memory aplicará os registros de log de transações ativos ainda não cobertos pelos arquivos de ponto de verificação para que os dados com otimização de memória sejam concluídos.

Durante a operação de restauração, os arquivos de ponto de verificação In-Memory OLTP 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 ocorre com a recuperação de falhas, o mecanismo OLTP In-Memory carrega dados na memória em paralelo, para minimizar o impacto no tempo de recuperação.

Mesclando dados e arquivos delta

Os dados das tabelas com otimização de memória são armazenados em um ou mais pares de arquivos delta e de dados (também chamados de par de arquivos de ponto de verificação ou CFP). Os arquivos de dados armazenam linhas inseridas e arquivos delta fazem referência a linhas excluídas. Durante a execução de uma carga de trabalho OLTP, à medida que 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 é acrescentada aos arquivos delta.

Os metadados de todos os CFPs anteriormente fechados e atualmente ativos são armazenados em uma estrutura de matriz interna conhecida como matriz de armazenamento. É uma matriz finita (8.192 entradas) de CFPs. As entradas na matriz de armazenamento são ordenadas pelo intervalo de transações. Os CFPs na matriz de armazenamento (juntamente com a parte final do log) representam todo o estado em disco necessário para recuperar um banco de dados com tabelas com otimização de memória.

Com o tempo, com as operações DML, o número de CFPs aumenta fazendo com que a matriz de armazenamento atinja a capacidade, o que apresenta os seguintes desafios:

• Linhas excluídas. As linhas excluídas permanecem no arquivo de dados, mas são marcadas como excluídas no arquivo delta correspondente. Essas linhas não são mais necessárias e serão removidas do armazenamento. Se as linhas excluídas não fossem removidas dos CFPs, elas usariam o espaço desnecessariamente e tornariam o tempo de recuperação mais lento.

• Matriz de armazenamento cheia. Quando há 8.000 entradas na matriz de armazenamento são alocadas (192 entradas na matriz são reservadas para mesclagens existentes para competir ou para permitir que você faça mesclagens manuais), nenhuma nova transação DML pode ser executada em tabelas duráveis com otimização de memória. Somente operações de ponto de verificação e mesclagem têm permissão para consumir as entradas restantes. Isso garante que as transações DML não preencham a matriz e que algumas entradas na matriz sejam reservadas para mesclar arquivos existentes e recuperar espaço na matriz.

• Sobrecarga de manipulação da matriz de armazenamento. Processos internos pesquisam a matriz de armazenamento em busca de operações, como localizar o arquivo delta para acrescentar informações sobre uma linha excluída. O custo dessas operações aumenta com o número de entradas.

Para ajudar a evitar essas ineficiências, os CFPs fechados mais antigos são mesclados, com base em uma política de mesclagem descrita abaixo, de modo que a matriz de armazenamento é compactada para representar o mesmo conjunto de dados, com um número reduzido de CFPs.

O tamanho total na memória de todas as tabelas duráveis em um banco de dados não deve exceder 250 GB. Tabelas duráveis que usam até 250 GB de memória, supondo que as operações de inserção, exclusão e atualização exijam, em média, 500 GB de espaço de armazenamento. São necessários 4.000 pares de dados e arquivos delta no grupo de arquivos com otimização de memória para dar suporte aos 500 GB de espaço de armazenamento.

Os aumentos de curto prazo na atividade de banco de dados podem causar atraso nas operações de ponto de verificação e mesclagem, o que aumentará o número de dados necessários e pares de arquivos delta. Para acomodar picos de picos de curto prazo na atividade de banco de dados, o sistema de armazenamento pode alocar até 8.000 pares de dados e arquivos delta até um total de 1 TB de armazenamento. Quando esse limite for atingido, não haverá novas transações permitidas no banco de dados até que as operações de ponto de verificação sejam atualizadas. Se o tamanho das tabelas duráveis na memória exceder 250 GB por longos períodos de tempo, há uma chance de atingir o limite de 8.000 pares de arquivos.

A operação de mesclagem usa como entrada um ou mais CFPs fechados adjacentes (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 de mesclagem resultante substitui os CFPs de origem (fontes de mesclagem). Os CFPs da fonte de mesclagem passam por uma fase de transição antes de serem removidos do sistema de armazenamento.

No exemplo a seguir, o grupo de arquivos de tabela com otimização de memória tem quatro pares de dados e arquivos delta 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 maior que 100 e menor que ou igual a 200; alternativamente representado como (100, 200]. O segundo e o terceiro arquivos de dados estão menos de 50% cheios após contabilizar as 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 data/hora maior que 200 e menor ou igual a 400, que é o intervalo resultante da combinação desses dois CFPs. Você verá outro CFP com intervalo (500, 600] e arquivo delta não vazio para intervalo de transações (200, 400] mostra que a operação de mesclagem pode ser feita simultaneamente com a atividade transacional, incluindo a exclusão de mais linhas dos CFPs de origem.

Diagrama mostra o grupo de arquivos de tabela com otimização de memória

Uma thread em 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 que atendem aos critérios. 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 2014 (12.x)

O SQL Server 2014 (12.x) implementa a seguinte política de mesclagem:

• Uma mesclagem será agendada se 2 ou mais CFPs consecutivos puderem ser consolidados, considerando as linhas excluídas, de modo que as linhas resultantes possam caber em 1 CFP de tamanho ideal. O tamanho ideal do CFP é determinado da seguinte maneira:

  • Se um computador tiver menos ou igual a 16 GB de memória, o arquivo de dados será de 16 MB e o arquivo delta será de 1 MB.

  • Se um computador tiver mais de 16 GB de memória, o arquivo de dados será de 128 MB e o arquivo delta será de 16 MB.

• Um único CFP pode ser autofundido se o arquivo de dados exceder 256 MB e mais de metade das linhas forem excluídas. Um arquivo de dados pode aumentar mais de 128 MB 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 ideal porque uma transação não pode abranger vários CFPs.

Aqui estão alguns exemplos que mostram os CFPs que serão mesclados de acordo com a política de mesclagem.

Nem todos os CFPs com espaço disponível se qualificam para mesclagem. Por exemplo, se dois CFPs adjacentes tiverem 60% cheios, eles não se qualificarão para mesclagem e cada um desses CFPs terá 40% armazenamento não utilizado. Na pior das hipóteses, todos os CFPs serão 50% completos, uma utilização de armazenamento de apenas 50%. Embora as linhas excluídas possam existir no armazenamento porque os CFPs não se qualificam para mesclagem, as linhas excluídas podem já ter sido removidas da memória pela coleta de lixo na memória. O gerenciamento do armazenamento e da memória é independente da coleta de lixo. O espaço de armazenamento ocupado por CFPs ativos (a atualização não está ocorrendo para todos os CFPs) pode ser até 2 vezes superior ao tamanho das tabelas duráveis na memória.

Se necessário, uma mesclagem manual pode ser executada explicitamente chamando sys.sp_xtp_merge_checkpoint_files (Transact-SQL).

Ciclo de vida de um CFP

Os CPFs passam por vários estados antes de serem desalocados. A qualquer momento, os CFPs estão em uma das seguintes fases: PRECREATED, UNDER CONSTRUCTION, ACTIVE, MERGE TARGET, MERGED SOURCE, REQUIRED FOR BACKUP/HA, IN TRANSITION TO TOMBSTONE e TOMBSTONE. Para obter uma descrição dessas fases, consulte sys.dm_db_xtp_checkpoint_files (Transact-SQL).

Após contabilizar o armazenamento consumido por CFPs em vários estados, o armazenamento total consumido por tabelas otimizadas para memória durável pode ser muito superior a duas vezes o tamanho das tabelas na memória. O sys.dm_db_xtp_checkpoint_files DMV (Transact-SQL) pode ser consultado para listar todos os CFPs no grupo de arquivos com otimização de memória, incluindo a fase. A transição de CFPs do estado MERGE SOURCE para o TOMBSTONE e, por fim, a coleta de lixo pode ocupar cinco pontos de verificação, com cada ponto de verificação seguido por um backup de log de transações, se o banco de dados estiver configurado para o modelo de recuperação completo ou bulk-logged.

Você pode forçar manualmente o ponto de verificação seguido pelo backup de log para agilizar a coleta de lixo, mas isso adicionará 5 CFPs vazios (cinco pares de arquivos de dados/delta com o arquivo de dados de tamanho 128MB cada). 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 farão a transição perfeita de CFPs por essas fases sem a necessidade de nenhuma intervenção manual. O impacto 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. Não é incomum que os CFPs sejam até quatro vezes maiores que as tabelas duráveis otimizadas para memória.

Consulte Também

Criando e gerenciando o armazenamento para objetos Memory-Optimized