Glorf IT

Jahrelang hörte man oft davon, dass bestimmte Dienstleistungen im Ausland eingekauft wurden: Software made in Indien oder Malaysia. Jetzt geht der Trend hin zu den östlichen europäischen Ländern. Nach meinen Erfahrungen gestaltet sich der Informationsaustausch in der Regel aber mehr als schwierig. Das Tchechen oder Polen immer entweder gut englisch oder deutsch sprechen, stimmt nach meiner Erfahrung überhaupt nicht. Am besten klappt unsere Zusammenarbeit noch mit den Italienern, aber die sind weder im Osten noch billiger als wir… 😉

Das im Osten auch nicht alles so gut und billig produziert werden kann, weiss ich seitdem mein Freund Michael auf dem Weg zu seinen tchechischen Kunden ab und an bei uns Station macht. Er leitet eine kleine deutsche Spritzguss-Firma (Familienbetrieb). Was die Kunden schätzen ist das gute Preis-/Leistungsverhältnis: Gute Qualität zu bezahlbaren Preisen.

Leider hört man viel zu wenig von Firmen, die im Ausland schlechte Erfahrungen gesammelt haben. Hier mal eine seltene Ausnahme: heute.de – Eine grobe Fehleinschätzung

Bei debri.ru gibt es irre Bilder von ?russischen? Höhlen. Ich muss unbedingt mal dran denken und mir von Vladimir übersetzen lassen, was die Texte bedeuten:
ПDEBRI.RU

Im ersten Teil der Reihe zum Vorgehen bei Datenbank-Reparaturen wurde erklärt, wie man vorgehen kann, wenn man eine Datenbank an einen SQL Server 2000 anhängen will, das aber nicht klappt, weil die Datenbank kaputt ist.

In diesem Teil geht es darum, wie man vorgehen kann, wenn das Transaktionslog defekt ist oder es von jemandem gelöscht wurde, der es für eine "ganz normale Log-Datei" hielt, die man ruhig löschen kann. Diese Irrlehre hält sich noch in einigen Köpfen… 😉

Wenn das Transaktionslog futsch oder defekt ist, muss man beachten das eine inkrementelle Sicherungsstrategie damit schwere Rückschläge bekommt. Mann muss sofort nach der Reparatur eine Voll-Sicherung durchführen. Wie man bei der Wiederherstellung vorgeht, hängt vom Zustand der Datenbank ab. Wenn die Datenbank ordentlich geschlossen wurde und das Tranlog defekt ist, dann hat man sehr gute Chancen ohne Datenverluste aus der Geschichte rauszukommen. Wichtig ist immer, dass man vor dem Beginn der Analyse Kopien der Datenbank-Dateien anfertigt! Ich rate dazu den SQL Server zu stoppen und auch die Master-Dateien zu sichern.

Beispiel aus der Praxis: Ein Mitarbeiter hat etwas zu viel gelöscht. Jetzt wird der Admin gebeten die Sicherung vom Vortag wieder einzuspielen. Der Admin überschreibt die Dateien von heute mit der Sicherung von gestern (Festplattenvollsicherung bei gestopptem SQL Server, benutzt wird Simple Recovery Mode). Unerklärlicherweise lässt sich die Datenbank danach nicht zugreifen. Analyse: Tranlog-Datei völlig geschrottet. Die Datenbank wurde als suspekt markiert, weil kein Recovery durchgeführt werden konnte.

In diesem Beispiel kann man vergleichsweise einfach zum Ziel kommen. Die Datenbank-Datei wurde ordnungsgemäß geschlossen. Daher enthält das Tranlog keine Infos, die nicht schon in der Datenbank eingepflegt wurden. Man kann den SQL Server "einfach" ein Neues anlegen lassen:

(1) SQL Server stoppen, LDF umbenennen (oder löschen, man hat ja eine Kopie), SQL Server starten.

(2) Datenbank trennen und nur mittels der MDF wieder anhängen:

exec sp_detach_db 'MyCrashDB'

exec sp_attach_single_file_db 'hahaha',
'e:\Programme\Microsoft SQL Server\MSSQL$MYLITTLESQL\data\MyCrashDB.MDF'

Man bekommt beim Anhängen zwar einen Fehler, aber die Datenbank lässt sich prima wieder anhängen.

Device activation error. The physical file name 'e:\Programme\Microsoft SQL Server\MSSQL$MYLITTLESQL\data\MyCrashDB_log.LDF' may be incorrect.
New log file 'e:\Programme\Microsoft SQL Server\MSSQL$MYLITTLESQL\data\MyCrashDB_log.LDF' was created.

Und fertig ist die Lauge. Herzlichen Glückwunsch. Man sollte danach in jedem Fall eine neue Datensicherung machen. Nicht nur, wenn man ein inkrementelles Backup verwendet.

Im nächsten Teil geht es dann darum, was man macht, wenn die Datenbank nicht sauber heruntergefahren wurde.