{"id":71,"date":"2006-07-31T20:46:06","date_gmt":"2006-07-31T18:46:06","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/2006\/07\/31\/sql-talk\/db-defekte\/vorgehen-bei-datenbank-reparaturen-teil-2a"},"modified":"2006-07-31T20:46:06","modified_gmt":"2006-07-31T18:46:06","slug":"vorgehen-bei-datenbank-reparaturen-teil-2a","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2006\/07\/31\/sql-talk\/db-defekte\/vorgehen-bei-datenbank-reparaturen-teil-2a","title":{"rendered":"Vorgehen bei Datenbank-Reparaturen (Teil 2a)"},"content":{"rendered":"

Im ersten Teil<\/a> 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.<\/p>\n

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… \ud83d\ude09<\/p>\n

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<\/strong> anfertigt! Ich rate dazu den SQL Server zu stoppen und auch die Master-Dateien zu sichern.<\/p>\n

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.<\/p>\n

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: <\/p>\n

(1) SQL Server stoppen, LDF umbenennen (oder löschen, man hat ja eine Kopie), SQL Server starten.<\/p>\n

(2) Datenbank trennen und nur mittels der MDF wieder anhängen:<\/p>\n

exec sp_detach_db 'MyCrashDB'<\/p>\n

exec sp_attach_single_file_db 'hahaha',
\n\t'e:\\Programme\\Microsoft SQL Server\\MSSQL$MYLITTLESQL\\data\\MyCrashDB.MDF'<\/code><\/p>\n

Man bekommt beim Anhängen zwar einen Fehler, aber die Datenbank lässt sich prima wieder anhängen.<\/p>\n

Device activation error. The physical file name 'e:\\Programme\\Microsoft SQL Server\\MSSQL$MYLITTLESQL\\data\\MyCrashDB_log.LDF' may be incorrect.
\nNew log file 'e:\\Programme\\Microsoft SQL Server\\MSSQL$MYLITTLESQL\\data\\MyCrashDB_log.LDF' was created.<\/code><\/p>\n

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.<\/p>\n

Im nächsten Teil geht es dann darum, was man macht, wenn die Datenbank nicht sauber heruntergefahren wurde.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[7],"tags":[],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/71"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=71"}],"version-history":[{"count":0,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/71\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=71"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=71"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=71"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}