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:
- das transactionlog kann man nicht kleiner machen (ohne den sinn des logs zu vernichten)
- wenn man weiss, was man tut, kann man das logfile löschen.
- 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
hier noch eine Möglichkeit, die Größe des Protokolls zurückzusetzen: