Manchmal ist es mühsam, alte Server-Systeme zu warten. Vor allem, wenn man feststellt, dass große Transaction Logfiles von (nicht mehr benutzten) SQL-Datenbanken wie vom “companyweb” – von SharePoint 2007 – eingenommen werden und unnötig viel Festplattenplatz verbrauchen. So wars auch auf einem SBS2008. Nur: Wie verkleinert man solche SQL-Datenbanken?
Das Problem
Im schönen Pfad D:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\DATA lagen hier ein paar winzige SQL Datenbankdateien – allerdings mit riesigen Transaction Logs. Die SharePoint_Config – Datenbank hatte nur 5MB und das dazugehörige Logfile sportliche … 31GB. Und ein paar weitere DB´s zu shrinken…
Das Verbinden im SQL Management Studio (Express) auf dem SBS gestaltete sich als mühsam. Es war nicht möglich mit Windows-Authentifizierung, eine Verbindung zur SQL-Instanz <Servername>\MICROSOFT##SSEE herzustellen.
Beim Versuch folgt eine Fehlermeldung “Es kann keine Verbindung mit <Servername>\MICROSOFT##SSEE hergestellt werden.”
Die Instanz MICROSOFT##SSEE läuft übrigens unter dem Netzwerkdienst.
Zum Glück gibt es Suchmaschinen. Damit war es dann doch recht rasch gelöst.
Zum SQL Server verbinden
Anmelden als Domänen-Administrator (und zwar mit jenem Admin, mit dem der – schon damals migrierte – SBS installiert wurde: haha, Stolperstein…) und das SQL Management Studio Express starten. Die Verbindung erfolgt dann auf der lokalen Maschine zu dieser Instanz – und zwar nur mit diesem ConnectionString:
\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
Danke an MSSQLTips.com und den Artikel Administering your Windows Internal Database MICROSOFT##SSEE instance für das HowTo mit der erfolgreichen Verbindung!
Und die Transaction-Logs verkleinern
Sobald die SQL-Verbindung erfolgreich hergestellt wurde, folgt nun der einfache Teil: Das Shrinken der SQL-Datenbanken, besser gesagt, der riesigen Transaction-Logs. Die Pfade “D:\Temp\” und Datenbank-Namen “SharePoint_Config_123” sind natürlich an die eigene Situation anzupassen.
Die logischen Datenbank-Namen sieht man in den Eigenschaften der jeweiligen Datenbank:
Am besten Search und Replace des DB-Namens in folgendem T-SQL Script durchführen.
Das fertige Script sieht dann etwa so aus:
----------------------------------------------------
-- Backup and Shrink Database Log by TP
----------------------------------------------------
BACKUP DATABASE [SharePoint_Config_123]
TO DISK = N'D:\Temp\SharePoint_Config_123.bak'
WITH NOFORMAT, INIT, NAME = N'Full Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
BACKUP LOG [SharePoint_Config_123]
TO DISK = N'D:\Temp\SharePoint_Config_123.trn'
WITH NOFORMAT, INIT, NAME = N'Transaction Log',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
-- 2x Log save before shrink
BACKUP LOG [SharePoint_Config_123]
TO DISK = N'D:\Temp\SharePoint_Config_123.trn'
WITH NOFORMAT, INIT, NAME = N'Transaction Log',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
-- Shrink the log
USE [SharePoint_Config_123]
GO
DBCC SHRINKFILE (N'SharePoint_Config_123_log' , 0)
GO
Hinweis: BACKUP LOG ist natürlich nur möglich, wenn das Recovery Model der Datenbank FULL ist (nicht bei SIMPLE). Wenn es dennoch ein .TRN File gibt, kann das Recovery-Modell kurzfristig auf FULL umgestellt werden, die DB verkleinert werden und das Recovery Modell danach wieder geändert werden. Oder das Recovery Modell gleich auf SIMPLE umschalten und die Logs löschen. Wie so oft gibt es mehrere Lösungswege.
Sollte das Shrinken nicht auf Anhieb funktionieren, einfach Backup Log und DBCC Shrinkfile nochmals ausführen. Der Vorgang von Backup Log kann schon einige Zeit (Stunden) benötigen, je nach Größe der Logs. Aber es können auch mehrere Backups und Shrinks in mehreren Query-Fenstern parallel laufen, so lässt sich etwas Zeit sparen.
Sofern die Backup-Dateien *.bak und *.trn nicht archiviert werden sollen, können diese Dateien wieder gelöscht werden. Als Ergebnis sind die Transaction-Logs wieder 504KB (Standardgröße) klein – wie es sein soll (bis der Server … abgelöst wird).