La restauration de page en ligne atteint la limite de 1000

Question

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é le DBCC CHECKDB commandes (toujours pas de 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 créé un script qui crée de nombreux RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>' commandes du DBCC CHECKDB sortie (essentiellement une expression régulière et une expression distincte) ... jusqu'à présent tout va bien, jusqu'à ce qu'il soit 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'ai essayé un RESTORE DATABASE <foo> WITH RECOVERY mais cela n'a pas fonctionné 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 (en gros, en ajoutant WITH NORECOVERY à tout puis essayer de le ramener à la fin?)

L'élaboration manuelle de la base de données est fondamentalement impossible à éliminer ... il existe 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 requêtes SELECT après quelques millions de lignes mais je ne suis pas sûr de pouvoir trouver 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 un DBA ... je suis un 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 était un no-go, nous avons donc abandonné l'idée. Nous allons faire 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).

John aka hot2use · Answer

La procédure standard consisterait à:

Obtenez les ID de page qui doivent être restaurés.
Démarrez une restauration de page avec une base de données complète.
Appliquez la sauvegarde différentielle la plus récente.
Appliquez les sauvegardes de journal suivantes.
Créez une nouvelle sauvegarde du journal.
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.

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. vous voulez-vous risquer cela?
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. vous voulez-vous risquer cela?
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. Bien que cela puisse sembler être un geste noble, vous vous mettez en danger. Vous pourriez avoir "implicitement promis" quelque chose que vous ne pourrez jamais accomplir. vous voulez-vous risquer cela?
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. vous voulez-vous risquer cela? (Cette question pourrait également être posée à la direction)
La procédure de sauvegarde de votre entreprise semble être 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. vous 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 seulement avons perdu 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 n'importe quel 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.

^{( accentuation la mienne)}

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.

samosql · Answer

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 supérieure à 1 To. Cela rend le processus beaucoup plus difficile et une course contre la montre. En tant que DBA 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éparer les fichiers de base de données SQL corrompus (.mdf & .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 d'enregistrer le fichier réparé aux formats MSSQL, HTML, XLS & 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échargez 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 du jour!

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! :)