Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se:
SQL Server
O reparo automático de página é compatível com o espelhamento de banco de dados e com os grupos de disponibilidade do Always On. Após certos tipos de erro corromperem uma página, tornando-a ilegível, um parceiro de espelhamento de banco de dados (principal ou espelho) ou uma réplica de disponibilidade (primária ou secundária) tenta recuperar automaticamente a página. O parceiro/réplica que não consegue ler a página solicita uma nova cópia da página ao parceiro ou a 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 tratam erros de E/S de maneira equivalente. As poucas diferenças são destacadas explicitamente aqui.
Observação
O reparo automático de página difere do reparo executado pelo DBCC. Um reparo automático da página preserva todos os dados. Em contrapartida, corrigir erros usando a opção DBCC REPAIR_ALLOW_DATA_LOSS pode exigir que algumas páginas e, portanto, alguns 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áginas do espelhamento de banco de dados tenta reparar apenas páginas em um arquivo de dados nas quais uma operação falhou devido a um dos erros listados na tabela a seguir.
| Número do erro | Descrição | Instâncias que causam uma tentativa automática de reparo da página |
|---|---|---|
| 823 | Uma ação será tomada apenas se o sistema operacional tiver realizado uma verificação de redundância cíclica (CRC) que detectou falha 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 CRC 823 recentes e erros 824, 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).
Tratamento de erros de E/S no banco de dados principal/primário
No banco de dados principal/primário, o reparo automático de página é tentado apenas quando o banco de dados está no estado SYNCHRONIZED e o principal/primário ainda está enviando registros de log do banco de dados para o banco de dados 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 ao espelho uma cópia da página. Para grupos de disponibilidade Always On, o primário envia a solicitação a todos os secundários e recebe 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 está 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 pode 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 para o principal/primário, e a tentativa de reparo automático da página falhará.
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 da página tiver causado alguma transação adiada, depois de reparar a página, o servidor principal/primário tentará resolver essas transações.
Tratamento de 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 geralmente são tratados da mesma maneira pelo espelhamento de banco de dados e pelos Grupos de Disponibilidade Always On.
Com o espelhamento de banco de dados, se o servidor espelho encontrar um ou mais erros de E/S de página ao refazer um registro de log, a sessão de espelhamento passará para o estado SUSPENDED. Nos grupos de disponibilidade Always On, se uma réplica secundária encontrar um ou mais erros de E/S de página ao reaplicar um registro de log, o banco de dados secundário entrará no estado SUSPENSO. Nesse ponto, o espelho/secundário insere uma linha na tabela suspect_pages com o status de erro adequado. O espelho/secundário então solicita uma cópia da página da principal/primária.
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. Nos grupos de disponibilidade Always On, 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 automática de reparo de página em qualquer banco de dados espelhado na instância do servidor.