Reparo automático de página (Grupos de Disponibilidade: espelhamento de banco de dados)
Aplica-se a: 
SQL Server
O reparo automático de página tem suporte do espelhamento de banco de dados e de Grupos de disponibilidade AlwaysOn. 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 Grupos de disponibilidade AlwaysOn tratam erros de E/S de formas 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
Manipulando erros de E/S no banco de dados principal/primário
Manipulando erros de E/S no banco de dados espelho/secundário
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 Grupos de disponibilidade AlwaysOn, o primário transmite a solicitação a todos os secundários e obtém a página do primeiro a 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
Os erros de E/S em páginas de dados que ocorrem no banco de dados espelho/secundário costumam ser tratados da mesma forma pelo espelhamento de banco de dados e pelo Grupos de disponibilidade AlwaysOn.
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 o Grupos de disponibilidade AlwaysOn, se uma réplica secundária 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 o Grupos de disponibilidade AlwaysOn, 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 dos Grupos de Disponibilidade AlwaysOn (SQL Server)
Espelhamento de banco de dados (SQL Server)