La restauration de page en ligne atteint la limite de 1000

J'ai été chargé d'essayer de récupérer une base de données qui a souffert de corruption (en raison d'une défaillance d'E / S, qui a été corrigée depuis). Je ne connais pas la base de données ni ce qu'elle contient.

On m'a donné une vieille sauvegarde complète (~ 3 semaines) et une série de journaux de transactions ... mais il manque des journaux de transactions, donc je ne peux récupérer que jusqu'à une certaine date. Il manque environ 2,5 semaines de données (et de nombreuses données sont constamment ajoutées à cette base de données).

J'ai également reçu une copie de la base de données corrompue (qui est accessible, mais avec beaucoup de pages corrompues / manquantes).

J'ai essayé les DBCC CHECKDBcommandes typiques (toujours non repair_allow_data_loss, ce sera mon dernier recours si rien d'autre ne fonctionne).

Après que de nombreux va et vient dans la base de données (la base de données est un petit monstre de 1,5 téraoctet et tout ce que je fais est lent et prend du temps), j'ai essayé de faire une restauration de page en ligne à partir de la dernière bonne sauvegarde connue pour les pages corrompues.

Pour ce faire, j'ai fait un script qui crée de nombreuses RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'commandes à partir de la DBCC CHECKDBsortie (essentiellement une expression régulière et une distincte) ... jusqu'ici tout va bien, cela a fonctionné au point où il est dit que j'avais atteint une limite de 1000 pages par fichier (il y a 8 fichiers sur cette base de données) par commande de restauration.

Donc, il me demande de "terminer la restauration en ligne", mais je ne sais pas comment faire ... Je n'ai pas de journal de fin ou quoi que ce soit de plus complet que la sauvegarde complète avec laquelle je commence, donc Je ne sais pas comment terminer la restauration pour continuer à essayer avec le reste des pages.

J'en ai essayé un RESTORE DATABASE <foo> WITH RECOVERYmais ça n'a pas marché non plus, il me demande un journal que je n'ai pas.

Quelqu'un a-t-il des conseils sur la façon dont je pourrais essayer de récupérer quoi que ce soit d'ici? Ou comment "terminer" la restauration en ligne pour que je puisse continuer à essayer de récupérer plus de pages? Aurais-je le même problème si j'essaie une restauration hors ligne (essentiellement en ajoutant WITH NORECOVERYà tout, puis en essayant de la ramener à la fin?)

L'élaboration manuelle de la base de données est fondamentalement impossible à éliminer ... il y a des centaines de tables avec des millions de lignes et il n'y a aucune signification claire de ce que c'est. La base de données corrompue échouera sur les SELECTrequêtes après quelques millions de lignes, mais je ne suis pas sûr de pouvoir savoir où. J'ai essayé de reconstruire tous les index non clusterisés, mais il y a des pages corrompues avec des données de ligne, donc cela n'a pas fonctionné non plus.

Une certaine perte de données serait acceptable, mais la cohérence sur la base de données devrait au moins essayer d'être atteinte.

