SQL 2005 - Logs werden nicht mehr abgeschnitten

[Data1701 10]

Mahlzeit,

 

ich habe hier ein Problem, dass ich mir nicht erklären kann. Seit dem 01.02.2010 werden anscheiend die LOGs auf den SQL-Servern nicht mehr auto. gekürzt. An diesem Tage wurde "nur" ein IE8 Patch installiert, nichts SQL relevantes.

 

Das SQL Studio zeigt mir schön wann die letzte Datenbank- bzw Logsicherung war, allerdings werden die LOGs nicht abgeschnitten. Ich kann natürlich händisch rangehen, aber das ist ja keine Lösung.

 

Soweit ich weiß, wurde an den SQL nicht gemacht bis auf das IE-Patch. Gesichert wird mit BackupExec, da wurde kein Patch installiert, davon abgesehen schneidet ja nicht BackupExec die LOGs ab sondern der SQL-Server, BE markiert nur die LOGs zum abschneiden.

 

Hat jemand einen Einfall, was hier schief laufen könnte.

 

Gruß Data

[NilsK 2.934]

Moin,

 

sagt das Eventlog was dazu? Das BE-Logging?

 

Wie sind die Datenbankoptionen gesetzt? Poste mal die Ausgabe von

exec sp_helpdb NameDerDB

 

("Ausgabe in Text" einstellen.)

 

Und wie ist der Backupjob definiert? Anders als Exchange schneidet SQL Server beim Full Backup die Logs keineswegs ab, das tut es nur beim Log-Backup!

 

Gruß, Nils

[Data1701 10]

@NilsK

 

Mal bitte für Doofe. SQL ist nicht mein Ding.

 

Studio öffnen - Neue Abfrage ? Nur Text habe ich nicht gefunden, aber meintest Du diese Ausgabe ?

 

Name=DB1

1459.81 MB

User=

DBID=42

created=Sep 9 2009 S

Status=ONLINE, Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=FULL, Version=611, Collation=Latin1_General_CI_AS, SQLSortOrder=0, IsAutoCreateStatistics, IsAutoUpdateStatistics

Comptibilty=80

 

BackupExec-Logs sind grün, deshalb habe ich den Anwuchs der LOG-Files auch gar nicht bemerkt.

 

Event-Log für o.g. DB (LOG-Backup):

 

Das Protokoll wurde gesichert. Datenbank: DB1, Erstellungsdatum(-zeit): 2009/09/09(15:54:14), Erste LSN: 508:11530:1, Letzte LSN: 508:15399:1, Anzahl der Sicherungsgeräte: 1, Geräteinformationen: (FILE=1, TYPE=VIRTUAL_DEVICE: {'DB1_00__8f98ee60_a19b_4bd3_830d_8a66235d5033_'}). Diese Meldung dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.

 

Event-Log für o.g. DB (Full-Backup):

 

Der E/A-Vorgang für die DB1-Datenbank hängt. Es ist keine Benutzeraktion erforderlich. Wenn der E/A-Vorgang jedoch nicht umgehend fortgesetzt wird, sollten Sie die Sicherung möglicherweise abbrechen.

 

gefolgt von:

 

Der E/A-Vorgang für die DB1-Datenbank wurde fortgesetzt. Es ist keine Benutzeraktion erforderlich.

 

gefolgt von:

 

Die Datenbank wurde gesichert. Datenbank: DB1, Erstellungsdatum(-zeit): 2009/09/09(15:54:14), gesicherte Seiten: 1, Erste LSN: 508:11231:101, Letzte LSN: 508:11274:1, Anzahl der Sicherungsgeräte: 1, Geräteinformationen: (FILE=1, TYPE=VIRTUAL_DEVICE: {'BE_SQLAgent-DB1__30d4e15d_4b5e_40dd_997a_fe31fe33e7ac_'}).

 

Das wars. Eigentlich alles i.O.

 

Gruß Data

[Data1701 10]

Sorry, habe was vergessen:

 

Nächtliches Full-Backup, dann im Abstand von 4 Stunden jeweils ein LOG-Backup, in BE (Transaktionsprotokolle sichern).

 

Gruß Data

[NilsK 2.934]

Moin,

 

