Letztens wollte ich einen Test-Restore meiner Sharepoint Datenbank durchführen. Normalerweise hat das immer problemlos funktioniert, jedoch beim letzten Backup gab es große Probleme mit dem Sharepoint-Inhalt. Der Restore-Vorgang wurde erfolgreich beendet, jedoch war lediglich die halbe Sharepoint Struktur und keine Daten enthalten.

Nachdem ich das Eventlog des Quellservers durchforstet habe, bin ich auf folgende Fehler im Anwendungs-Log gestoßen:

image

Protokollname: Application
Quelle:        MSSQL$SHAREPOINT
Datum:         24.08.2010 15:46:37
Ereignis-ID:   18053
Aufgabenkategorie:Server
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      ******\daniel nitz
Computer:      Miami.*****.local
Beschreibung:
Fehler: 7884, Schweregrad: 20, Status: 1. (Parameter: ). Der Fehler wird aufgrund eines Formatierungsfehlers im nicht ausführlichen Modus gedruckt. Ablaufverfolgung, ETW, Benachrichtigungen usw. werden ausgelassen.

image

Protokollname: Application
Quelle:        MSSQL$SHAREPOINT
Datum:         24.08.2010 15:46:37
Ereignis-ID:   7105
Aufgabenkategorie:Server
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      ******\daniel nitz
Computer:      Miami.*****.local
Beschreibung:
Die Datenbank-ID '6', Seite '(0:0)', Slot '0' für den LOB-Datentypknoten ist nicht vorhanden. Dies ist gewöhnlich auf Transaktionen zurückzuführen, die Daten, für die kein Commit ausgeführt wurde, auf einer Datenseite lesen können. Führen Sie DBCC CHECKTABLE aus.

Um den Fehler zu analysieren muss man zunächst das SQL Server 2008 Management Studio Express installieren. Über das Management Studio erhält man Zugriff auf dem SQL Server und kann mit dem Troubleshooting beginnen.
Zunächst meldet man sich am SQL Server an. Als Servername verwenden wir SERVER\Sharepoint

image

Nun ist die Verbindung zum Server hergestellt. Jetzt muss die Datenbank mit der ID ‘6’ (wie in der Fehlermeldung 2) gefunden werden. Als erstes öffnen wir ein Abfragefenster und gehen jede Datenbank mit

use NAME-DER-DATENBANK
select db_id()

image

durch, bis uns die entsprechende ID im Fenster “Meldungen” ausgegeben wird. In meinen Fall war das die Datenbank WSS_CONTENT.

Nun führen wir den Befehl DBCC CHECKDB (WSS_CONTENT) WITH NO_INFOMSGS, ALL_ERRORMSGS aus und bekommen eine Liste mit den entsprechenden Fehlern

image

In meinem Fall:

Meldung 8965, Ebene 16, Status 1, Zeile 1
Tabellenfehler: Objekt-ID 69575286, Index-ID 1, Partitions-ID 72057594113359872, Zuordnungseinheits-ID 72057594043760640 (LOB data-Typ). Auf den Datenknoten außerhalb von Zeilen auf Seite (0:0), Slot 0, Text-ID 1759772672 wird von Seite (1:4986), Slot 6 verwiesen, er wurde jedoch im Scan nicht betrachtet.
Meldung 8929, Ebene 16, Status 1, Zeile 1
Objekt-ID 69575286, Index-ID 1, Partitions-ID 72057594113359872, Zuordnungseinheits-ID 72057594123255808 (In-row data-Typ): Es wurden Fehler in Daten außerhalb von Zeilen gefunden mit der ID 1759772672, im Besitz von data, Datensatz identifiziert durch RID = (1:4986:6).
Von CHECKDB wurden 0 Zuordnungsfehler und 2 Konsistenzfehler in der 'AllDocs'-Tabelle (Objekt-ID 69575286) gefunden.
Von CHECKDB wurden 0 Zuordnungsfehler und 2 Konsistenzfehler in der 'WSS_Content'-Datenbank gefunden.
repair_allow_data_loss ist die minimale Reparaturstufe für die Fehler, die mit DBCC CHECKDB (WSS_Content) gefunden wurden.

 

Die Meldungen weisen darauf hin, dass eine Inkonsistenz in der Datenbank vorliegt. Höchstwahrscheinlich handelt es sich dabei um eine Datei, die auf dem Sharepoint Server upgeloaded wurde. Um die Inkonsistenz zu beheben muss DBCC CHECKDB mit dem Parameter repair_allow_data_loss ausgeführt werden.

Dafür müssen zunächst alle Sharepoint Dienste und der IIS Dienst beendet werden.
Danach müssen die folgenden Kommandos ausgeführt werden:

image

Mit dem Befehl ALTER DATABASE WSS_Content SET SINGLE_USER, wird die Datenbank in den Sinlge_Mode gesetzt, der Befehl DBCC CHECKDB (WSS_Content, REPAIR_ALLOW_DATA_LOSS) startet die Reparatur.

Nachdem die Reparatur abgeschlossen wurde und DBCC CHECKDB keine Fehler mehr protokolliert, kann der Modus wieder zu MULTI_USER geändert werden.

image

Jetzt können alle Dienste wieder gestartet werden. Die Datenbank sollte jetzt konsistent sein und die Sicherung vollständig durchlaufen.

Grüße
dn

This post has been migrated from our earlier blog based on BlogEngine.NET.