Reparo automático de página durante uma sessão de espelhamento de banco de dados
Desde o SQL Server 2008, um parceiro de espelhamento de banco de dados tenta se recuperar automaticamente de páginas corrompidas no banco de dados espelho resolvendo certos tipos de erros que impedem a leitura de uma página de dados. O parceiro que não está habilitado para ler uma página solicita uma cópia atualizada de outro parceiro. Se essa solicitação tiver êxito, a página ilegível será substituída pela cópia. Isso normalmente resolve o erro.
.gif "Observação") Observação |
|---|
O reparo automático de página pelos parceiros de espelhamento de banco de dados 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 poderia 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 |
|---|---|---|
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. |
|
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, consulte a tabela suspect_pages no banco de dados msdb.
Tipos de página que não podem ser reparados automaticamente
Os seguintes tipos de página de controle não podem ser reparados no espelhamento de banco de dados:
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
No banco de dados principal, haverá a tentativa de reparo automático de página apenas quando o nó estiver no estado SYNCHRONIZED e o servidor principal ainda estiver enviando registros de log ao servidor espelho. 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, o servidor principal insere uma linha na tabela suspect_pages com o status de erro apropriado. O servidor principal solicita uma cópia da página do servidor espelho. 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 servidor espelho espera o log ser refeito para o LSN especificado na solicitação. Depois, o servidor espelho tenta acessar a página do banco de dados espelho. Se a página puder ser acessada, o servidor espelho enviará a cópia da página ao servidor principal. Caso contrário, o servidor espelho retornará um erro ao servidor principal e ocorrerá falha na tentativa de reparo automático de página.
O servidor principal 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 = 4).
Se o erro de E/S de página causar quaisquer transações adiadas, após a página ser reparada, o servidor principal tentará resolver essas transações.
Manipulando erros de E/S no banco de dados espelho
Os erros de E/S em páginas de dados que acontecem no banco de dados espelho é manipulado do modo a seguir.
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 entrará no estado SUSPENDED. Nesse ponto, o servidor espelho insere uma linha na tabela suspect_pages com o status de erro apropriado. Depois, o servidor espelho solicita uma cópia da página do servidor principal.
O servidor principal tenta acessar a página do banco de dados espelho. Se a página não puder ser acessada, o servidor principal enviará a cópia da página ao servidor espelho.
Se o servidor espelho receber cópias de toda página solicitada, ele tentará retomar a sessão de espelhamento. Se 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 um servidor espelho não receber uma página solicitada do servidor principal, ocorrerá falha na tentativa de reparo automático de página e a sessão de espelhamento continuará suspensa. Se a sessão de espelhamento for retomada 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, mesmo para um banco de dados espelho, 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, você deve interceptar as exceções das 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.