Datenbank wird bei fehlendem Medium als fehlerverdächtig markiert

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 180500 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D180500
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
180500 Missing device causes database to be marked suspect
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Problembeschreibung

SQL Server markiert eine Datenbank als fehlerverdächtig, wenn beim Startversuch Mediendateien für die Datenbank fehlen. Im Fehlerprotokoll von SQL Server wird einer der folgenden Fehlermeldungssätze angezeigt:
Fehlermeldung 1
96/11/18 10:48:32.60 Kernel UDOPEN: Betriebssystemfehler 32 (Der
Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen
Prozess verwendet wird.) beim Erstellen/Öffnen des physischen Mediums
C:\DATA\SQL\MSDB.DAT (oder C:\DATA\SQL\MSDB.MDF)

96/11/18 10:48:32.60 Kernel UDACTIVATE (primär): Fehler beim Öffnen
des Mediums C:\MSSQL\DATA\MSDB.DAT (oder C:\DATA\SQL\MSDB.MDF) für VDN 127
Fehlermeldung 2
96/11/18 10:48:32.60 Kernel UDOPEN: Betriebssystemfehler 2 (Die
angegebene Datei wurde nicht gefunden.) beim Erstellen/Öffnen
des physischen Mediums C:\MSSQL\DATA\MSDB.DAT (oder C:\DATA\SQL\MSDB.MDF)

96/11/18 10:48:32.60 Kernel UDACTIVATE (primär): Fehler beim Öffnen des Mediums C:\MSSQL\DATA\MSDB.DAT (oder C:\DATA\SQL\MSDB.MDF) für VDN 127
Im Anschluss hieran erscheinen die folgenden Meldungen im Protokoll:
96/11/18 10:48:36.70 Kernel UDREAD: Betriebssystemfehler 6 (Das
Handle ist ungültig.) auf Medium 'C:\MSSQL\DATA\MSDB.DAT' (oder C:\DATA\SQL\MSDB.MDF) (VIRTPAGE
0x7f000018).

96/11/18 10:48:36.77 SPID11 Fehler: 840, Schweregrad: 17, Status: 2

96/11/18 10:48:36.77 SPID11 Medium 'MSDBData' (mit dem physischen Namen
'C:\MSSQL\DATA\MSDB.DAT' (oder C:\DATA\SQL\MSDB.MDF) und der virtuellen Mediennummer 127) ist nicht
verfügbar. Setzen Sie sich mit dem Systemadministrator in Verbindung, um weitere Informationen zu erhalten.

96/11/18 10:48:36.77 SPID11 Puffer 1092480 von Datenbank 'msdb'
hat Seitennummer 0 im Seitenheader und Seitennummer 24 im
Pufferheader

96/11/18 10:48:37.43 SPID11 Wiederherstellung von
DBID <5> kann wegen vorheriger Fehler nicht fortgesetzt werden. Vorgang wird mit der nächsten
Datenbank fortgesetzt.
Das Problem lässt sich beispielsweise durch Ausführen der folgenden Schritte demonstrieren:
  1. Beenden Sie SQL Server.
  2. Geben Sie im Verzeichnis Mssql\Data den folgenden Befehl von einer Befehlszeile aus ein:

    ren msdb.dat msdb.sav
  3. Starten Sie SQL Server.
Die oben aufgeführten Fehler (vom zweiten Fehlermeldungssatz) erscheinen im Fehlerprotokoll von SQL Server. Wenn Sie anschließend folgende Abfrage in der zentralen Datenbank ausführen
   select name, dbid, mode, status from sysdatabases where dbid =
   db_id('msdb')
				

werden folgende Ergebnisse angezeigt:
   Name     DBID   Modus  Status
   ------------------------------
   msdb      5      0      328
				

Der Status 328 ergibt folgende Werte:
   truncate log on chkpt
   database not recovered yet
   database is suspect
				

Weitere Informationen finden Sie unter dem Thema "Sysdatabases (Master Database Only)" in der Onlinedokumentation zu SQL Server.

Ursache

Beim Starten versucht SQL Server, eine exklusive Sperre für die Mediendatei einzurichten. Wenn das Medium von einem anderen Prozess verwendet wird (zum Beispiel von Sicherungssoftware) oder die Datei nicht vorhanden ist, tritt das oben beschriebene Szenario auf. In diesen Fällen liegen gewöhnlich keine Fehler bei den Medien und der Datenbank vor. Damit die Datenbank korrekt wiederhergestellt werden kann, müssen das Medium verfügbar gemacht und der Datenbankstatus zurückgesetzt werden.

Abhilfe

Gehen Sie folgendermaßen vor, um dieses Problem zu umgehen. Hierbei ist der letzte Schritt besonders wichtig.
  1. Stellen Sie sicher, dass die Mediendatei tatsächlich verfügbar ist.
  2. Verwenden Sie die zusätzliche gespeicherte Prozedur "sp_resetstatus", um den Status einer fehlerverdächtigen Datenbank zurückzusetzen. Erstellen Sie diese Prozedur, falls nicht bereits geschehen, indem Sie das Skript "Instsupl.sql" ausführen, das im Verzeichnis Mssql\Install enthalten ist. Weitere Informationen zu "sp_resetstatus" finden Sie unter dem Thema "Resetting the Suspect Status" in der Onlinedokumentation zu SQL Server.
  3. Führen Sie "sp_resetstatus" in der zentralen Datenbank für die fehlerverdächtige Datenbank aus:
          use master
          go
          exec sp_resetstatus msdb   -- replace msdb with your database name
     
    						
    Folgendes wird ausgegeben:
          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. Beenden Sie SQL Server, und starten Sie ihn neu.
  5. Stellen Sie sicher, dass die Datenbank wiederhergestellt wurde und verfügbar ist.
  6. Führen Sie DBCC NEWALLOC, DBCC TEXTALL und DBCC CHECKDB aus.

Weitere Informationen

Wenn die Datenbank nach dem Durchführen dieser Schritte immer noch als fehlerverdächtig markiert ist, liegen möglicherweise andere Probleme vor, die eine Wiederherstellung der Datenbank verhindern. An diesem Punkt können Sie entweder eine Wiederherstellung von einer fehlerfreien Sicherungskopie durchführen oder die Datenbank in den Notfallmodus setzen und das Massenkopierprogramm (BCP) verwenden, um die Daten herauszukopieren. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
165918 INF: WITH NO_LOG Umgehung (Notfall) Modus und DUMP TRANSACTION
Wichtig: Wenden Sie sich an Ihren primären Supportanbieter, wenn Sie die Schritte in diesem Artikel (Q165918) verwenden und sich über die Folgen der durchgeführten Aktionen nicht sicher sind.

Eigenschaften

Artikel-ID: 180500 - Geändert am: Donnerstag, 26. Oktober 2006 - Version: 5.3
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Keywords: 
kbprb KB180500
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Disclaimer zu nicht mehr gepflegten KB-Inhalten
Dieser Artikel wurde für Produkte verfasst, für die Microsoft keinen Support mehr anbietet. Der Artikel wird deshalb in der vorliegenden Form bereitgestellt und nicht mehr weiter aktualisiert.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com