SQL Server Filegroup Full?

Heute ein Beitrag aus dem Alltag eines SQL Server DBA’s 😉

Gemeldet wurde vom Kunden, dass die betroffene Anwendung eine Fehlermeldung gezeigt hat, die „Dateigruppe ‚PRIMARY‘ ist voll“ lautet. Daraufhin war die erste Ferndiagnose vom DBA erst einmal einfach und ich wollte die Max Size der Datenbankdateien überprüfen.

Das war nun gar nicht so einfach, da die Datenbank vom Kunden gerade offline geschalten wurde. Also gab es den Prozess der Offline Schaltung, die anscheinen durch weitere Transactions auf die Datenbank aufgehalten wurde. Dadurch war die Bedienung durch das SQL Server Management Studio unmöglich und man konnte auch keine weiteren sinnvollen Diagnosen auf der Datenbank durchführen.

Hintergrund zur SQL Server Umgebung:

• 2x virtuelle Windows Server 2016 Maschine
• Windows Server Failover Cluster
• SQL Server 2016 Failover Cluster Umgebung

Damit die Wartezeit etwas verkürzt wird, da es sich ja um ein produktives System handelte, habe ich mich zum Schwenk der SQL Server Instanz entschieden. Das bewirkt einen Neustart der SQL Services und so die Hoffnung, ein wieder normales Interagieren mit den Datenbankdienst.

Der Dienstneustart führte natürlich zum Recovery Prozess den SQL Server Dienstes auf allen Datenbanken, die einen unsauberen Beendigungsstatus hatten. Da die Datenbanken eine gewisse Größe hatten, dauerte der Vorgang zunächst ca. 25 Minuten.

Im Verlauf des Recovery Prozesses sind mir immer wieder Meldungen Windows Event Viewer (System) aufgefallen:

The device, \Device\Harddisk10\DR10, ist not ready for access yet.

Das führte zur Vermutung, dass eventuell etwas mit dem Festplatten Subsystem nicht in Ordnung ist und der SQL Server selbst keine Schuld an dem Problem trägt.

Nachdem die Instanz nach 25 Minuten einfach wieder auf den ersten Knoten zurück geschwenkt ist, und die Datenbank Recovery wieder von vorn begonnen wurde, konnte dieser Verdacht bestätigt werden.

Der Dienst ist nun korrekt gestartet, eine Teilmenge der Datenbanken war aber weiterhin im Recovery Modus. Das hat weitere 40 Minute in Anspruch genommen. Im SQL Server Error Log waren während dessen immer wieder folgende Fehlermeldungen zu sehen:

SQL Server has encountered 4 occurence(s) of I/O requests taking longer than 15 seconds to complete on file [...] in database id ...

Das legt die Vermutung nahe, dass das Festplatten Subsystem, oder die betreffenden Netzwerkkomponenten ein Problem haben, da hier mit einem geteilten Speichersystem (SAN) gearbeitet wird.

Durch die teilweise sehr langsam reagierende Storage Schicht, waren einige Datenbanken leider im „Recovery pending“ Status.

Um dies wieder zu bereinigen, wurden folgende T-SQL Befehle ausgeführt:

USE master
GO

ALTER DATABASE <<dbname>> SET EMERGENCY
GO

ALTER DATABASE <<dbname>> SET SINGLE_USER
GO

DBCC CHECKDB(N'<<dbname>>',REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS,ALL_ERRORMSGS
GO

Ist die Reparatur erfolgreich, kann die Datenbank wieder in den Multi User Modus geschalten werden.

ALTER DATABASE <<dbname>> SET MULTI_USER
GO

Leider konnte der Fehler noch nicht abschließend geklärt werden, falls ich etwas neues weiß, würde ich das hier weiter aktualisieren.