La base de données corrompue est toujours en ligne et les clients y travaillent (donc elle continue à obtenir de nouvelles données), donc tout processus que je fais sur le banc de laboratoire devrait être reproductible sur la base de données de production par la suite (le temps d'arrêt sera difficile pour elle).

Il s'agit de SQL Server 2014 Enterprise

PS: je ne suis pas DBA ... Je suis programmeur, mais le client a essayé des services de récupération d'urgence sql "experts" et ils ont abandonné, donc on m'a demandé de le regarder et de voir si je pouvais faire n'importe quoi.

Mise à jour : après de nombreux tests, la restauration page par page a été un échec, nous avons donc abandonné l'idée. Nous allons effectuer une récupération manuelle (en sélectionnant manuellement les enregistrements manquants dans les tables corrompues et en les insérant dans la dernière bonne sauvegarde connue), en faisant des outils automatisés pour cela (encore une fois, il y a des centaines et des centaines de tables).

La procédure standard consisterait à:

1. Obtenez les ID de page qui doivent être restaurés.
2. Démarrez une restauration de page avec une base de données complète.
3. Appliquez la sauvegarde différentielle la plus récente.
4. Appliquez les sauvegardes de journal suivantes.
5. Créez une nouvelle sauvegarde du journal.
6. Restaurez la nouvelle sauvegarde lob.

Une fois la nouvelle sauvegarde du journal appliquée, la restauration de la page est terminée et les pages sont alors utilisables.

Exemple de restauration

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  

Référence: Pages de restauration (SQL Server) (Microsoft Docs) Référence: Instructions RESTORE (Transact-SQL) (Microsoft Docs)

Cependant, vous avez des trous dans vos sauvegardes TLOG et la restauration avec la procédure ci-dessus peut ramener votre base de données dans un état que vous ne souhaitez pas.

Vous êtes dans une situation compliquée.

1. Votre base de données contient des pages corrompues et votre entreprise ajoute constamment de nouvelles données à une base de données présentant des problèmes. Cela pourrait entraîner un temps d'arrêt total de la base de données. Voulez- vous risquer cela?

2. Quelqu'un va être tenu responsable et plus vous essayez de le réparer, plus la direction pourrait être encline à décider que vous pourriez être cette personne à la fin. Voulez- vous risquer cela?

3. Vous vous mettez dans une situation difficile en assumant un rôle pour lequel vous n'étiez pas employé. Vous essayez de réaliser quelque chose dont ni les administrateurs de base de données de votre entreprise ni votre consultant externe n'étaient capables. Même si cela peut sembler être un geste noble, vous vous mettez en danger. Vous pourriez avoir «implicitement promis» quelque chose que vous ne pourrez jamais accomplir. Voulez- vous risquer cela?

4. Lorsque quelqu'un qui travaille avec la base de données interroge des données corrompues, il est possible qu'il reçoive un message d'erreur. Le travail quotidien est déjà impacté. Plus vous attendez avec l'inévitable, plus la productivité sera affectée. Voulez- vous risquer cela? (Cette question pourrait également être posée à la direction)

5. La procédure de sauvegarde de votre entreprise semble défectueuse (sinon comment les sauvegardes TLOG seraient-elles manquantes?) Et vous exécutez toujours votre base de données de production comme s'il n'y avait aucun problème. Voulez- vous risquer cela?

La meilleure recommandation que je puisse vous donner est d'arrêter la production et d'appeler Microsoft! Ou au moins appeler Microsoft et éventuellement arrêter la production.

Bien que mon écriture puisse sembler trop prudente et légèrement dramatisée de votre point de vue, je peux personnellement me rapporter à une expérience en tant que DBA où des données ont été perdues dans une situation similaire. Nous n'avons perdu qu'une demi-journée de données, mais nous avons dû resynchroniser beaucoup de données avec les systèmes environnants .

Plus vous attendez, plus la récupération pourrait coûter cher.

Quant à la limitation des restaurations de page, voici une citation de la documentation officielle:

le nombre maximal de pages pouvant être restaurées dans un seul fichier dans une séquence de restauration est de 1000 . Cependant, si vous avez plus d'un petit nombre de pages endommagées dans un fichier, envisagez de restaurer l'intégralité du fichier au lieu des pages.

^{(c'est moi qui souligne )}

Référence: Instructions RESTORE - Arguments (Transact-SQL) (Microsoft Docs)

Lorsque tout est revenu à la normale, les administrateurs de base de données et / ou les consultants externes peuvent envisager d'implémenter une politique / procédure de sauvegarde / restauration différente pour votre base de données. Comme il doit être opérationnel 7x24, vous ne pouvez pas risquer d'avoir une procédure de sauvegarde qui ne fournit pas de capacités de restauration adéquates pour n'importe quelle situation.

Je vois que vous avez essayé différentes méthodes, notamment en travaillant avec des «experts» en récupération de données pour réparer cette base de données corrompue, en particulier avec une taille de plus de 1 To. Cela rend le processus beaucoup plus difficile et une course contre la montre. En tant qu'administrateur de base de données expérimenté, j'ai rencontré des situations similaires où la plupart du temps, de bonnes sauvegardes sont disponibles pour la restauration. En cas d'héritage de sauvegardes incorrectes et de bases de données corrompues, je me suis fortement appuyé sur un outil tiers appelé Stellar Phoenix SQL Database Repair Tool . Cet outil est bien connu pour réparer les bases de données corrompues (.mdf et .ndf). Voici les quelques fonctionnalités de l'outil:

• Répare les fichiers de base de données SQL corrompus (.mdf et .ndf)
• Récupère les tables, déclencheurs, index, clés, règles et procédures stockées

• Effectue la récupération des enregistrements supprimés de la base de données SQL

• Enregistre le résultat de l'analyse de la base de données pour effectuer la récupération à un stade ultérieur

• Permet l'enregistrement du fichier réparé aux formats MSSQL, HTML, XLS et CSV
• Prend en charge MS SQL Server 2016, 2014, 2012,2008 et les versions antérieures

L'outil nécessite que les fichiers .mdf et .ndf soient hors ligne, donc cela fonctionne très bien que vous ayez une copie de la base de données PROD corrompue et que vous n'ayez pas à arrêter les services SQL Server.

La meilleure partie est que la version d'essai vous offre toutes les fonctionnalités de l'outil, sauf que la base de données réparée ne peut pas être exportée / enregistrée. Vous pourrez toujours voir tous les objets de base de données récupérés et le fichier journal de réparation complet qui fournit des détails sur les différentes étapes du processus de réparation.

N'hésitez pas à télécharger et voir si cela aide. Télécharger ici

J'ai également écrit un blog sur le fonctionnement de l'outil sur ce site: blogs samosql

Merci et HTH de faire de vous le HÉROS de la journée!

PS. Lorsque cette tempête est terminée, n'oubliez pas de dire à la direction qu'il doit y avoir une refonte majeure de leurs procédures de sauvegarde, en particulier pour une telle base de données. Une répétition de ce scénario est totalement inacceptable! :)