Durabilidade para tabelas com otimização de memória

Aplica-se a:SQL Server

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

Registo 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 em disco antes de se comunicar com o aplicativo ou sessão de usuário que a transação confirmou. 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 com o mesmo fluxo de log usado por tabelas baseadas em disco. Essa integração permite que as operações existentes de backup, recuperação e restauração do log de transações continuem a funcionar sem a necessidade de etapas adicionais. No entanto, como o In-Memory OLTP pode aumentar significativamente a taxa de transferência das transações da sua carga de trabalho, a E/S de log pode tornar-se um gargalo de desempenho. Para sustentar esta taxa de transferência aumentada, certifique-se de que o subsistema de E/S de log possa lidar com o aumento da carga.

Dados e arquivos delta

Os dados em tabelas com otimização de memória são armazenados como linhas de dados de forma livre em uma estrutura de heap de dados na memória e são ligados 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. Para 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 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 arquivos delta estão localizados em um ou mais contêineres (usando 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 forma estritamente sequencial, o que minimiza a latência do disco para mídia giratória. Você pode usar vários contêineres em discos diferentes para distribuir a atividade de E/S. Os dados e arquivos 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 dados e arquivos delta no disco para a memória.

As transações do usuário não acessam diretamente dados e arquivos delta. Todos os dados lidos e gravados usam estruturas de dados na memória.

O ficheiro 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 anexadas ao arquivo de dados na ordem das transações no log de transações, tornando o acesso aos dados sequencial. Isso permite uma ordem de grandeza melhor na taxa de transferência de E/S em comparação com E/S aleatórias.

Quando o arquivo de dados estiver cheio, as linhas inseridas por novas transações são armazenadas em outro arquivo de dados. Com o tempo, as linhas de tabelas com otimização de memória durável são armazenadas em um ou mais arquivos de dados e cada arquivo de dados contendo linhas forma uma gama separada, mas contígua, 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 ou igual a 200. O timestamp de commit é um número monotonicamente crescente atribuído a uma transação quando ela está pronta para commit. 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 E/S aleatórias no arquivo de dados.

Tamanho: Cada ficheiro de dados tem um tamanho aproximado de 128 MB para computadores com memória superior a 16 GB e 16 MB para computadores com menos 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 é rápido o suficiente. No modo de ponto de verificação grande, os ficheiros de dados são dimensionados em 1 GB. Isso permite maior eficiência no subsistema de armazenamento para cargas de trabalho de alto throughput.

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 pelas transações no intervalo de transações. Esse arquivo delta e de dados é conhecido como um par de arquivos de ponto de verificação (CFP) 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). Como os arquivos de dados, o arquivo delta é acessado sequencialmente.

Quando uma linha é excluída, ela não é removida do arquivo de dados, mas uma referência à linha é acrescentada ao arquivo delta associado ao intervalo de transações onde 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 do log transacional das operações de exclusão ou atualização de origem.

Tamanho: Cada ficheiro delta tem um tamanho aproximado de 16 MB para computadores com memória superior a 16 GB e 1 MB para computadores com menos ou igual a 16 GB. Iniciando 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 é rápido o suficiente. No modo de ponto de verificação grande, os ficheiros delta são dimensionados para 128MB.

Preencher dados e ficheiros delta

Os dados e o ficheiro delta são preenchidos com base nos registos de log de transações gerados por transações confirmadas em tabelas otimizadas para memória, e adicionam informações sobre as linhas inseridas e eliminadas nos respetivos dados e ficheiros delta. Ao contrário das tabelas baseadas em disco em que as páginas de dados/índice são liberadas com E/S aleatórias quando o ponto de verificação é concluído, 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 que foi 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 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 ocorrem os seguintes eventos.

Trabalhadores de pontos de verificação offline

Este thread acrescenta inserções e exclusões a linhas de dados com otimização de memória, aos dados correspondentes e pares de arquivos delta. O SQL Server 2014 (12.x) tem um operador de ponto de verificação offline. O SQL Server 2016 (13.x) e versões posteriores têm vários operadores de ponto de verificação.

Operação de mesclagem

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

Durante a recuperação de falhas

