Transaction-Logs verkleinern

[martin koenig]

Hallo zusammen

Verwende MS SQL 2000. Habe das gleiche Problem wie Willmar. Er hat am
11.8.2004 in diesem Forum eine Frage bezüglich Transaction Log File Grösse
gestellt. Die Hinweise von Bernd auf DBCC Shrinkfile und DBCC Shrink
Database und BACKUP LOG WITH TRUNCATEONLY waren genau richtig.

Bei mir war das Transaction File 80MB und jetzt ist es noch 1MB gross.

Wie kann ich das automatisieren, dass ich nicht andauernd manuell die Grösse
des Transaktion Log's runtersetzen muss? Durch die Growth Informationen auf
dem TransactionLog File? Wird das dann vom SQL Server korrekt gehandhabt
(dass auch wirklich die neusten Log Infos abgelegt werden und die alten
hinten raus faulen)? Wie verhält sich das auf die Performance? Was wird
generell in diesem Bereich empfohlen?


Vielen Dank für jeden Hinweis
Martin

[Christa Kurschat]

Hallo Martin,

Post by martin koenig
Hallo zusammen
Verwende MS SQL 2000. Habe das gleiche Problem wie Willmar. Er
hat am
11.8.2004 in diesem Forum eine Frage bezüglich Transaction Log
File Grösse gestellt. Die Hinweise von Bernd auf DBCC
Shrinkfile und DBCC Shrink Database und BACKUP LOG WITH
TRUNCATEONLY waren genau richtig.
Bei mir war das Transaction File 80MB und jetzt ist es noch
1MB gross.
Wie kann ich das automatisieren, dass ich nicht andauernd
manuell die Grösse des Transaktion Log's runtersetzen muss?
Durch die Growth Informationen auf dem TransactionLog File?

Nein, Du kannst einen entsprechenden Wartungsplan erstellen und automatisch
ausführen lassen.
z.B. Log sichern (bei Wiederherstellungsmodell "vollständig" oder
"massenprotokolliert") und anschließendes Verkleinern. Die Sivcherung
entfällt, wenn Dein Wiederherstellungsmodell auf "einfach" steht.

Post by martin koenig
Wird das dann vom SQL Server korrekt gehandhabt (dass auch
wirklich die neusten Log Infos abgelegt werden und die alten
hinten raus faulen)?

Ja, das wird sauber gehandhabt. Aber nicht immer ist der aktive Teil des
Logs auch am Anfang. Deshalb sollte die Option "benutzte Seiten an den
Anfang verschieben" eingestellt sein.

Post by martin koenig
Wie verhält sich das auf die Performance?

Nun ja, ein verkleinertes Log muß auch wieder vergrößert werden. Das kostete
natürlich Performance.
Deshalb sind regelmäßige Sicherungen (nicht bei Wiederherstellungsmodell
"einfach") empfohlen. Dadurch werden abgeschlossene Transaktionen aus dem
Log entfernt und der Platz zur Wiederverwendung bereitgestellt. Ist das Log
zur Wiederherstellung der Daten nicht nötig, stelle das
Wiederherstellungsmodell auf "einfach", dann wird der Platz beim Checkpunkt
wieder zur Verfügung gestellt. Das Log wächst so auf eine vertretbare Größe
und muß i.d.R. nicht verkleinert werden.

Post by martin koenig
Was wird generell in diesem Bereich empfohlen?

s.o.

Gruß
Christa
--
Access-FAQ: http://www.donkarl.com
KnowHow.mdb: http://www.freeaccess.de
SQL-Server-FAQ: http://www.berndjungbluth.de
Newbie-Info: http://www.doerbandt.de/Access/Newbie.htm
Suchen in den Newsgroups:
http://groups.google.de/advanced_group_search?hl=de&lr=&ie=UTF-8

[Christoph Muthmann]

Post by martin koenig
Hallo zusammen
Verwende MS SQL 2000. Habe das gleiche Problem wie Willmar. Er hat am
11.8.2004 in diesem Forum eine Frage bezüglich Transaction Log File
Grösse gestellt. Die Hinweise von Bernd auf DBCC Shrinkfile und DBCC
Shrink Database und BACKUP LOG WITH TRUNCATEONLY waren genau richtig.
Bei mir war das Transaction File 80MB und jetzt ist es noch 1MB gross.
Wie kann ich das automatisieren, dass ich nicht andauernd manuell die
Grösse des Transaktion Log's runtersetzen muss? Durch die Growth
Informationen auf dem TransactionLog File? Wird das dann vom SQL
Server korrekt gehandhabt (dass auch wirklich die neusten Log Infos
abgelegt werden und die alten hinten raus faulen)? Wie verhält sich
das auf die Performance? Was wird generell in diesem Bereich
empfohlen?

Hallo Martin,
falls Du keine Log-Sicherungen machst weil Du häufig genug Full-Backup
machst, könntest Du das Recovery-Modell der DB auf Simple stellen. Dann
werden inaktive Teile des Log wieder überschrieben.

Andernfalls lege z. B. einen Wartungsplan an, der die Sicherungen des Log
übernimmt und diese für den Worst-Case zur Verfügung stellt.

Bzgl. der Performance, solltest Du nur etwas merken, wenn das Log ständig
vergrößert werden muß, falls Du es regelmässig verkleinerst.

Schau Dir noch mal die Optionen des BACKUP DATABASE in der Online-Doku an.

Einen schönen Tag noch,
Christoph
--
(Please post ALL replies to the newsgroup only unless indicated
otherwise)

[martin koenig]

Besten Dank Christa und Christoph, Ihr habt mir sehr geholfen.