Kategorie: SQL

Kategorien
IT SharePoint SQL

Eine „suspect“ Datenbank reparieren

Es ist mir schon passiert, dass ich auf einmal keine SharePoint-Webseite meiner Virtual Machine mehr öffnen konnte. Auch die Central Administration funktionierte nicht mehr. Als Fehlermeldung erschien:

„This operation can be performed only on a computer that is joined to a server farm by users who have permissions in SQL Server to read from the configuration database. To connect this server to the server farm, use the SharePoint Products Configuration Wizard, located on the Start menu…“

Ein Ausführen des SharePoint Products Configuration Wizards war nicht möglich, der Wizard brach nach einigen Schritten ab, mit der Begründung, dass nicht auf die Configuration-Datenbank zugegriffen werden konnte.

Ein Blick in das MSSQL Management Studio zeigte dann, dass die SharePoint-Config-Datenbank im Status suspect, also verdächtig war.

Zum Glück gibt es einen Weg, die Datenbank wieder in einen gesunden Zustand zu bringen, oder zumindest es zu versuchen. Achtung: je nach Schweregrad der zu Grunde liegenden Störung kann es sein, dass bei diesem Vorgang Daten verloren gehen, da hier eine Reparatur der Datenbank mit „REPAIR_ALLOW_DATA_LOSS“ durchgeführt wird.

Via MSSQL Management Studio auf den Datenbankserver verbinden und ein neues Query-Fenster öffnen, danach folgende Zeilen ausführen („DatabaseName“ durch den Namen der „suspect“ Datenbank ersetzen):

EXEC sp_resetstatus [DatabaseName];
ALTER DATABASE [DatabaseName] SET EMERGENCY
DBCC checkdb([DatabaseName])
ALTER DATABASE [DatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([DatabaseName], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [DatabaseName] SET MULTI_USER

Je nach Grösse der Datenbank, Server-Leistung und Fehler-Anzahl kann der Vorgang zwischen wenigen Sekunden bis hin zu Stunden dauern. Bei mir brauchte es für eine 1 GB grosse Datenbank zum Beispiel ca. eine Minute. Im Ausgabefenster ist ersichtlich, was für Reparaturen vorgenommen wurden und ob diese zu Datenverlust führten.

Nachdem die Operation beendet wurde, kann man versuchen wieder auf die Datenbank zuzugreifen. In meinem Fall konnte ich wieder auf die SharePoint-Central-Administration und die Web-Applications zugreifen.

Kategorien
IT SQL

Microsoft SQL Server Management Studio – verbleibende Datenbank-Restore-Dauer anzeigen

Vielleicht habt ihr auch schon mal in einem Microsoft SQL Server einen Restore einer Datenbank durchgeführt und wolltet wissen, wie weit der Restore nach einigen Minuten/Stunden schon gekommen ist und wann der Restore ungefähr beendet sein wird.

Wird der Restore via „Management Studio“-GUI durchgeührt (Datenbank-Kontextmenü -> Tasks -> Restore), dann habt ihr im Restore-Dialog zumindest eine ungefähre Prozent-Anzeige. In der 2012er-Version wird diese oben rechts angezeigt:

Die Prozent-Anzeige erscheint aber erst nach einem Weilchen und wenn man den Restore via SQL-Skript gestartet hat und dabei „STATS“ nicht (oder mit einem ungünstigen Wert) verwendet hat, weiss man auch nicht bei wieviel Prozent der Restore aktuell steht und wie lange er noch dauert. Häufig bleibt die Prozentzahl auch lange unverändert und man ist sich nicht sicher, ob der Restore noch läuft oder sich aufgehängt hat.

Zum Glück gibt es jedoch eine Möglichkeit mit einem SQL-Befehl den aktuellen Fortschritt und die geschätzte Endzeit zu erhalten – egal ob  der Backup-Job via GUI, Skript oder sogar von einer anderen Maschine gestartet wurde. Voraussetzung ist ein MSSQL Server der Dynamic Management Views (DMVs) unterstützt, also ab MSSQL 2005. Ist das gegeben kann man folgenden Befehl als Query absetzen (es muss keine Datenbank dazu vorselektiert werden):

SELECT session_id as SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')

Das Resultat sieht dann zum Beispiel wie folgt aus (unterer Bereich, Spalten percent_complete und estimated_completion_time):

Im Beispiel sieht man also, dass bereits 96.16975 % des Restores durchlaufen ist und der Restore um 12:38 Uhr, des 7. Dezember 2016, fertig sein sollte – nach ungefähr 19 Stunden Laufzeit. Praktisch oder?

Gefunden auf: https://www.mssqltips.com/sqlservertip/2343/how-to-monitor-backup-and-restore-progress-in-sql-server/