Quando o SQL Server é reiniciado ou o banco de dados é colocado online novamente, os dados com otimização de memória são preenchidos usando os pares de dados e arquivos 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 os dados na memória. Depois que os dados são carregados na memória, o mecanismo OLTP In-Memory aplica os registros de log de transações ativas ainda não cobertos pelos arquivos de ponto de verificação para que os dados otimizados para memória sejam completos.

Durante a operação de restauração

Os arquivos de ponto de verificação In-Memory OLTP são criados a partir do backup do banco de dados e, em seguida, um ou mais backups de log de transações são aplicados. Tal como acontece com a recuperação de falhas, o motor OLTP In-Memory carrega dados na memória em paralelo, para minimizar o efeito no tempo de recuperação.

Unir dados e ficheiros delta

Os dados para tabelas otimizadas para memória são armazenados em um ou mais pares de arquivos delta e de dados (também chamados de pares de arquivos de ponto de verificação ou CFP). Os arquivos de dados armazenam linhas inseridas e os 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 é anexada aos arquivos delta.

Com o tempo, com as operações DML, o número de dados e arquivos delta cresce, 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 pares de arquivos de ponto de verificação fechados (CFPs) adjacentes, que são pares de dados e arquivos delta (chamados de origem 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 restantes linhas das PCP de origem são consolidadas numa única PCP de destino. Após a conclusão da mesclagem, a CFP de destino de mesclagem resultante substitui as CFPs de origem (fontes de mesclagem). Os CFPs de origem de fusão passam por uma fase de transição antes de serem removidos do armazenamento.

No exemplo a seguir, o grupo de ficheiros de tabela com otimização de memória tem quatro pares de ficheiros de dados e ficheiros delta no carimbo de data e 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 ou igual a 200; alternativamente representado como (100, 200). O segundo e terceiro arquivos de dados são mostrados como estando menos de 50 por cento cheios após considerar as linhas marcadas como eliminadas. A operação de fusão combina estes dois PCP 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 destes dois CFP. Você vê outro CFP com intervalo (500, 600] e um arquivo delta não vazio para o intervalo de transações (200, 400] que mostram que a operação de mesclagem pode ser realizada simultaneamente com a atividade transacional, incluindo a exclusão de mais linhas dos CFPs de origem.

Um thread em segundo plano avalia todas as CFPs fechadas usando uma política de mesclagem e, em seguida, inicia uma ou mais solicitações de mesclagem para as CFPs qualificadas. 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 fusão é agendada se duas ou mais CFPs consecutivas puderem ser consolidadas, após contabilizar as linhas excluídas, de modo que as linhas resultantes possam caber em um CFP de tamanho alvo. O tamanho de destino dos dados e arquivos delta corresponde ao dimensionamento original, conforme descrito anteriormente.

• Um único CFP pode ser mesclado automaticamente se o arquivo de dados exceder o dobro do tamanho de destino e mais da metade das linhas forem 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 inserirem ou atualizarem uma grande quantidade de dados, forçando o arquivo de dados a crescer além do tamanho de destino, porque uma transação não pode abranger vários CFPs.

Eis alguns exemplos que mostram as PCP a fundir no âmbito da política de fusão:

Nem todos os CFPs com espaço disponível se qualificam para fusão. Por exemplo, se dois CFPs adjacentes estiverem 60% completos, eles não se qualificam para mesclagem e cada um desses CFPs tem 40% armazenamento não utilizado. Na pior das hipóteses, todos os CFPs estão com 50% de capacidade, resultando numa 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. A gestão do armazenamento e da memória é independente da recolha de lixo. O armazenamento ocupado por CFPs ativos (nem todos os CFPs precisam ser atualizados) pode ser até duas vezes maior do que o tamanho das tabelas persistentes na memória.

Ciclo de vida de uma PCP

Os CFP transitam por vários estados antes de poderem ser desalocados. Pontos de verificação de banco de dados e backups de log precisam acontecer para fazer a transição dos arquivos pelas fases e, finalmente, 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 agilizar a coleta de lixo. Em cenários de produção, os pontos de verificação automáticos e backups de log tomados como parte da estratégia de backup fazem a transição perfeita dos CFPs por essas fases sem exigir qualquer intervenção manual. O efeito do processo de coleta de lixo é que os bancos de dados com tabelas otimizadas para 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 espaço em disco dos ficheiros de ponto de verificação continuará a crescer.

Conteúdo relacionado

• Criar e gerenciar armazenamento para objetos com otimização de memória