Restauração e Recuperação de Tabelas Memory-Optimized

O mecanismo básico para recuperar ou restaurar um banco de dados com tabelas com otimização de memória é semelhante a bancos de dados com apenas tabelas baseadas em disco. Mas, ao contrário das tabelas baseadas em disco, as tabelas com otimização de memória devem ser carregadas na memória antes que o banco de dados esteja disponível para acesso do usuário. Isso adiciona uma nova etapa na recuperação do banco de dados. As etapas modificadas na recuperação de banco de dados são alteradas da seguinte maneira:

Quando o SQL Server é reiniciado, cada banco de dados passa por uma fase de recuperação que consiste nas três fases a seguir:

1. A fase de análise. Durante essa fase, uma passagem é feita nos logs de transações ativas para detectar transações confirmadas e não confirmadas. O mecanismo OLTP In-Memory identifica o ponto de verificação para carregar e pré-carregar as entradas de log da tabela do sistema. Ele também processará alguns registros de log de alocação de arquivos.

2. A fase de refazer. Essa fase é executada simultaneamente em tabelas baseadas em disco e com otimização de memória.

   Para tabelas baseadas em disco, o banco de dados é movido para o ponto atual no tempo e adquire bloqueios feitos por transações não confirmadas.

   Para tabelas com otimização de memória, os dados dos pares de arquivos delta e de dados são carregados na memória e, em seguida, atualizam os dados com o log de transações ativo com base no último ponto de verificação durável.

   Quando as operações acima em tabelas baseadas em disco e com otimização de memória forem concluídas, o banco de dados estará disponível para acesso.

3. A fase desfazer. Nesta fase, as transações não confirmadas são revertidas.

Carregar tabelas com otimização de memória na memória pode afetar o desempenho do RTO (objetivo de tempo de recuperação). Para melhorar o tempo de carregamento de dados com otimização de memória de dados e arquivos delta, o mecanismo OLTP In-Memory carrega os arquivos de dados/delta em paralelo da seguinte maneira:

• Criando um filtro de mapa delta. Os arquivos Delta armazenam referências às linhas excluídas. Um thread por contêiner lê os arquivos delta e cria um filtro de mapa delta. (Um grupo de arquivos de dados com otimização de memória pode ter um ou mais contêineres.)

• Transmitindo os arquivos de dados. Depois que o filtro de mapa delta é criado, os arquivos de dados são lidos usando quantos threads houver CPUs lógicas. Cada thread que lê o arquivo de dados lê as linhas de dados, verifica o mapa delta associado e só insere a linha na tabela se essa linha não tiver sido marcada como excluída. Essa parte da recuperação pode ser associada à CPU em alguns casos, conforme observado abaixo.

As tabelas com otimização de memória geralmente podem ser carregadas na memória na velocidade de E/S, mas há casos em que o carregamento de linhas de dados na memória será mais lento. Casos específicos são:

• A baixa contagem de buckets em um índice de hash pode levar a colisões excessivas, fazendo com que a inserção das linhas de dados seja mais lenta do que o normal. Isso geralmente resulta em uma utilização muito alta da CPU em toda parte e, especialmente, no final da recuperação. Se você configurou o índice de hash corretamente, ele não deve afetar o tempo de recuperação.

• Tabelas grandes com otimização de memória com um ou mais índices não clusterizados, ao contrário de um índice de hash cuja contagem de buckets é dimensionada no momento da criação, os índices não clusterizados crescem dinamicamente, resultando em alta utilização da CPU.

Restaurando um banco de dados com tabelas com otimização de memória

Você sabe que tem memória suficiente no servidor para restaurar um banco de dados, mas há um requisito de que a memória necessária para o banco de dados seja contabilizada como parte de uma piscina de recursos existente. Você sabe que não pode criar a associação ao pool de recursos antes que o banco de dados exista, por isso, execute a restauração WITH NORECOVERY. Isso faz com que a imagem de disco do banco de dados seja restaurada e o banco de dados seja criado, mas nenhuma In-Memory memória OLTP é consumida porque o banco de dados não é colocado online.

Neste ponto, você pode criar o pool de recursos para associação de banco de dados e, em seguida, usar RESTORE WITH RECOVERY para colocar o banco de dados restaurado online. Como a associação está configurada antes que o banco de dados seja colocado online, o consumo de memória OLTP do In-Memory é devidamente contabilizado. Isso requer a restauração do banco de dados apenas uma vez. O primeiro comando RESTORE é um comando informativo que lê apenas o cabeçalho de backup e o último comando simplesmente dispara a recuperação sem realmente restaurar nenhum bit.

Consulte Também

Backup, restauração e recuperação de tabelas Memory-Optimized