Probleme mit Transaktionsloggröße

weiss nicht genau ob ich hier mit dieser Frage richtig bin aber vielleicht kann mir hier ja jemand helfen…

bei meiner DB ist die Datenbank 1,5 GB und mein Transaktionsprotokoll wird riesig derzeit 60 GB … habe mich bis jetzt damit nicht wirklich beschäftigt weil immer genug Platz war und keine Probleme damit auftraten …

jetzt stösst das ganze an die plattenkapazität und verursacht fehlermeldungen in der DB … ich soll eine Sicheung des Transaktionsprotokoll durchführen … damit wird aber scheinbar das protokoll auch nicht wieder kleiner …

woran kann das liegen und kann ich irgendwie anders das Protokoll auch wieder auf normalgroesse kriegen …

habe schon versucht im Enterprisemanager Datenbank verkleinern das brachte aber nur 200 MB … auserdem kam es mir viel zu schnell vor …

dann habe ich was über den Befehl DBCC SHRINKDB gelesen … kann man den einfach ausführen und alles ist wieder gut ???

Danke für eure Hilfe!!!

Welches DBMS? (owt)
owt.

ich kenne transactionlogs sowohl von sybase-sql als auch von oracle. in beiden fällen werden darin alle transaktionen protokolliert, die gegen die datenbank gefahren wurden.

wozu braucht man das ganze: erstens einmal im fehlerfall - benutzer schreibt gerade in die db, hat aber noch kein commit gemacht. normalerweise schreibt die db sofort in das datenfile. nun fällt der strom aus. folge: die datenbank ist inkonsistent. die db kann aber aufgrund der einträge im transactionlog herausfinden, was der letzte commitierte befehl und vor allem was der letzte nicht commitierte befehl war. mit diesen infos kann die db das datenfile „recovern“ - also einen konsistenten zustand wiederherstellen (= nur die commitierten transaktionen stehen im datenfile).

zum zweiten braucht man es für ein point-in-time-recovery. beispiel: chef kommt aufgeregt daher und meint, er kann einen wichtigen termin nicht mehr finden. nach langem hin und her kommt man drauf, dass der dödel den termin gestern abend gelöscht hat. wie kommt man wieder ran? die sicherung war am abend davor bzw. ein paar stunden nach der löschaktion. der termin wurde am selben tag erfasst, an dem er gelöscht wurde ==> er ist auf keiner sicherung drauf.

mit vollständigen transactionlogs kein problem: sicherung vom vortag einspielen und bis zum zeitpunkt x (zwischen erfassen und löschen des termins) „vorrollen“. beim vorrollen werden alle änderungen, die seit der letzten sicherung am datenfile gemacht wurden, nochmals ausgeführt. das dauert zwar extrem lange und blockiert die db für ein paar stunden. dafür findet man den gelöschten termin auch wieder. sobald der datensatz wieder da ist, kann man die letzte sicherung wieder einspielen (die man hoffentlich vor dem zurücksichern gemacht hat!) und normal weiterarbeiten.

langer rede kurzer sinn: bei den mir bekannten datenbanken kann man das transactionlog nach der sicherung löschen. man benötigt ja lediglich das log ab der letzten sicherung (sofern man eine generationensicherung hat).

bei sybase-sql muss man lediglich die db niederfahren. danach kann man einfach das log-file löschen. beim nächsten start wird automatisch ein neues angelegt und alles funkt wieder.

bei oracle ist das etwas komplizierter: es gibt dort redo-log-dateien, die man auf keinen fall löschen darf. diese dateien werden aber zyklisch überschrieben und werden daher nicht grösser. mit aktivierten archiver werden die redo-log-dateien vor dem überschreiben in ein eigenes verzeichnis weggesichert. diese dateien kann man dann löschen (sofern man genau weiss, was man tut).

zusammenfassung:

  1. das transactionlog kann man nicht kleiner machen (ohne den sinn des logs zu vernichten)
  2. wenn man weiss, was man tut, kann man das logfile löschen.
  3. wenn man nicht weiss, was man tut, kann man die db nachher vergessen.

bleibt lediglich zu sagen, dass man immer die genaue db-version angeben sollte, wen man solche fragen stellt…

erwin

Hallo Wendt,

Es gibt eine Möglichkeit unter MS SQL (wovon ich hier jetzt mal ausgehe wg. Enterprise Manager und ich denke, es ist der 2000er).

Folgendes: Du startest den Enterprise Manager. Im Konsolenstamm ist ein Eintrag Verwaltung unter dem jeweiligen SQL-Server. Hier drunter findest Du unter anderem den SQL-Server-Agent. Diesen solltest Du für solche Wartungsarbeiten starten.

Danach richtest Du unter Datenbank-Wartungspläne einen Wartungsplan ein. Dieser Wartungsplan kann folgende Aufgaben übernehmen: Sicherung der DB, Sicherung des Transaktionsprotokolls, Überprüfung Datenbank Integrität und das entscheidende für Dich ist der Punkt Datenbank opitmierung.

Haßt Du einen Wartungsplan erstellt, kannst Du diesen auch auserhalb der eingestellen Zeiten aufrufen. Diesen Punkt findest Du unter dem SQL-Server-Agent im Punkt Aufträge. Hier kannst Du jederzeit jeden Auftrag manuell starten.

Ich gehe mal davon aus, das Du/Ihr die Datenbank regelmäßig sichert. Wenn Du/Ihr eien professionelle Back-Up-Software benutzt, sollte diese in der Lage sein, den SQL-Dienst zu beenden. Meine Erfahrung hat aber gezeigt, daß es besser ist, eine Sicherung mit dem SQL-Server-Agent zu machen und dann diese Sicherungsdatei per Back-Up-Software wegzusichern, ohne den SQL-Dienst zu beenden.

Gruß
Ingo

Moin,

wofür das Tranaktionsprotokoll da ist haben meine beiden Vorredner dir ja schnon recht ausführlich erklärt :wink: hier noch eine Möglichkeit, die Größe des Protokolls zurückzusetzen:

Dazu den Query-Analyzer starten.

Use DerDatenbankName
BACKUP LOG DerDatenbankName WITH TRUNCATE_ONLY
DBCC SHRINKFILE (DerNameDerLogDatei,GrößeInMegaByte)

evtl muss der Schritt:

BACKUP LOG DerDatenbankName WITH TRUNCATE_ONLY

wiederholt werden (jedenfalls haben wir das bei unserem Server hier festgestellt).
Falls bei DBCC Shrinkfile eine Fehlermeldung ausgegeben wird, daß der Logdateiname nicht gefunden wird, kann man alternativ die FileID aus der tabelle sysfiles angegeben werden. Also einfach „Select * from sysfiles“ abfragen und dann die fileid der Protokolldatei in den obigen Befehl einsetzen. Das sollte die Protokolldatei wieder zusammenschnurzeln.

Durch das obige Vorgehen wird der nicht verwendete Speicherplatz im Protokoll freigegeben. Je nach Datenbankmodell und Einstellung der Protokollierung wird hier auch der nicht mehr verwendete Teil, also der Teil des Protokolls, der vor der Mindestwiederherstellungs-Protokollsequenznummer (MinLSN) liegt abgeschnitten. In Datenbanken mit einfacher Wiederherstellung sollte dies der letzte Checkpoint sein. (Ein Checkpoint wird z.B. bei Sicherung des Transaktionsprotokolls durch einen Wartungsplan usw gesetzt).

Gruß
D. Scholdei