Restauration de pages
Cette rubrique s'applique aux bases de données SQL Server employant les modes de restauration complète ou de récupération utilisant les journaux de transactions. La restauration de pages n'est prise en charge que pour les groupes de fichiers en lecture-écriture.
Dans la restauration de pages, l'objectif est de restaurer une ou plusieurs pages endommagées sans restaurer toute la base de données. Généralement, les pages candidates à la restauration ont été marquées « suspectes » en raison d'une erreur rencontrée lors de l'accès à la page. Les pages suspectes sont identifiées dans la table suspect_pages dans la base de données msdb.
Notes
Toutes les erreurs de page n'exigent pas une restauration. Il peut arriver qu'un problème survenant dans les données en cache, dans un index secondaire par exemple, ne puisse pas être résolu en recalculant les données. Par exemple, si l'administrateur de la base de données supprime un index secondaire et le reconstruit, les données endommagées, bien qu'ayant été corrigées, ne sont pas indiquées comme telles dans la table suspect_pages.
Plusieurs pages de bases de données peuvent être restaurées immédiatement. Les sauvegardes des fichiers journaux sont appliquées à tous les fichiers de base de données qui contiennent une page en cours de récupération. Comme dans le cas d'une restauration de fichiers, le jeu de restauration par progression est une opération avancée qui s'effectue en une seule passe.
La restauration de pages permet de réparer des pages endommagées. La restauration et la récupération de quelques pages individuelles peuvent être plus rapides qu'une restauration de fichiers, ce qui réduit le nombre de données qui restent hors ligne pendant l'opération. Toutefois, si vous avez besoin de restaurer un plus grand nombre de pages d'un fichier, il est généralement plus efficace de restaurer l'ensemble du fichier. Par exemple, si de nombreuses pages sur une unité indiquent une défaillance possible de l'unité, envisagez de restaurer le fichier éventuellement dans un emplacement différent et de réparer l'unité.
Scénarios de restauration de pages
Toutes les éditions de SQL Server 2005 et versions ultérieures prennent en charge la restauration des pages lorsque la base de données est hors connexion (restauration de pages hors ligne). Dans SQL Server 2005 Enterprise Edition et versions ultérieures, si la base de données est en ligne au cours d'une restauration de pages, elle reste en ligne. Le processus de restauration et de récupération d'une page lorsque la base de données est en ligne est appelé restauration de pages en ligne.
Ces scénarios de restauration de pages sont les suivants :
Restauration de pages hors connexion
SQL Server 2005 Standard, SQL Server 2005 Express Edition et SQL Server 2005 Workgroup, et versions ultérieures, ne prennent en charge que la restauration hors ligne. SQL Server 2005 Enterprise Edition et les versions ultérieures font appel à la restauration hors ligne si la base de données est déjà hors connexion. Dans une restauration de pages hors connexion, la base de données est hors connexion pendant que les pages endommagées sont restaurées. À la fin de la séquence de restauration, la base de données devient en ligne.
Pour que la restauration de pages aboutisse, les pages restaurées doivent être récupérées dans un état cohérent avec la base de données. Si une chaîne ininterrompue de sauvegardes de journaux doit être appliquée à la dernière restauration complète ou différentielle pour restaurer par progression la page jusqu'au fichier journal actuel.
Restauration de pages en ligne
Dans SQL Server 2005 Enterprise Edition et versions ultérieures, si les conditions le permettent, les restaurations de pages sont automatiquement des restaurations en ligne. Dans la plupart des cas, il est possible de restaurer une page endommagée si la base de données, ainsi que le groupe de fichiers vers lequel une page est restaurée, reste en ligne. La restauration de pages en ligne est particulièrement utile pour les pages endommagées par une erreur matérielle.
Une page endommagée peut nécessiter parfois une restauration hors connexion. Il arrive par exemple que l'état de certaines pages critiques empêche le démarrage de la base de données. Dans ces cas, la restauration hors connexion est nécessaire.
Notes
Une restauration en ligne tente de mettre à jour les métadonnées et cette mise à jour peut échouer si une page essentielle est impliquée. En cas d'échec d'une restauration en ligne, la restauration doit être effectuée en mode hors connexion.
La restauration de pages bénéficie de la fonction améliorée de signalisation des erreurs au niveau de la page (avec sommes de contrôle) et du suivi de SQL Server 2005 et versions ultérieures. Les pages endommagées détectées par somme de contrôle ou une erreur d'écriture, pages endommagées, peuvent être restaurées en spécifiant les pages dans une instruction RESTORE. La restauration de pages est destinée à ne réparer que quelques pages endommagées. Chaque page spécifiée dans une instruction RESTORE est remplacée par une page du jeu de sauvegarde spécifié. Les pages restaurées doivent être récupérées dans un état cohérent avec la base de données. Seules les pages spécifiées explicitement sont restaurées.
Limites des restaurations de pages
Seules les pages de bases de données peuvent être restaurées. La restauration de pages ne peut pas être utilisée pour restaurer les éléments suivants :
Journal des transactions
Pages d'allocation : pages Global Allocation Map (GAM), pages Shared Global Allocation Map (SGAM) et pages Page Free Space (PFS). Pour plus d'informations, consultez Gestion des allocations des extensions et de l'espace libre.
Page 0 de tous les fichiers de données (page de démarrage des fichiers)
Page 1:9 (page de démarrage de la base de données)
Catalogue de texte intégral
Si une page isolée ne peut pas être restaurée, vous devez utiliser la sauvegarde complète de la base de données, ou la sauvegarde complète du fichier ou du groupe de fichiers.
Notes
Si la page à restaurer est un cas spécial, tel que les pages de métadonnées, la restauration de page en ligne échouera. Dans ces cas particuliers, essayez une restauration de pages hors connexion.
Conditions requises pour la restauration de pages
La restauration de pages est soumises aux conditions suivantes :
Les bases de données doivent utiliser le mode de restauration complète ou de récupération utilisant les journaux de transactions. Certains problèmes sont connus dans le cas d'une utilisation du mode de récupération utilisant les journaux de transactions. Pour plus d'informations, consultez la section suivante.
Les pages de groupes de fichiers en lecture seule ne peuvent pas être restaurées. Toute tentative de mise en lecture seule d'un groupe de fichiers échouera tant qu'une restauration de pages concernant ce groupe de fichiers est en cours.
La séquence de restauration doit commencer par une sauvegarde complète, de fichier ou de groupe de fichiers.
Une restauration de pages requiert une chaîne ininterrompue de sauvegardes de journaux jusqu'au fichier journal actuel. Celles-ci doivent toutes être appliquées de manière à ce que la page soit mise à jour en fonction des informations contenues dans le fichier journal actuel.
Comme dans une séquence de restauration de fichiers, vous pouvez ajouter des pages au jeu de restauration par progression à chaque étape.
Il est impossible d'exécuter une restauration de pages et une sauvegarde de base de données simultanément.
Restauration de pages et mode de récupération utilisant les journaux de transactions
La fonction de restauration de pages est soumise aux conditions supplémentaires suivantes lorsque la base de données utilise le mode de récupération utilisant les journaux de transactions.
La sauvegarde d'un groupe de fichiers ou de données de pages hors connexion pose problème au niveau des données journalisées en bloc étant donné que les données hors connexion ne sont pas enregistrées dans le journal. Une page hors connexion peut empêcher la sauvegarde du journal. Dans ce cas, envisagez l'utilisation de DBCC REPAIR car cette solution peut davantage minimiser la perte de données que la restauration de la sauvegarde la plus récente.
Si une sauvegarde de fichier journal d'une base de données journalisée en bloc rencontre une page endommagée, elle échoue à moins que WITH CONTINUE_AFTER_ERROR n'ait été spécifié.
La restauration de pages ne fonctionne généralement pas avec la récupération utilisant les journaux de transactions.
La méthode recommandée pour effectuer une restauration de pages consiste à affecter à la base de données le mode de restauration complète et à tenter une sauvegarde du journal. Si la sauvegarde du journal fonctionne, vous pouvez poursuivre la restauration de la page. Si elle échoue, soit vous perdez effectivement le travail effectué depuis la dernière sauvegarde du journal, soit vous tentez d'exécuter DBCC avec l'option REPAIR_ALLOW_DATA_LOSS.
Syntaxe de base de la restauration de pages
Pour spécifier une page dans une instruction RESTORE DATABASE, vous avez besoin de l'ID du fichier qui contient la page et l'ID de la page. La syntaxe requise est la suivante :
RESTORE DATABASE database_name
PAGE ='file:page [ ,...n ]' [ ,...n ]
FROM <backup_device> [ ,...n ]
WITH NORECOVERY
Pour plus d'informations sur les paramètres de l'option PAGE, consultez Arguments RESTORE (Transact-SQL). Pour plus d'informations sur la syntaxe RESTORE DATABASE, consultez RESTORE (Transact-SQL).
Procédure de restauration d'une page
La restauration d'une page comprend généralement les étapes suivantes :
Obtenez les ID des pages endommagées à restaurer. Une somme de contrôle ou une erreur d'écriture renvoie un ID de page fournissant les informations nécessaires pour la spécification des pages. Pour rechercher l'ID de page d'une page endommagée, utilisez une des sources suivantes.
Source d'ID de page
Rubrique
msdb..suspect_pages
Journal des erreurs
Traces d'événements
DBCC
Fournisseur WMI
Démarrez une restauration de pages avec une sauvegarde complète de base de données, de fichier ou de groupe de fichiers contenant la page. Dans l'instruction RESTORE DATABASE, utilisez la clause PAGE pour énumérer les ID de toutes les pages à restaurer.
PAGE ='file:page [ ,...n ]'
Appliquez les sauvegardes différentielles les plus récentes.
Appliquez les sauvegardes des journaux suivants.
Créez une nouvelle sauvegarde de journal de la base de données incluant le NSE final des pages restaurées, c'est-à-dire le point auquel la dernière page restaurée est placée en mode hors connexion. Le NSE final, qui est défini dans le cadre de la première restauration dans la séquence, est le NSE cible de restauration par progression. La restauration en ligne par progression du fichier contenant la page est capable de s'arrêter au NSE cible de restauration par progression. Pour connaître le NSE cible actuel de restauration d'un fichier, consultez la colonne redo_target_lsn de sys.master_files. Pour plus d'informations, consultez sys.master_files (Transact-SQL).
Restaurez la nouvelle sauvegarde de fichier Une fois appliquée cette nouvelle sauvegarde de journal, la restauration des pages est terminée et les pages sont désormais utilisables.
Notes
Cette séquence est analogue à une séquence de restauration de fichier. En fait, la restauration de pages et les restaurations de fichiers peuvent être effectuées dans le cadre de la même séquence.
Exemple
Cet exemple restaure quatre pages endommagées du fichier B à l'aide de NORECOVERY. Ensuite, deux sauvegardes de journal sont appliquées à l'aide de NORECOVERY, suivies de la sauvegarde de fichier journal après défaillance, qui est restaurée à l'aide de RECOVERY.
Important
Si les pages endommagées contiennent des métadonnées critiques pour la base de données, une séquence de restauration de pages hors connexion peut se révéler nécessaire. Pour effectuer une restauration hors connexion, vous devez sauvegarder le journal des transactions à l'aide de WITH NORECOVERY.
L'exemple suivant effectue une restauration en ligne. Dans l'exemple, l'ID de fichier B est 1, et les ID des pages endommagées sont 57, 202, 916, et 1016.
RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'
FROM <file_backup_of_file_B>
WITH NORECOVERY;
RESTORE LOG <database> FROM <log_backup>
WITH NORECOVERY;
RESTORE LOG <database> FROM <log_backup>
WITH NORECOVERY;
BACKUP LOG <database> TO <new_log_backup>
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;
GO