Im vorherigen Teil der Serie zum Vorgehen bei Datenbank-Reparaturen am SQL Server 2000 wurde erklärt, wie man vorgeht, wenn das Tranlog defekt ist und die Datenbank ordentlich geschlossen wurde, d.h. das Transaktionslog im Prinzip leer ist. Trotz Urlaub will ich daran anknüpfen:
Was macht man aber, wenn die Datenbank nicht geschlossen wurde, sondern der Server abstürzte, weil die Festplatte langsam schrottet und just da auch noch das Tranlog rüber rudert? Das ist ein häufiges Szenario, weil das Tranlog sehr oft zugegriffen wird. Und deswegen besonders oft von Festplattenproblemen betroffen ist.
In diesem Fall muss wird die "Reparatur" etwas fummelig. Wenn man Glück hat, dann ist die Datenbank noch am SQL Server angehängt, aber als suspekt markiert. Wenn man den vorherigen Tipp ausprobiert hat ohne vorher die Master-Datenbank zu sichern oder einem die DB-Dateien zur Untersuchung zugeschickt wurden, dann muss man der SQL-Server erst mal austricksen, um die defekte Datenbank an den Server angehängt zu bekommen. Wenn man dann soweit ist, dass die Datenbank angehängt, aber suspekt ist, dann ist es nicht mehr so schwierig. Mit beiliegendem Statement bekommt man übrigens eine Liste aller Datenbanken mit deren Status:
select name, databasepropertyex(name, 'status')
from master.dbo.sysdatabases
Im Folgenden wird erklärt, wie man das Tranlog löscht und vom SQL Srever ein Neues anlegen lässt. Da im Tranlog aber eventuell wichtige Daten standen, erzeugt man dadurch möglicherweise einen inkonsistenten Datenbestand.
(1) Datenbank in den "Emergency-Mode" schalten. Beim nächsten Start wird für die Datenbank kein Recovery versucht:
-- Änderungen in den Systemtabellen erlauben
exec sp_configure 'allow update', 1
reconfigure with override
go
– Datenbank in den Emergency mode setzen
update master..sysdatabases
set status = status | 32768
where name = 'MyCrashDB'
go
– Änderungen in den Systemtabellen verbieten
exec sp_configure 'allow update', 0
reconfigure with override
(2) SQL-Server-Dienst stoppen und neu starten. Erst danach ist die Datenbank im Emergency-Mode.
(3) Jetzt kann ein neues Transaktionslog angelegt werden. Vorher muss man die alte Tranlog-Datei noch schnell umbenennen (oder löschen, denn man hat ja vorher eine Kopie gemacht, oder?)
-- Log neu erzeugen lassen:
DBCC rebuild_log ('MyCrashDB')
Das Ergebnis sieht etwa so aus:
Warning: The log for database 'MyCrashDB' has been rebuilt. Transactional consistency has been lost. DBCC CHECKDB should be run to validate physical consistency. Database options will have to be reset, and extra log files may need to be deleted.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
(4) Jetzt muss man die DB nur wieder auf "normal" schalten:
alter database MyCrashDB
set online
Und schon hat man es geschafft.
Die gute Nachricht ist, dass man beim SQL Server 2005 nicht mehr in den Systemtabellen rumpfuschen muss. Die schlechte ist, dass immer noch viel Handarbeit notwendig ist. Naja, aber so arme Hunde wie ich müssen ja auch leben… 😉
Im dritten Teil geht es dann um Reparaturen rund um DBCC CHECKDB.
