Das Wichtigste zuerst, Nicht am Produktiven System üben. Das folgende Beispiel nur im Absoluten Notfall verwenden. Alles ohne Garantie das es funzt und ihr nicht noch mehr zerstört. Bei allen die sich etwas mit dem MS SQL Server auseinander gesetzt haben wissen das es sich beim Transaktion log um das LDF File. Zuerst möchte ich aber etwas näher auf die Funktion des Transaktionslog eingehen für alle welche nicht so versiert mit Datenbanken sind. Wenn ein Programm eine Update in einer Datenbank macht wird dieses zuerst in das Transaktion log geschrieben. Der SQL Server Schreibt dann die Änderung in die Eigentliche Datenbank
(mdf). Für alle welche sich mal etwas im Transaktion log umschauen möchten gibt’s den Befehl “DBCC log ( {dbid|dbname}, [, type={0|1|2|3|4}] )”. Wobei ich eigentlich meistens zum Debuggen die Option 0 oder 1 verwende. Insgeheim Denke ich auch das man die leute welche mit der Option 4 Debuggen in der Matrix Leben und keine rl freunde haben 
.
Aber wieder zurück zum Thema. Also gehen wir mal davon aus das unser DB Server geratscht ist wegen einer Hard Disk wo das LDF File drauf war (Möchte hier nur anmerken das mir das noch nie passiert ist und so ein File auf ein Riad System gehört !!) Des weiter haben wir ein Backup der Datenbank welches 
eine stunden alt ist. Um dies zu simulieren habe ich im Windows Task Manager den “sqlservr.exe” beendet und die ldf Datei gelöscht. Da wir ja kein 0815 Admin sind. Geben wir uns nicht damit zufrieden unser Backup einfach so zurückzustellen und die Armen Kunden (Anwender) die letzen stunden einfach nochmal so einzugeben. Also werfen wir den DB Server mal wieder an. Das unsere Datenbank sich als suspect meldet springt uns als erstes in Auge (sihe PRTSCR 2). Wenn wir versuchen einen Zugriff zu machen wird dies geblockt das kein Transaktion log da ist. Aber wir komme ich weiter ?
Wir besinnen uns auf den SQL Kurs den wir nie hatten und beginnen zu weinen . Wir können auch etwas Rumsuchen in dem SQL Books Online bei Microsoft. Oder wir Erinnern uns an den von Microsoft nicht dokumentierten befehl DBCC. Ok ich gebe zu in diversen KB artikeln wird mit dem ding rumgebastelt. Oder wir können etwas Googeln und gelangen zu einem Scribt was so ähnlich ist wie dieses Hier.
EXEC sp_configure ‘allow updates’, 1
RECONFIGURE WITH OVERRIDE
GO
BEGIN TRAN
UPDATE master..sysdatabases
SET status = status | 32768
WHERE name = ‘RocketSience’
IF @@ROWCOUNT = 1
BEGIN
COMMIT TRAN
RAISERROR(‘emergency mode set’, 0, 1)
END
ELSE
BEGIN
ROLLBACK
RAISERROR(‘unable to set emergency mode’, 16, 1)
END
GO
EXEC sp_configure ‘allow updates’, 0
RECONFIGURE WITH OVERRIDE
GO
– Hier den SQL Server neu starten (Service Reicht).
DBCC REBUILD_LOG(‘RocketSience’,'D:\SQLDB\MSSQL$STARFLEETDB\Data\RocketSience_log.LDF’)
/*Hier Testen ob alles wieder geht !!!!!!
Keine garantie das meine DB Konsistent ist */
ALTER DATABASE RocketSience SET MULTI_USER
GO
Und schon lebt unsere Datenbank Wieder. Zum beweis das wir auch ein neues TRN Log haben noch dieser PRTSCR 
Das Scribt habe ich euch natürlich auch als TXT Datei bereit gelegt.
