Transkatione Log , automatisch löschen, bei erfolgreichem Backup ?
Dirk Schächner
Hi,
ich habe das Problem, dass ich das Transaktions Log nach einem
erfolgreichen Backup automatisch löschen / verkleinern will.
Leider finde ich nirgends wie das gehen soll ?
Hat jemand einen Tip ?
Cioa
D. Schächner
Peter Putz
Hallo Dirk!
Versuche mal:
DUMP TRANSACTION datenbank TO logfile WITH NOUNLOAD, INIT, NOSKIP
Dirk Schächner schrieb:
Stefan Falk
Hallo Peter,
darf ich noch eine Frage draufsetzen? Wie ist das mit DUMP DATABASE? Wird
da das Tranaction Log nun automatisch geleert oder nicht? Die Doku verstehe
ich immer so, daß sie geleert wird. Aber irgendwie bin ich beim gucken mit
dem Enterprise Manager nicht so sicher.
Grüße,
Stefan Falk
Peter Putz <pu...@rmdata.co.at> schrieb im Beitrag
<350FEECB...@rmdata.co.at>...
Olaf Didszun
Hallo Stefan,
meine Erfahrungen mit dem Backup sehen so aus, daß der SQL-Server bei
einem Dump einer Datenbank, die kein Medium für das Log-File hat, das
Transaktionsprotokoll zurücksetzt.
Bei einer Datenbank, die ihr Transaktionsprotokoll in einem eigenen
Medium speichert (damit es getrennt gesichert werden kann), wird es
nur dann zurückgesetzt. wenn auch tatsächlich das
Transaktionsprotokoll per DUMP TRANSACTION gesichert wird.
Olaf Didszun (MCSE/MCT)
AP GmbH, Karlsruhe/Germany
Stefan Falk
Tag Olaf und Danke für Deine Antwort,
das hieße, wenn ich nur Voll-Backups vorhabe, ***sollte*** ich das Log im
selben Medium unterbringen wie die Daten? Liege ich da richtig? Denn sonst
bekäme ich das Log ja nur mit TRUNCATE LOG oder so wieder weg. Und zwischen
dem DUMP DATABASE und dem TRUNCATE LOG (wie gesagt, "oder so") gäbe es ja
ein Zeitfenster, in dem ein User eine Transaktion machen könnte, die
gelöscht wird, bevor das nächste Backup läuft.
Gruß, Stefan
Olaf Didszun <OlafD...@compuserve.com> schrieb im Beitrag
<3519536...@msnews.microsoft.com>...
Olaf Didszun
Hallo Stefan,
bei der Sache mit dem Zeitfenster hast Du recht, aber das macht
nichts, wenn Du zuerst ein DUMP DATABASE und anschließend ein DUMP
TRANSACTION machst. Zuerst wird die gesamte DB gesichert, und
anschließend wird noch das Transaktionsprotokoll geschrieben, und zwar
mit allen bis dahin abgeschlossenen Transaktionen. Es kann somit
nichts verloren gehen.
Bsp.:
DUMP DATABASE mydb TO backupmedia WITH INIT, NOUNLOAD
DUMP TRANSACTION mydb TO backupmedia WITH UNLOAD
Ob die Datenbank in ein Medium, oder in mehrere Medien verteilt wird
hängt zum einen vom Festplattenplatz ab, zum anderen aber auch von der
Performance. Wenn der DB-Server geschickt aufgebaut ist, kann man sehr
gute Geschwindigkeit dadurch erreichen, daß das Transaktionsprotokoll
von der Datenbank getrennt wird, indem die beiden Medien auf
unterschiedlichen Festplatten liegen. Schreibzugriffe können auf diese
Weise vom SQL-Server quasi parallel durchgeführt werden. Bei einer DB,
die ca. 400 MB groß ist, und evtl. nur von 3 Benutzern bearbeitet
wird, wird vermutlich kein großer Unterschied spürbar sein.
Olaf Didszun (MCSE/MCT)
AP GmbH, Karlsruhe/Germany
On Wed, 25 Mar 1998 13:25:09 -0800, "Stefan Falk"
Stefan Falk
Hallo Olaf,
Danke für die Info. Dadurch stellen sich mir aber noch zwei Fragen:
1. Sichert das DUMP TRANSACTION dann nach dem DUMP DATABASE nur Sachen, die
im DUMP DATABASE schon enthalten sind, oder müßte ich bei einem Ausfall
sowohl die DB als auch das Log zurücksichern?
2. Ich habe schon öfter versucht, mit DUMP TRANSACTION das Logfile klein zu
kriegen (in einer zur für Tests angelegten gut 1 GB großen Datenbank, in
der truncate log on checkpoint eingeschaltet ist). Auch nach dem DUMP
TRANSACTION ist das Log aber noch genau so groß. Warum? (Erst ein DBCC
NEWALLOC und DBCC CHECKDB ermöglichte es mir, das Protokoll manuell
abzuschneiden.) Es läuft NTS4/SP3 und SQL 6.5/SP3.
Viele Grüße,
Stefan Falk
Olaf Didszun <OlafD...@compuserve.com> schrieb im Beitrag
<351c06f5....@msnews.microsoft.com>...
Olaf Didszun
Hi Stefan,
der DUMP TRANSACTION sichert auch Sachen, die der DUMP DATABASE schon
geschrieben hat, aber es könnten ggf. auch neue Einträge dabei sein.
Deshalb sollten bei einem Restore IMMER beide Files eingespielt
werden.
Wenn der 'truncate log on checkpoint' eingeschaltet ist, macht das
Sichern des Log-Files eigentlich keinen Sinn, da es normalerweise
regelmäßig vom Server zurückgesetzt wird.
Wie hast Du die Größe überprüft?? Der Enterprise Manager 'spinnt'
häufiger bei der Ausgabe der Größe. Den korrekten Wert bekommst Du auf
jeden Fall mit DBCC CHECKTABLE(syslogs) im Kontext Deiner Datenbank.
Dabei wird nichts abgeschnitten, sondern die internen Einträge werden
korrigiert.
Olaf Didszun (MCSE/MCT)
AP GmbH, Karlsruhe/Germany
On Fri, 27 Mar 1998 12:41:31 -0800, "Stefan Falk"
Stefan Falk
Und wieder vielen Dank, Olaf,
truncate log on checkpoint ist bei dieser DB schon ok, weil sie ja nur zum
Testen existiert. Ich weiß schon, daß dann die Transaktionen nicht
gesichert werden können, die schon weg sind. Die DB wird nur komplett
gesichert (einmal pro Nacht). Nur wollte ich das Log auf 0% bekommen.
Dein Tip mit dbcc checktable(syslogs) war gut. Der sagte mir, a) er habe
etwas korrigiert und b) daß 100% frei wären. Enterprise Manager zeigt immer
noch nur 99,97% frei (obwohl alles SP4 ist). Auf einer anderen DB zeigt er
durchaus 100%. Schon komisch.
Viele Grüße,
Stefan Falk
Olaf Didszun <OlafD...@compuserve.com> schrieb im Beitrag
<351e621...@msnews.microsoft.com>...