Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: 
SQL Server
A reparação automática de páginas é suportada pelo espelhamento de bases de dados e pelos grupos de disponibilidade Always On. Depois de determinados tipos de erros corromperem uma página, tornando-a ilegível, um parceiro de espelhamento da base de dados (principal ou de 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 pede uma cópia nova da página ao seu parceiro ou a outra réplica. Se este pedido for bem-sucedido, a página ilegível é substituída pela cópia legível, o que normalmente resolve o erro.
De um modo geral, os grupos de espelhamento de bases de dados e de disponibilidade Always On tratam erros de E/S de forma equivalente. As poucas diferenças são explicitamente destacadas aqui.
Note
A reparação automática de página difere da reparação com DBCC. Todos os dados são preservados através da reparação automática de páginas. Em contrapartida, corrigir erros ao utilizar a opção DBCC REPAIR_ALLOW_DATA_LOSS pode exigir que algumas páginas e, consequentemente, alguns dados tenham de ser eliminados.
Tipos de erro que causam uma tentativa automática de reparação de páginas
Gestão de erros de I/O na base de dados espelhada/secundária
Como: visualizar tentativas automáticas de reparação de páginas
Tipos de erro que provocam uma tentativa automática de reparação de página
A reparação automática de páginas com espelhamento de base de dados tenta reparar apenas páginas num ficheiro de dados em que uma operação falhou por um dos erros listados na tabela seguinte.
| Número do erro | Description | Instâncias que provocam uma tentativa automática de reparação da página |
|---|---|---|
| 823 | A ação só é tomada se o sistema operativo tiver realizado uma verificação cíclica de redundância (CRC) que falhou nos dados. | ERROR_CRC. O valor do sistema operativo para este erro é 23. |
| 824 | Erros lógicos. | Erros lógicos de dados, como escrita truncada ou soma de controlo de página incorreta. |
| 829 | Uma página foi marcada como pendente de restauro. | Todos. |
Para ver os erros CRC 823 recentes e os erros 824, consulte a tabela suspect_pages na base de dados msdb.
Tipos de Página que Não Podem Ser Reparados Automaticamente
A reparação automática de páginas não pode reparar os seguintes tipos de páginas de controlo:
Página do cabeçalho do ficheiro (ID da página 0).
Página 9 (a página de arranque da base de dados).
Páginas de alocação: páginas do Mapa de Alocação Global (GAM), páginas do Mapa de Alocação Global Compartilhada (SGAM) e páginas de Espaço Livre de Página (PFS).
Tratamento de Erros de I/O na Base de Dados Principal/Primária
Na base de dados principal/primária, a reparação automática da página é tentada apenas quando a base de dados está no estado SINCRONIZADO e o principal/primário ainda está a enviar registos de registo da base de dados para o espelho/secundário. A sequência básica de ações numa tentativa automática de reparação de páginas é a seguinte:
Quando ocorre um erro de leitura numa página de dados na base de dados principal/primária, o principal/primário insere uma linha na tabela suspect_pages com o estado de erro apropriado. Para o espelhamento da base de dados, o servidor principal solicita, então, uma cópia da página ao servidor espelho. Para grupos de disponibilidade Sempre Ligados, o primário transmite o pedido para todas as secundárias e recebe a página do primeiro para responder. O pedido especifica o ID da página e o LSN que está atualmente no final do registo limpo. A página está marcada como pendente de restauração. Isto torna-o inacessível durante a tentativa automática de reparação da página. As tentativas de aceder a esta página durante a tentativa de reparação falharão com o erro 829 (restauração pendente).
Depois de receber o pedido de página, o espelho/secundário espera até ter refeito o registo até ao LSN especificado no pedido. Depois, o espelho/secundário tenta aceder à página na sua cópia da base de dados. Se for possível aceder à página, o espelho/secundário envia a cópia da página para o principal/primário. Caso contrário, o espelho/secundário devolve um erro ao principal/primário, e a tentativa automática de reparação da página falha.
O principal/primário processa a resposta que contém a nova cópia da página.
Após a tentativa automática de reparação de páginas corrigir uma página suspeita, a página é marcada na tabela de suspect_pages como restaurada (event_type = 5).
Se o erro de I/O da página causou transações adiadas, depois de a página ser reparada, o servidor principal/primário tenta resolver essas transações.
Gestão de erros de I/O na base de dados espelha/secundária
Os erros de I/O em páginas de dados que ocorrem na base de dados espelhada/secundária são tratados geralmente da mesma forma pelo espelhamento da base de dados e pelos grupos de disponibilidade Always On.
Com o espelhamento de base de dados, se o espelho encontrar um ou mais erros de I/O de página ao refazer um registo de log, a sessão de espelhamento entra no estado SUSPENSO. Nos grupos de disponibilidade Always On, se uma réplica secundária encontrar um ou mais erros de I/O de página ao refazer um registo de log, a base de dados secundária entra no estado SUSPENSO. Nesse ponto, o espelho/secundário insere uma linha na tabela suspect_pages com o estado de erro adequado. O espelho/secundário solicita então uma cópia da página ao principal/primário.
O principal/o primário tenta aceder à página na respetiva cópia da base de dados. Se a página for acessível, o principal/primário envia uma cópia da página para o espelho/secundário.
Se o espelho/secundário receber cópias de todas as páginas que solicitou, o espelho/secundário tenta retomar a sessão de espelhamento. Se uma tentativa automática de reparação de páginas corrigir uma página suspeita, a página é marcada na tabela de suspect_pages como restaurada (event_type = 4).
Se um espelho/secundário não receber a página que solicitou ao principal/primário, a tentativa automática de reparação da página falha. Com o espelhamento da base de dados, a sessão de espelhamento permanece suspensa. Com os grupos de disponibilidade Always On, a base de dados secundária permanece suspensa. Se a sessão de espelhamento ou a base de dados secundária for retomada manualmente, as páginas corrompidas serão novamente atingidas durante a fase de sincronização.
Boas Práticas para Desenvolvedores
Uma reparação automática de páginas é um processo assíncrono que corre em segundo plano. Assim, uma operação de base de dados que solicita uma página ilegível falha e devolve o código de erro da condição que causou a falha. Ao desenvolver uma aplicação para uma base de dados espelhada ou uma base de dados de disponibilidade, deve intercetar exceções para operações falhadas. Se o código de erro do SQL Server for 823, 824 ou 829, deve tentar novamente a operação mais tarde.
Como ver tentativas de reparação automática de páginas
As seguintes vistas de gestão dinâmica devolvem até 100 linhas por base de dados relativas às tentativas mais recentes de reparação automática de páginas numa determinada base de dados de disponibilidade ou base de dados em espelho.
Grupos de Disponibilidade Sempre Ativos:
sys.dm_hadr_auto_page_repair (Transact-SQL)
Devolve uma linha para cada tentativa automática de reparação de páginas em qualquer base de dados de disponibilidade numa réplica de disponibilidade alojada para qualquer grupo de disponibilidade pela instância do servidor.
Espelhamento de bases de dados:
sys.dm_db_mirroring_auto_page_repair (Transact-SQL)
Retorna uma linha para cada tentativa automática de reparação de páginas em qualquer base de dados espelhada na instância do servidor.