sieht doch erst mal alles grün aus. Warum bist du denn der Ansicht, dass die Logs nicht abgeschnitten werden? Wenn es um das Anwachsen der Log-Dateien geht: Das ist normal, die verkleinern sich nicht von selbst (anders als bei Exchange!). Das Log wird immer sequenziell geschrieben, und erst wenn das Log abgeschnitten wurde (per Backup oder per Truncate), fängt SQL Server innerhalb der bestehenden Datei wieder am Anfang an.

 

Könnte also ein reines Verständnisproblem sein.

 

Verkleinern des Transaktionsprotokolls

 

Führe doch im SSMS als neue Abfrage mal dieses Kommando aus:

 

dbcc sqlperf (logspace)

 

Gruß, Nils

[Data1701 10]

Lese ich mir morgen durch.

 

Ich bin der Meinung, dass die LOGs sehr groß wurden, da auf beiden Server die LDF-Datei das Datum 01.02.2010 trug und auf einem Server 25 GB auf eine anderen 100 GB groß war.

 

Ich war der Meinung, dass SQL, ähnlich dem EX-Backup die LOGS auto. abschneidet.

 

Habe den Artikel noch nicht studiert, wenn ich den gelesen habe und noch Fragen habe, dann werde ich mich noch einmal hier melden.

 

Gruß Data

[NilsK 2.934]

Moin,

 

die Logs können auch durchaus sehr groß werden, wenn viele Transaktionen laufen. Das können z.B. Imports sein, das Löschen großer Datenmengen oder auch Wiederholtes Ändern derselben Daten. Jede Transaktion muss SQL Server einzeln protokollieren.

 

Daher sollte man in Produktionsumgebungen auch a) die Loggröße überwachen und b) einen Task einrichten, der die Notbremse ziehen kann, indem er ab einem Schwellwert das Protokoll abschneidet und direkt danach eine Vollsicherung ausführt.

 

Gruß, Nils

[Data1701 10]

So, langsam blicke ich durch.

 

Intressant war auch der Artikel:

 

Faktoren, die das Abschneiden des Protokolls verzögern können

Faktoren, die das Abschneiden des Protokolls verzögern können.

 

Wie sieht denn Dein Notbremsskript aus ? Würde mich mal intressieren.

 

So wie ich es bverstanden habe, kann man gar nicht vorhersagen, wann die LOGs abgeschnitten werden, oder.....

 

Das mit dem Skript ist mit Sicherheit eine super Sache, nur würde ich vom SQL erwarten, dass er das sleber hinbekommt.

 

Die riesen LOGs machen dei DB auch nicht gerade schneller.

 

Gruß Data

[NilsK 2.934]

Moin,

 

bevor man urteilt, sollte man eine Sache kennen.

 

Wann das Log abgeschnitten wird, ist eindeutig bekannt: Beim Log-Backup. Punkt. Eine große Logdatei macht den Server nicht langsamer, denn er muss ohnehin alle Transaktionen protokollieren, darüber hinaus wird das Log sequenziell geschrieben. Schlechtes Log-Management kann den Server aber durchaus bremsen - etwa falsche Einstellungen zur Dateigröße, die dann ständige Vergrößerung erfordern bzw. Fragmentierung erzeugen.

 

Das "Notbremse-Skript" ist eigentlich simpel: Man erzeuge im SQL Agent einen Auftrag, der die Loggröße oder den freien Plattenplatz überwacht und bei Überschreiten einer Schwelle zwei Kommandos ausführt: 1. Abschneiden des Logs, 2. Full Backup der Datenbank.

 

Wenn man mit kritischen Datenbanken operiert, sollte man selbet Know-how dazu aufbauen oder sich extern unterstützen lassen. Eure Firmenwagen lasst ihr ja sicher auch warten.

 

Gruß, Nils

[Hr_Rossi 10]

hi

 

fall du doch manuell ranmusst...

 

c:\sqlmaint -S SERVER\deineinstanz

1>USE MeineDatenbank

2>BACKUP LOG MeineDatenbank TO DISK = 'C:\Backup.bak'

3>DBCC SHRINKFILE (MeineDatenbank_log, 1)

>GO

 

lg

[NilsK 2.934]

Moin,

 

warum sollte man das über sqlmaint machen?

 

Gruß, Nils