Transaktionsprotokoll ...?

[Andreas Liebert]

Hi Leute
ich hab ein Problem und zwar wir entwickeln mit der Datenbank MS SQL Server und gestern wollt ich einen ganz einfachen Befehl 'Delete from Rechpos' ausführen aber dann kam die Fehlermeldung dass mein Transaktionsprotokoll voll ist! Jetzt hab ich schon herausgefunden dass es daran gelegen hat dass meine Festplatte voll war da das Transaktionsprotokoll 1GB groß war!!! Ich hab auch herausgefunden dass man das TP verkleinern kann indem man

1. "Select * from sysfiles"
Im Ergebnis die FileID des Logfiles heraussuchen

2. "BACKUP LOG datenbank WITH NO_LOG"

3. "DBCC SHRINKFILE (FileID,100)"
100= Größe in MB

eingibt.
Jetzt bin ich mir nur nicht sicher ob es irgendeinen Nachteil oder sonstiges gibt worauf ich achten muss wenn ich das TP einfach verkleiner!
Vielleicht kann mir ja jemand helfen!

Oder gibt es vielleicht eine Möglichkeit, dass das Protokoll überhaupt nicht erst größer wird, bzw. es sich automatisch wieder leert? Ich müsste es nämlich auf ca. 300 MB beschränken, da die Festplatte sehr begrenzt ist.

Mfg
Andy

[Andreas Kosch]

Hallo,

der MS SQL Server legt eine neue Datenbank standardmässig im "Entwickler-Modus" an, damit die ersten Schritte so einfach wie nur möglich ablaufen. Über den Eigenschaftsdialog dieser Datenbank (Enterprise-Manager) sollte die Auswahl im Auswahlfeld <b>Wiederherstellung | Modell</b> an die eigenen Anforderungen angepasst werden. Je nach der dort getroffenen Einstellung erwartet der Server, dass regelmässige Backups der Datenbank die Transaktionslogs abschneiden. Wenn man über den internen Agent des MS SQL Servers sein Backup regelmässig ablaufen lässt, wird man niemals mit diesem Problem konfrontiert :-)

Die physische Log-Datei ist intern in virtuelle Logdateien unterteilt, deren Anzahl und Größe von der aktuellen Datenbankaktivität abhängt. Jeder Eintrag im Transaction Log erhält eine eindeutige <i>Log Sequence Number</i> (LSN). Die physische Datei für das Transaktions-Log wächst immer dann an, wenn der Platzbedarf für die virtuellen Logdateien am Ende der physischen Datei angekommen ist und der SQL Server noch nicht die Log-Einträge vor der minimalen LSN gesichert hat. Die Log-Eintrag vor der minimalen LSN spielen beim Recovery keine Rolle mehr, werden allerdings für das Rollforward benötigt, wenn die Datenbank nach dem Einspielen des letzen Voll-Backups über die gesicherten Log-Dateien wiederhergestellt werden soll. Wenn diese Log-Sequenzen nicht benötigt werden, kann der SQL Server die Log-Einträge vor der minimalen LSN auch überschreiben, wenn eine der folgenden Bedingungen erfüllt wurde:

1. Das Log wurde über die T-SQL-Aufrufe BACKUP LOG WITH NO_LOG oder BACKUP LOG WITH TRUNCATE_ONLY abgeschnitten.

2. Das Abschneiden der Log-Datei wurde über <b>trunc. log on chkpt</b> automatisch angefordert (SQL Server 7) oder über das Wiederherstellungs-Modell <b>Einfach</b> angefordert (SQL Server 2000).

3. Es wird seit dem letzten vollständigen Backup eine Operation durchgeführt, die keine Log-Dateien anlegt (Bulkcopy).

4. Es wurde noch niemals ein vollständiges Datenbank-Backup ausgelöst.

Wenn eine dieser Bedindungen zutrifft, recycelt der SQL Server immer denn den "alten" Logbereich, wenn eine virtuelle Logdatei an das Ende der physischen Logdatei kommt. Das Abschneiden des Logs markiert also nur den wiederverwendbaren Platz der Logdatei, verkleinert diese jedoch nicht. Zur Verkleinerung der physischen Logdatei stehen 2 Wege offen:

1. Datenbank-Optionsdialog: Automatisch verkleinern

2. Oder manuell über SQL Query Analyzer über die folgenden Anweisungen :
<pre>
dbcc log(TestDB,0); -- Anzahl der Einträge in der Logdatei ermitteln
checkpoint -- explizit einen Prüfpunkt setzen, Logeinträge werden in DB geschrieben
backup log TestDB with no_log -- Inaktive Einträge abschneiden
dbcc shrinkfile(TestDB_Log) -- Logdatei soll verkleinert werden
dbcc shrinkdatabase(TestDB) -- Datenbankdatei soll verkleinert werden
</pre&gt

[Andreas Liebert]

Vielen Dank Herr Kosch. Das hat uns sehr weitergeholfen.

mfg
Andreas Lieber