Périphérique manquant entraîne la base de données est marquée comme suspecte

Numéro d'article: 180500 - Voir les produits auxquels s'applique cet article
Traduction automatiqueATTENTION : Cet article est issu du système de traduction automatique
Agrandir tout | Réduire tout

Symptômes

SQL Server marque une base de données suspecte si un des fichiers de périphérique pour la base de données ne sont pas disponibles lorsqu'il tente de démarrer. Un des ensembles suivants de messages dans le journal des erreurs de SQL Server peut s'afficher :
Message d'erreur 1
11/96/18 10:48:32.60 noyau udopen : 32 d'erreur de système d'exploitation (le
processus ne peut pas accéder au fichier car il est utilisé par un autre
processus.) lors de la création ou de l'ouverture de l'unité physique,
C:\DATA\SQL\MSDB.DAT (ou C:\DATA\SQL\MSDB.MDF)

11/96/18 10:48:32.60 noyau udactivate (principal): Impossible d'ouvrir
périphérique C:\MSSQL\DATA\MSDB.DAT (ou C:\DATA\SQL\MSDB.MDF) pour vdn 127
Message d'erreur 2
11/96/18 10:48:32.60 noyau udopen: 2 (l'erreur du système d'exploitation
système ne peut pas trouver le fichier spécifié.) lors de la création ou de l'ouverture
de physique C:\MSSQL\DATA\MSDB.DAT de périphérique (ou C:\DATA\SQL\MSDB.MDF)

11/96/18 10:48:32.60 noyau udactivate (principal): Impossible d'ouvrir le périphérique C:\MSSQL\DATA\MSDB.DAT (ou C:\DATA\SQL\MSDB.MDF) pour vdn 127
Il seront suivies plus loin dans le journal par :
11/96/18 10:48:36.70 noyau udread : erreur du système d'exploitation 6 (le
handle n'est pas valide.) DISPOSITIF 'C:\MSSQL\DATA\MSDB.DAT' (ou C:\DATA\SQL\MSDB.MDF) (virtpage
0x7f000018).

11/96/18 10:48:36.77 spid11 erreur : 840, gravité : 17, état: 2

11/96/18 10:48:36.77 spid11 Device 'MSDBData' (dont le nom physique
'C:\MSSQL\DATA\MSDB.DAT' (ou C:\DATA\SQL\MSDB.MDF) et le numéro de périphérique virtuel 127) n'est pas
disponible. Contactez l'administrateur système pour obtenir de l'aide.

11/96/18 10:48:36.77 spid11 tampon 1092480 de base de données 'msdb'
possède le numéro de page 0 dans l'en-tête de page et numéro de page 24 dans la
en-tête de la mémoire tampon

11/96/18 10:48:37.43 spid11 Impossible pour poursuivre la récupération de
dbid <5>raison d'erreurs antérieures. Poursuivre la suivante
base de données.
Par exemple, l'effectuant les étapes suivantes présentent ce problème :
  1. Arrêtez SQL Server.
  2. La commande suivante à partir d'une invite de commandes sur le Mssql\Data répertoire :

    ren msdb.dat msdb.sav
  3. Démarrez SQL Server.
Vous verrez les erreurs ci-dessus (ceux à partir du second jeu) dans le journal des erreurs de SQL Server. Si vous exécutez ensuite la requête suivante dans la base de données master 
   select name, dbid, mode, status from sysdatabases where dbid =
   db_id('msdb')

Vous recevez les résultats suivants : 
   name     dbid   mode   status
   ------------------------------
   msdb      5      0      328

L'état de 328 a la valeur : 
   truncate log on chkpt
   database not recovered yet
   database is suspect

Pour plus d'informations, consultez la rubrique «Sysdatabases (base de données master uniquement)» dans la documentation en ligne.
Retour au début | Envoyer des commentaires

Cause

Au démarrage, SQL Server tente d'obtenir un verrou exclusif sur le fichier du périphérique. Si le périphérique est utilisé par un autre processus (par exemple, logiciel de sauvegarde) ou si le fichier est manquant, a rencontré le scénario décrit ci-dessus. Dans ces cas, il est généralement tout à fait correct avec les périphériques et la base de données. Pour la base de données récupérer correctement, le périphérique doit être mis à disposition et l'état de la base de données doit être réinitialisé.
Retour au début | Envoyer des commentaires

Contournement

Pour contourner ce problème, effectuez les opérations ci-dessous. Notez que l'étape finale est critique.
  1. Assurez-vous que le fichier du périphérique est effectivement disponible.
  2. Utilisez sp_resetstatus de procédure stockée supplémentaire pour réinitialiser l'état d'une base de données suspecte. Si vous ne l'avez pas déjà fait, créez cette procédure en exécutant le script Instsupl.sql, figure dans le répertoire Mssql\Install. Pour plus d'informations sur sp_resetstatus, consultez la rubrique «Réinitialisation de l'état suspect» dans la documentation en ligne.
  3. Exécuter sp_resetstatus dans la base de données master pour la base de données suspecte : 
          use master
      go
      exec sp_resetstatus msdb   -- replace msdb with your database name
    vous verrez la sortie suivante : 
          Prior to Update sysdatabases attempt for DBName='msdb', the mode=0
      and status=328 (status suspect_bit=256). For DBName='msdb' in
      sysdatabases, status bit 256 was forced Off and mode was forced to
      0. WARNING: You MUST stop/restart SQL Server prior to accessing this
      database!
  4. Arrêtez et redémarrez SQL Server.
  5. Vérifiez que la base de données a été récupéré et est disponible.
  6. Exécutez DBCC NEWALLOC, DBCC TEXTALL et DBCC CHECKDB.
Retour au début | Envoyer des commentaires

Plus d'informations

Si la base de données est toujours marquée comme suspecte après avoir effectué ces étapes, il peut y avoir des autres problèmes empêchant la récupération de la base de données. À ce stade, vous pouvez restaurer à partir d'une bonne sauvegarde ou définir la base de données en mode d'urgence et utiliser le programme de copie en bloc (BCP) pour copier en bloc les données. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la base de connaissances Microsoft :
165918
(http://support.microsoft.com/kb/165918/ )
Mode de contournement (secours) et DUMP TRANSACTION WITH NO_LOG
Important Si vous utilisez cet article (Q165918) et que vous n'êtes pas sûr des conséquences complets d'une des actions que vous effectuez, contactez votre assistance technique pour obtenir de l'aide.

Retour au début | Envoyer des commentaires

Propriétés

Numéro d'article: 180500 - Dernière mise à jour: mardi 30 mai 2006 - Version: 5.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 6.0 Standard
  • Microsoft SQL Server 6.5 Édition Standard
Mots-clés : 
kbmt kbprb KB180500 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 180500
(http://support.microsoft.com/kb/180500/en-us/ )
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Exclusion de responsabilité concernant les contenus obsolètes dans la Base de connaissances
Cet article concerne des produits pour lesquels Microsoft n'offre plus de support. Il est par conséquent fourni « en l'état » et ne sera plus mis à jour.
Retour au début | Envoyer des commentaires

Envoyer des commentaires

 
Retour au débutRetour au début