Reparo automático de página (para grupos de disponibilidade e espelhamento de banco de dados)
O reparo automático de página é compatível com o espelhamento de banco de dados e Always On Grupos de Disponibilidade. Depois que certos tipos de erros corrompem uma página, tornando-a ilegível, um parceiro de espelhamento de banco de dados (entidade de segurança ou espelho) ou uma réplica de disponibilidade (primária ou secundária) tenta recuperar a página automaticamente. O parceiro/réplica que não puder ler a página solicitará uma cópia atualizada da página do seu parceiro ou de outra réplica. Se essa solicitação tiver êxito, a página ilegível será substituída pela cópia legível. Isso costuma resolver o erro.
Em geral, o espelhamento de banco de dados e os grupos de disponibilidade Always On lidam com erros de E/S de maneiras equivalentes. As poucas diferenças são destacadas explicitamente aqui.
Observação
O reparo automático de página difere do reparo de DBCC. Todos os dados são preservados por um reparo automático de página. Por outro lado, a correção de erros usando a opção DBCC REPAIR_ALLOW_DATA_LOSS pode exigir que algumas páginas e, portanto, dados, sejam excluídos.
Tipos de erro que causam uma tentativa de reparo automático de página
O reparo automático de página do espelhamento de banco de dados tenta reparar apenas páginas em um arquivo de dados no qual houve falha na operação de um dos erros listados na tabela a seguir.
| Número do erro | Descrição | Instâncias que causam uma tentativa de reparo automático de página |
|---|---|---|
| 823 | Ação realizada apenas se o sistema operacional tiver executado uma CRC (verificação de redundância cíclica) que falhou nos dados. | ERROR_CRC. O valor do sistema operacional desse erro é 23. |
| 824 | Erros lógicos. | Erros de dados lógicos, como gravação interrompida ou soma de verificação de página inválida. |
| 829 | Uma página foi marcada como restauração pendente. | Todos. |
Para exibir erros 823 CRC e erros 824 recentes, veja a tabela suspect_pages no banco de dados msdb .
Tipos de página que não podem ser reparados automaticamente
O reparo automático de página não pode reparar os seguintes tipos de página de controle:
Página de cabeçalho do arquivo (ID da página 0).
Página 9 (a página de inicialização do banco de dados).
Páginas de alocação: páginas GAM (Global Allocation Map), páginas SGAM (Shared Global Allocation Map) e páginas PFS (Page Free Space).
Manipulando erros de E/S no banco de dados principal/primário
No banco de dados principal/primário, haverá a tentativa de reparo automático de página apenas quando o estado do banco de dados for SYNCHRONIZED e o principal/primário ainda estiver enviando registros de log do banco de dados ao espelho/secundário. A sequência básica de ações em uma tentativa de reparo automático de página é a seguinte:
Quando ocorre um erro de leitura em uma página de dados no banco de dados principal/primário, o principal/primário insere uma linha na tabela suspect_pages com o status de erro apropriado. Para o espelhamento de banco de dados, o principal solicita uma cópia da página do espelho. Para Always On Grupos de Disponibilidade, o primário transmite a solicitação para todos os secundários e obtém a página do primeiro para responder. A solicitação especifica a ID da página e o LSN que estão atualmente na parte final do log liberado. A página é marcada como restauração pendente. Isso a torna inacessível durante a tentativa de reparo automático de página. Ocorrerá falha com o erro 829 nas tentativas de acesso a essa página durante a tentativa de reparo (restauração pendente).
Após o recebimento da solicitação de página, o espelho/secundário espera o log ser refeito para o LSN especificado na solicitação. Depois, o espelho/secundário tenta acessar a página em sua cópia do banco de dados. Se a página puder ser acessada, o espelho/secundário enviará a cópia da página ao principal/primário. Caso contrário, o espelho/secundário retornará um erro ao principal/primário e ocorrerá uma falha na tentativa de reparo automático de página.
O principal/primário processa a resposta que contém a cópia atualizada da página.
Depois que a tentativa de reparo automático de página reparar uma página suspeita, a página será marcada na tabela suspect_pages como restaurada (event_type = 5).
Se o erro de E/S de página causar quaisquer transações adiadas, após a página ser reparada, o principal/primário tentará resolver essas transações.
Manipulando erros de E/S no banco de dados espelho/secundário
Erros de E/S em páginas de dados que ocorrem no banco de dados espelho/secundário geralmente são tratados da mesma maneira pelo espelhamento de banco de dados e por Always On Grupos de Disponibilidade.
Com o espelhamento de banco de dados, se o espelho encontrar um ou mais erros de E/S de página ao refazer um registro de log, a sessão de espelhamento entrará no estado SUSPENDED. Com Always On Grupos de Disponibilidade, se um réplica secundário encontrar um ou mais erros de E/S de página ao refazer um registro de log, o banco de dados secundário entrará no estado SUSPENDED. Nesse ponto, o espelho/secundário insere uma linha na tabela suspect_pages com o status de erro apropriado. O espelho/secundário solicita uma cópia da página do principal/primário.
O principal/primário tenta acessar a página em sua cópia do banco de dados. Se a página puder ser acessada, o principal/primário enviará a cópia da página ao espelho/secundário.
Se o espelho/secundário receber cópias de cada página solicitada, ele tentará retomar a sessão de espelhamento. Se uma tentativa de reparo automático de página reparar uma página suspeita, a página será marcada na tabela suspect_pages como restaurada (event_type = 4).
Se um espelho/secundário não receber uma página solicitada do principal/primário, ocorrerá falha na tentativa de reparo automático de página. Com o espelhamento de banco de dados, a sessão de espelhamento permanece suspensa. Com Always On Grupos de Disponibilidade, o banco de dados secundário permanece suspenso. Se a sessão de espelhamento ou o banco de dados secundário for retomado de forma manual, as páginas corrompidas serão acionadas novamente durante a fase de sincronização.
Prática recomendada de desenvolvedor
Um reparo automático de página é um processo assíncrono executado em segundo plano. Portanto, ocorre falha na operação de banco de dados que solicita uma página ilegível e o código de erro é retornado para qualquer condição que causou a falha. Ao desenvolver um aplicativo para um banco de dados espelho ou um banco de dados de disponibilidade, você deve interceptar as exceções para operações com falha. Se o código de erro SQL Server for 823, 824 ou 829, você deverá tentar novamente a operação mais tarde.
Como exibir tentativas de reparo automático de página
As exibições de gerenciamento dinâmico a seguir retornam linhas para as últimas tentativas de reparo automático de página em determinado banco de dados de disponibilidade ou banco de dados espelho, com um máximo de 100 linhas por banco de dados.
Grupos de Disponibilidade AlwaysOn:
sys.dm_hadr_auto_page_repair (Transact-SQL)
Retorna uma linha para cada tentativa de reparo automático de página em qualquer banco de dados de disponibilidade em uma réplica de disponibilidade hospedada para qualquer grupo de disponibilidade pela instância do servidor.
Espelhamento de banco de dados:
sys.dm_db_mirroring_auto_page_repair (Transact-SQL)
Retorna uma linha para cada tentativa de reparo automático de página em qualquer banco de dados espelho na instância de servidor.
Consulte Também
Gerenciar a tabela suspect_pages (SQL Server)
Visão geral de grupos de disponibilidade AlwaysOn (SQL Server)
Espelhamento de banco de dados (SQL Server)