Sie sind zurzeit offline. Es wird auf die erneute Herstellung einer Internetverbindung gewartet.

Info: Umgehen (Emergency) Modus und DUMP TRANSACTION WITH NO_LOG

Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.

Den englischen Originalartikel können Sie über folgenden Link abrufen: 165918
Dieser Artikel wurde archiviert. Er wird im vorliegenden Zustand bereitgestellt und nicht mehr aktualisiert.
Zusammenfassung
In selten Fällen kann eine Datenbank als FEHLERVERDÄCHTIG aufgrund von Fehler bei der Wiederherstellung zur Startzeit gekennzeichnet werden. Normalerweise, hindert dies jemand am Zugriff auf die Daten. Es ist jedoch möglich, manuell den Status einer FEHLERVERDÄCHTIGEN Datenbank "umgehen Mode" (auch als "Notfallmodus" bezeichnet) und SELECT festgelegt oder Bulk Copy Program (BCP) verwenden, um die Daten zu kopieren. Zwar kann keine regulären Datenänderungen in Modus umgehen, ist es möglich, DUMP TRANSACTION WITH NO_LOG auszuführen. Beachten Sie, dass Durchführen dieses Vorgangs im Modus umgehen wird nicht unterstützt und ist ein potenziell gefährliche Vorgang.

Ähnlichen Gründen Wenn Start Recovery sehr lange dauert sollte nicht abgebrochen, es, stellen die Datenbank im Bypass-Modus und DUMP TRANSACTION WITH NO_LOG führen.
Weitere Informationen
Alle Aktionen von DUMP TRANSACTION werden normalerweise protokolliert, daher ist es wiederherstellbare und abortable. Jedoch wird durch den Befehl DUMP selbst Protokollspeicherplatz verbraucht. Wenn das Transaktionsprotokoll so voll ist, dass dazu eine protokollierte DUMP TRANSACTION nicht genügend Speicherplatz vorhanden ist, kann die Option WITH NO_LOG das Transaktionsprotokoll mit keine Protokollierung abschneiden.

DUMP TRANSACTION WITH NO_LOG ist relativ sicher unter normalen Bedingungen. Der Server nimmt Maßnahmen, um sicherzustellen, dass die Wiederherstellung erfolgreich ist, auch wenn der Server während dieser Operation fehlschlägt.

Unter seltenen Umständen kann die automatische Wiederherstellung (auch als Start-Wiederherstellung bezeichnet) eine Datenbank als FEHLERVERDÄCHTIG markiert fehlschlagen. Wiederherstellung für einen bestimmten Grund schlägt fehl. Es ist sehr wichtig zu beachten die Fehlerprotokoll-Nachricht, die anfänglich Wiederherstellung fehlschlägt,, verursacht da es hilfreich sein kann, um die Ursache zu ermitteln.

"Recovery" ist der Prozess, der Datenbank konsistent durch Wiederholen oder Rückgängigmachen alle Transaktionen entweder nach gestartet oder zum Zeitpunkt der letzten Prüfpunkt uncommitted. Dieser Prozess ist abhängig von der Write-ahead-Natur der das Transaktionsprotokoll (alle geänderte Seiten werden in das Protokoll geschrieben bevor Sie in die Datenbank geschrieben werden). Wiederherstellung besteht aus jeder Protokolleintrag, vergleichen deren Timestamp, der Zeitstempel der entsprechende Datenbankseite, und entweder die Änderung (im Fall von einer nicht ausgeführten Transaktion) rückgängig oder wiederholen die Änderung (im Fall von einer zugesicherten Transaktion) lesen. Versuchen Sie nach vermerken der Fehlerprotokoll-Nachricht, die Wiederherstellung der Fehler verursacht den Datenbankstatus wieder auf NORMAL festlegen, und starten Sie SQL Server finden Sie unter Wenn Wiederherstellung zum zweite Mal erfolgreich neu. Sie können den Datenbankstatus der über die Sp_resetstatus gespeicherten Prozedur ändern. Dies ist zusätzliche gespeicherte Prozedur Installation von das Instsupl.sql-Skript, das im Verzeichnis Mssql\Install enthalten ist. Weitere Informationen finden Sie in der Onlinedokumentation "Zurücksetzen des Fehlerverdächtig Status".

Wenn Wiederherstellung immer noch fehlschlägt, Beachten Sie die Fehlermeldung, und wenden Sie sich an Ihren Hauptanbieter für technischen Support. Da es möglicherweise erforderlich werden, sollten Sie auch die Verfügbarkeit Ihrer letzten Datenbanksicherung gute überprüfen. Ein Großteil der Daten in Ihrer Datenbank häufig noch verfügbar, wenn auch transaktionell (und physisch) inkonsistent ist jedoch. Sie können diese Daten zugreifen, indem Sie den Datenbankstatus zu umgehen oder Notfallmodus festlegen. Dies erfolgt durch Einstellung sysdatabases.status-32768 für eine SQL 6.5-Datenbank und 32768 für eine SQL 7.0-Datenbank, nach dem Einschalten "Updates zulassen". Verwenden Sie beispielsweise den folgenden Befehl für eine SQL 6.5-Datenbank:
   UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME='DBNAME'				

Nach diesem können Geben Sie die Datenbank und die Daten SELECT oder BCP verwenden, um es zu erhalten. Bei der auf diese Weise können Fehler auftreten, aber in den meisten Fällen ein Großteil der Daten abgerufen werden kann.

Warnung: Dieser Artikel wurde automatisch übersetzt.

Eigenschaften

Artikelnummer: 165918 – Letzte Überarbeitung: 12/04/2015 16:39:52 – Revision: 3.1

Microsoft SQL Server 4.21a Standard Edition, Microsoft SQL Server 6.0 Standard Edition, Microsoft SQL Server 6.5 Standard Edition

  • kbnosurvey kbarchive kbmt kbinfo kbusage KB165918 KbMtde
Feedback