- Dans un premier temps, détacher la base de données de l'Enterprise Manager et enregistré le fichier MDF dans un endroit sûr.
- Création d'un nouvelle base de données ayant le même nom et au même endroit où l'original a été conservé.
- Maintenant, arrêté le service SQL Server et remplace les fichiers de base de données (à la fois MDF et LDF) de la base de données SQL nouvellement créé avec les fichiers de base de données de la base de données corrompues.
- Redémarré le service et Enterprise Manager, puis lancé.
- La base de données est maintenant en mode suspect.
'Sp_configure' allow updates ', 1
go '
«Reconfigurer avec priorité
go '
Maintenant, il est facile de modifier les tables du catalogue système.
Pour vérifier l'état de base de données, j'ai lancé la commande suivante:
»Sélectionner l'état de sysdatabases où nom = 'le nom de votre base de données' (remplacer par le nom de votre base de données)»
Ensuite, exécuté ceci:
«Mise à jour sysdatabases
définir l'état = 32768 WHERE nom = 'le nom de votre base de données'
Redémarré le service SQL Server de basculer automatiquement en mode d'urgence.
Créé une base de données de récupération nommé 'dbrecover »et déplacé toutes les données dans la base de données endommagée à la base de données de récupération grâce à de nouveaux DTS (Data Transformation Services).
Pour reconstruire le journal, utilisé DBCC comme suit:
«DBCC rebuild_log (« votre nom de base de données ',' nom de fichier avec le chemin nouveau journal ')'
Ensuite, exécuter la série de commandes suivante sur la base de données:
«Use master
go '
«Sp_dboption« votre nom de base de données ',' SINGLE_USER ',' true '
go '
«DBCC CHECKDB ('le nom de votre base de données', repair_allow_data_loss)
go '
Changement de statut de l'arrière à l'utilisation de base de données normale:
«Use master
go '
«Mise à jour sysdatabases
définir l'état = 0 where name = 'le nom de votre base de données'
go '
Maintenant j'ai la base de données en ligne.
Toutefois, cela était complexe, nous avons récupéré la quasi-totalité de nos données à partir de la base de données en difficulté. Mais certaines entrées sont toujours portées disparues depuis des tables importantes. La principale raison à cela est en cours d'exécution CHECKDB avec 'repair_allow_data_loss' option. Pour faire une récupération complète de base de données SQL, en fin de compte, nous avons dû recourir à des commerciaux des outils tiers. Ces utilitaires ne valait le prix. Ils nous ont aidés numériser rapidement la base de données et de réparer le fichier corrompu MDF avec facilité. Avec l'aide de ces logiciels, j'ai pu sauver quelques requêtes, procédures, etc dans un fichier texte séparé.
Aucun commentaire:
Enregistrer un commentaire
Thanks for your valuable comment !