Aidez-moi! Ma base de données principale est corrompue, je ne peux même pas mettre l'instance SQL en ligne! Quelles sont mes options pour récupérer mon serveur?
J'ai une sauvegarde de master, mais la page MSDN "Restauration de la base de données master" me demande de démarrer l'instance en mode mono-utilisateur, ce que je ne peux pas faire!
(Remarque: je laisse cette question sans précision quant à la version SQL, afin d'être une référence plus largement applicable. Il existe des questions similaires sur DBA.SE, mais aucune n'implique que le serveur ne puisse pas démarrer.)
Voici quelques pistes sur lesquelles j'examinerais. Ne faites pas tous de ceux-ci (certains sont des techniques différentes pour atteindre le même but), mais valent la peine d'être considérés:
1. Examinez directement le journal des erreurs SQL
Accédez directement au dossier contenant les journaux d'erreurs SQL et chargez le ERRORLOG
le plus récent dans le bloc-notes pour obtenir plus de détails sur les raisons pour lesquelles l'instance SQL ne démarre pas. Vous constaterez peut-être que le problème ne vient pas du tout de la base de données master.
2. Essayez de démarrer l'instance en mode mono-utilisateur
Voici un liste complète des options de démarrage pour SQL Server , y compris -m
(mode mono-utilisateur) et -f
(mode de configuration minimal). D'autres options vous permettent de spécifier le chemin d'accès à la base de données master, si tel est le problème.
Si vous êtes en mesure de démarrer l'instance, suivez les étapes dans l'article MSDN que vous avez lié pour restaurer la base de données master, ou cette procédure détaillée par Thomas LaRock .
Si une autre application saisit toujours la connexion mono-utilisateur avant de pouvoir, désactivez d'abord l'agent SQL pour qu'il ne démarre pas. Deuxièmement, voir les idées sur cette question pour utiliser le -m"Application Name"
paramètre pour spécifier le nom de l'application.
3. Restaurez master
dans une autre instance et copiez ses fichiers
J'ai seulement trouvé ne autre mention de cette technique non documentée, mais je l'ai utilisée avec succès le week-end dernier, donc cela pourrait valoir la peine d'essayer.
Si vous ne pouvez pas démarrer l'instance en mode mono-utilisateur, mais vous avez une autre instance SQL exécutant exactement la même version et build, essayez de restaurer la dernière bonne sauvegarde de la base de données maître connue de votre serveur mort vers l'autre instance:
master_please_god_let_this_work
), WITH MOVE
pour ne pas écraser master
sur votre bon serveurWITH NORECOVERY
. Je ne sais pas si cela est nécessaire, mais je me suis senti mieux que je savais que l'autre serveur n'allait rien changer dans le maître restauréALTER DATABASE [master_please_god_let_this_work] SET OFFLINE
master.mdf
et mastlog.ldf
les fichiers nécessaires pour remplacer les mauvais fichiers maîtres par vos versions restauréesmaster
.4. Reconstruisez les bases de données système
Si vous n'avez pas une autre instance exécutant la même version, ou si vous n'êtes pas à l'aise avec la procédure non documentée répertoriée dans # 3, ou si vous n'avez pas de sauvegardes de master
( pourquoi n'avez-vous pas de sauvegardes ??), vous pouvez reconstruire les bases de données système SQL à partir du disque d'installation d'origine :
Setup.exe /ACTION=REBUILDDATABASE /...
Lorsque cela est terminé, vous pouvez suivre les étapes liées précédemment pour restaurer master
à partir de votre dernière bonne sauvegarde. Vous devrez également restaurer une sauvegarde récente de msdb
pour conserver tous vos travaux, le calendrier des travaux et l'historique des travaux.
5. Restaurer toutes les bases de données USER dans une nouvelle instance SQL (ou existante)
Si vous avez déjà une autre instance existante en cours d'exécution (version SQL appropriée, suffisamment d'espace disque), je commencerais probablement les restaurations de base de données à partir des sauvegardes les plus récentes pendant que je travaille sur les autres étapes de dépannage ci-dessus, juste au cas où j'en aurais besoin.
Si votre nouvelle instance (ou réinstallée) a accès au même disque, il est beaucoup plus rapide de simplement les attacher en tant que nouvelles bases de données:
CREATE DATABASE foo
ON (FILENAME = 'D:\data\foo.mdf'),
(FILENAME = 'D:\data\foo_log.ldf')
FOR ATTACH;
6. Effectuez à nouveau toutes les modifications sur master
Une fois que vous avez réussi à restaurer master
(via l'une des techniques ci-dessus), vous devez rechercher toutes les modifications qui pourraient avoir été perdues, si elles ont été apportées après la sauvegarde que vous venez de restaurer:
Il n'y a aucun moyen magique de les trouver, vous devrez revenir à la documentation de votre propre entreprise pour ces types de changements, si vous en avez un.
Je voulais juste ajouter un problème possible et une solution que je viens de rencontrer - J'ai eu une situation similaire lors d'une mise à jour cumulative échouée (SQL2016 CU12) et des messages dans l'Observateur d'événements et le journal d'erreurs où disant "Impossible de récupérer la base de données principale. SQL Server est impossible à exécuter. Restaurez le maître à partir d'une sauvegarde complète, réparez-le ou reconstruisez-le. ", mais j'ai finalement trouvé que si je réexécutais simplement l'exécutable CU, il détectait l'état de la mise à niveau comme" Incomplètement installé "et me permettait d'exécuter simplement le mettre à jour à nouveau, après quoi il s'est terminé avec succès et la base de données principale et toutes les autres ont été ouvertes sans problème.