Base de données «suspecte» SQL Server?


40

Que faites-vous quand vous avez une base de données marquée Suspect?

Restaurer à partir de la dernière sauvegarde?

S'il vous plaît donnez votre avis.

Réponses:


41

La première chose à faire est de ne PAS détacher cette base de données.

Restaurer depuis le dernier goodbackup connu est correct. Sinon, vous devrez utiliser le mode de réparation d'URGENCE (je suppose que vous utilisez SQL 2005 ou une version supérieure). Voici quelques articles de Paul Randal sur le sujet. Lisez-les tous les deux avant de commencer à prendre des mesures.

Créer, détacher, reconnecter et réparer une base de données SUSPECT

Réparation en mode URGENCE: le dernier recours


5

Assez bien oui.

En règle générale, cela signifie que les fichiers sont bollixés ou manquants ou qu’une erreur de disque ou une erreur similaire (j’ai vu un secteur défectueux en causer).

Mes pas:

  • S'assurer que toutes les sauvegardes sont là
  • Arrêtez SQL Server
  • chkdsk les disques utilisés par SQL Server (heureusement pas votre C: bien sûr)

Edit: je vais clarifier ma réponse

  • si les données sont importantes, je vais avoir une sauvegarde
  • les temps d'arrêt pendant que je déconne avec des réparations et le mode d'urgence est trop long pour moi

5

J'ai écrit quelques indications à ce sujet pour 2 cas de base de données suspecte: lorsque vous avez perdu le fichier de données ou le fichier journal. Veuillez lire ce qui suit:


5
Voici donc le problème: Stack Exchange ne fonctionne pas si vous ne publiez que des liens. Ce que nous avons besoin de vous, c'est de résumer le contenu dans les liens, sinon je serai obligé de supprimer votre réponse (et vous perdrez alors la réputation, et aucun de nous ne voudra que cela se produise)
jcolebrand

4

D'après votre question, il semble que vous ayez une copie de sauvegarde. La restauration de la base de données à partir d’une bonne sauvegarde sera le moyen le plus simple et le plus rapide de rendre votre base de données opérationnelle et hors de l’état suspect.


5
Mais vous perdrez des données si vous ne disposez pas des journaux de transaction.
mrdenny

0

Mon premier conseil est; ne jamais détacher la base de données suspecte. La restauration de la base de données à partir d'une sauvegarde mise à jour est utile. Si la sauvegarde n'est pas disponible ou si un problème survient, le EMERGENCYmode peut être utile:

Mettre la base de données en mode d'urgence:

ALTER DATABASE DB_NAME SET EMERGENCY

Maintenant, vérifiez les incohérences de la base de données avec ceci:

DBCC CHECKDB (‘DB_NAME’)

L’option d’autorisation de perte de données de réparation DBCC CHECKDB est utilisée en dernier recours. Le résultat peut être une perte de données, je ne suggère donc pas de l'exécuter.

Vérifiez également les références 1 et 2

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.