8
MS SQL 2005 - Fehler beim Verkleinern des TA Logs
Hallo,
meine MS SQL Schulung ist schon etwas her. Seit der Schulung habe ich nicht wieder mit MS SQL DBs gearbeitet. Das ist ne Grundlage
Jetzt haben wir hier eine MS SQL 2005'er DB, für die wir keinen Support gekauft haben. Ja, ist doof, ich weiß. Daher bin ich erstmal in den Foren der Welt auf der Suche nach Hinweisen, was schief laufen könnte. Folgende Situation:
Durch einen nächtlichen Reorg der DB läuft das TA Log auf gut 40GB voll. Das ist zu groß für die Festplatte. Es wird daher direkt nach dem Reorg eine Sicherung des TA Logs durchgeführt und das log geleert.In den Informationen zum Log steht auch, dass es nur noch zu 96% gefüllt ist. Klar, nach der Sicherung des Logs wird dieses geleert, der Speicherplatz auf der Festplatte aber nicht verkleinert. Daher wollen wir das Log jetzt automatisiert durch einen Wartungsplan verkleinern. Das manuelle Verkleinern durch einen Task (Rechtsklick auf DB - Tasks - Verkleinern - Dateien - Auswahl Protokoll und dann das entsprechende logfile) funktioniert problemlos. Jetzt haben wir probiert, das, was manuell funktioniert, in den Wartungsplan für den Reorg aufzunehmen. Dazu wollte ich einen T-SQL Task im Wartungsplan erstellen und entsprechend in der Ablauf verknüpfen.
Folgender T-SQL Code sollte eigentlich funktionieren (zumindest ist das das Skript, welches das Management Studio dafür erzeugt, wenn man den Task manuell ausführen will und dann oben auf Skript generieren geht):
Leider scheint das Skript aber nicht die richtige Datenbank zu wählen, denn es versucht immer die Datei in der master DB zu finden:
Das verstehe ich nicht. Das og. T-SQL Skript hat mir der Management Studio selbst erzeugt. Und schaue ich mir die Syntax an, ist das auch alles korrekt. Testweise habe ich dann mal geschaut, ob es mit der File ID für die Datei "pb59_echt_log" klappt. Die File ID ist die 2. Mit dem Code:
gibt es wenigstens keine Fehlermeldungen mehr, interessanterweise verkleinert er jetzt aber die Datei mit der File ID2 der Master DB. Ehrlich gesagt verstehe ich nicht, warum er mit dem og. Skript nicht auf die richtige DB zugreift.
Das Einfügen von Semikolons hat nichts geändert.
Manuelle Abfragen im Management Studio funktionieren auch auf Verschiedenen DB heraus, sogar mit dem Use "DB" Befehl.
Was mir noch aufgefallen ist: Der Besitzer dieser DB ist nicht sa, sondern ein Domänen-Benutzer. Dieser hat die DB damals angelegt (ist ein Dienstleister von uns, das Domänenkonto existiert immer noch).
Hat jemand eine Ahnung, was ich falsch mache? Viele lieben Dank fürs Lesen und drüber nachdenken.
meine MS SQL Schulung ist schon etwas her. Seit der Schulung habe ich nicht wieder mit MS SQL DBs gearbeitet. Das ist ne Grundlage
Jetzt haben wir hier eine MS SQL 2005'er DB, für die wir keinen Support gekauft haben. Ja, ist doof, ich weiß. Daher bin ich erstmal in den Foren der Welt auf der Suche nach Hinweisen, was schief laufen könnte. Folgende Situation:
Durch einen nächtlichen Reorg der DB läuft das TA Log auf gut 40GB voll. Das ist zu groß für die Festplatte. Es wird daher direkt nach dem Reorg eine Sicherung des TA Logs durchgeführt und das log geleert.In den Informationen zum Log steht auch, dass es nur noch zu 96% gefüllt ist. Klar, nach der Sicherung des Logs wird dieses geleert, der Speicherplatz auf der Festplatte aber nicht verkleinert. Daher wollen wir das Log jetzt automatisiert durch einen Wartungsplan verkleinern. Das manuelle Verkleinern durch einen Task (Rechtsklick auf DB - Tasks - Verkleinern - Dateien - Auswahl Protokoll und dann das entsprechende logfile) funktioniert problemlos. Jetzt haben wir probiert, das, was manuell funktioniert, in den Wartungsplan für den Reorg aufzunehmen. Dazu wollte ich einen T-SQL Task im Wartungsplan erstellen und entsprechend in der Ablauf verknüpfen.
Folgender T-SQL Code sollte eigentlich funktionieren (zumindest ist das das Skript, welches das Management Studio dafür erzeugt, wenn man den Task manuell ausführen will und dann oben auf Skript generieren geht):
USE [pb_echt]
GO
DBCC SHRINKFILE (N'pb59_echt_Log' , 0, TRUNCATEONLY)
GOLeider scheint das Skript aber nicht die richtige Datenbank zu wählen, denn es versucht immer die Datei in der master DB zu finden:
Fehler beim Ausführen der Abfrage 'DBCC SHRINKFILE (N'pb59_echt_Log' , 0, TRUNCATEONLY)': 'Die Datei 'pb59_echt_Log' wurde für die 'master'-Datenbank nicht in sys.database_files gefunden. Die Datei ist entweder nicht vorhanden oder wurde gelöscht. '. Mögliche Ursachen sind folgende: Probleme bei der Abfrage, nicht richtig festgelegte ResultSet-Eigenschaft, nicht richtig festgelegte Parameter oder nicht richtig hergestellte Verbindung. Das verstehe ich nicht. Das og. T-SQL Skript hat mir der Management Studio selbst erzeugt. Und schaue ich mir die Syntax an, ist das auch alles korrekt. Testweise habe ich dann mal geschaut, ob es mit der File ID für die Datei "pb59_echt_log" klappt. Die File ID ist die 2. Mit dem Code:
USE [pb_echt]
GO
DBCC SHRINKFILE (2 , 0, TRUNCATEONLY)
GOgibt es wenigstens keine Fehlermeldungen mehr, interessanterweise verkleinert er jetzt aber die Datei mit der File ID2 der Master DB. Ehrlich gesagt verstehe ich nicht, warum er mit dem og. Skript nicht auf die richtige DB zugreift.
Das Einfügen von Semikolons hat nichts geändert.
Manuelle Abfragen im Management Studio funktionieren auch auf Verschiedenen DB heraus, sogar mit dem Use "DB" Befehl.
Was mir noch aufgefallen ist: Der Besitzer dieser DB ist nicht sa, sondern ein Domänen-Benutzer. Dieser hat die DB damals angelegt (ist ein Dienstleister von uns, das Domänenkonto existiert immer noch).
Hat jemand eine Ahnung, was ich falsch mache? Viele lieben Dank fürs Lesen und drüber nachdenken.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 147384
Url: https://administrator.de/contentid/147384
Ausgedruckt am: 14.11.2024 um 23:11 Uhr
8 Kommentare
Neuester Kommentar
Morgen Viprex,
ein derartiges Anwachsen der TA-Logs ist immer ein Zeichen dafür, das das Wiederherstellungsmodell nicht auf 'einfach' gestellt ist.
Jetzt stellt sich die Frage, warum?
Müssen die Logs zwischen den Sicherungen aufgehoben werden?
Ich habe keine einzige Datenbank, welche einen anderen Wiederherstellungsmodus als simple eingerichtet hat.
Wenn du die Einstellung suchst:
Eigenschaften der DB -> Optionen -> Wiederherstellungsmodell (einfach wäre am Besten)
Wenn du eine aktuelle Sicherung hast, kannst du dies auch dort umstellen.
ein derartiges Anwachsen der TA-Logs ist immer ein Zeichen dafür, das das Wiederherstellungsmodell nicht auf 'einfach' gestellt ist.
Jetzt stellt sich die Frage, warum?
Müssen die Logs zwischen den Sicherungen aufgehoben werden?
Ich habe keine einzige Datenbank, welche einen anderen Wiederherstellungsmodus als simple eingerichtet hat.
Wenn du die Einstellung suchst:
Eigenschaften der DB -> Optionen -> Wiederherstellungsmodell (einfach wäre am Besten)
Wenn du eine aktuelle Sicherung hast, kannst du dies auch dort umstellen.
Das Wiederherstellungsmodell ist in der Tat "Vollständig". Warum, weiß ich nicht. So ganz unwichtig sit die DB nicht, denn dort läuft unser ERP System im Cluster. So einfach etwas umstellen kann und will ich da nicht. Ich mache mich jetzt erstmal schlau, was das Wiederherstellungsmodell denn bedeutet.
Meinst du denn, dass die Probleme mit dem Verkleinern des Logs daher rühren?
Meinst du denn, dass die Probleme mit dem Verkleinern des Logs daher rühren?
Zitat von @Viprex:
Das Wiederherstellungsmodell ist in der Tat "Vollständig". Warum, weiß ich nicht. So ganz unwichtig sit die
DB nicht, denn dort läuft unser ERP System im Cluster. So einfach etwas umstellen kann und will ich da nicht. Ich mache mich
jetzt erstmal schlau, was das Wiederherstellungsmodell denn bedeutet.
Hier solltest du dich in der Tat schlau machen. Von Clustern habe ich keinerlei Ahnung.Das Wiederherstellungsmodell ist in der Tat "Vollständig". Warum, weiß ich nicht. So ganz unwichtig sit die
DB nicht, denn dort läuft unser ERP System im Cluster. So einfach etwas umstellen kann und will ich da nicht. Ich mache mich
jetzt erstmal schlau, was das Wiederherstellungsmodell denn bedeutet.
Meinst du denn, dass die Probleme mit dem Verkleinern des Logs daher rühren?
Beim Wiederherstellungsmodell 'vollständig' müssen diese Logs gesichert werden. Dann wird das Protokoll automatisch gelöscht/verkleinert.
Schau einfach in die Online-Hilfe vom SQL-Server (Managementstudio -> DB-Optionen -> F1)
Moin Viprex,
wenn ich mir den Dateinamen anschaue, frage ich mich, ob Deine DB vielleicht "pb59_echt" und nicht "pb_echt" heißt.
Ansonsten gäbe es noch die Möglichkeit, gleich die ganze DB und nicht nur die Logdatei zu verkleinern:
Und außerdem noch die Variante, die Datenbank zu trennen, dann die Logdatei zu löschen und anschließend die Datendatei wieder anzuhängen. Dann wird die Logdatei neu erzeugt:
Hat natürlich den Nachteil, daß die DB kurzzeitig offline ist.
Weitere Möglichkeit ist auch noch, daß der Benutzer, der den Job im Wartungsplan ausführt, nicht die nötigen Berechtigungen hat, auf die DB zuzugreifen.
Dein Problem liegt auf jeden Fall nicht im "dbcc shrinkfile", sondern im "use [pb_echt]".
Und weil hier grade die Diskussion um das Wiederherstellungsmodell geht:
Für eine produktive DB solltest Du das Modell auf "Vollständig" lassen. Wenn Dir Deine DB abschmiert, willst Du sie ja wahrscheinlich so weit wie möglich wiederherstellen. Mit dem einfachen Modell geht das bis zur letzten Sicherung und fertig. Mit dem vollständigen Modell kannst Du bis zum Crash wiederherstellen oder auch bis zu einem bestimmten Zeitpunkt.
Wenn Du keine Ahnung hast, welches Modell Ihr braucht, dann laß die Finger von dem Schalter weg!
Gruß, Mad Max
wenn ich mir den Dateinamen anschaue, frage ich mich, ob Deine DB vielleicht "pb59_echt" und nicht "pb_echt" heißt.
Ansonsten gäbe es noch die Möglichkeit, gleich die ganze DB und nicht nur die Logdatei zu verkleinern:
dbcc shrinkdatabase ('pb_echt')
-- oder (?)
dbcc shrinkdatabase ('pb59_echt') Und außerdem noch die Variante, die Datenbank zu trennen, dann die Logdatei zu löschen und anschließend die Datendatei wieder anzuhängen. Dann wird die Logdatei neu erzeugt:
exec sp_detach_db 'pb_echt'
exec xp_cmdshell 'del c:\datenbanken\pb59_echt_Log.ldf' -- xp_cmdshell muss erlaubt sein oder es wird anders geloescht
exec sp_attach_db 'pb_echt', 'c:\datenbanken\pb59_echt.mdf' Hat natürlich den Nachteil, daß die DB kurzzeitig offline ist.
Weitere Möglichkeit ist auch noch, daß der Benutzer, der den Job im Wartungsplan ausführt, nicht die nötigen Berechtigungen hat, auf die DB zuzugreifen.
Dein Problem liegt auf jeden Fall nicht im "dbcc shrinkfile", sondern im "use [pb_echt]".
Und weil hier grade die Diskussion um das Wiederherstellungsmodell geht:
Für eine produktive DB solltest Du das Modell auf "Vollständig" lassen. Wenn Dir Deine DB abschmiert, willst Du sie ja wahrscheinlich so weit wie möglich wiederherstellen. Mit dem einfachen Modell geht das bis zur letzten Sicherung und fertig. Mit dem vollständigen Modell kannst Du bis zum Crash wiederherstellen oder auch bis zu einem bestimmten Zeitpunkt.
Wenn Du keine Ahnung hast, welches Modell Ihr braucht, dann laß die Finger von dem Schalter weg!
Gruß, Mad Max
Hallo nochmal,
vielen Dank für eure Antworten.
Die Datenbank heißt definitiv pb_echt.
Ein manuelles Verkleinern der Datei funktioniert problemlos.
Das USE PB_Echt scheint in der Tat der Knackpunkt zu sein. Der Hinweis auf fehlende Berechtigung ist ein sehr guter. Da werde ich mal nachforschen.
Das Wiederherstellungsmodell lasse ich unberührt, denn es werden ja sowieso ständig Vollsicherungen durchgeführt. Das ist also kein Hindernis. Anscheinend leert die Vollsicherung die TA Protokoll Datei zwar, aber verkleinert sie nicht physikalisch. Daher eben die Idee den T-SQL Task hinten dran anzufügen.
Die Datenbank trennen, um die logdatei löschen zu können, ist ja nicht notwendig, denn das manuelle Verkleinern durch den Wizzard funktioniert ja (wie oben geschrieben: Rechtsklick auf DB - Task - Verkleinern - Dateien -> Auswahl von Protokoll und dann die Datei)
Frage zum Vorschlag, die ganze DB zu verkleinern: Wird dann auch das logfile verkleinert? Außerdem dachte ich, dass es mit MS SQL (zumindest in Version 2005) nicht möglich ist, einmal physikalisch belegten Speicherplatz wieder freizugeben. Logisch (also innerhalb der DB Datei) geht das zwar - das nennt sich dann doch "leeren der DB" - aber verkleinern geht nicht, oder liege ich da auch vollkommen daneben?
Ich werde erstmal schauen, ob ich mit den Benutzerrechte weiterkomme. Vielen Dank.
vielen Dank für eure Antworten.
Die Datenbank heißt definitiv pb_echt.
Ein manuelles Verkleinern der Datei funktioniert problemlos.
Das USE PB_Echt scheint in der Tat der Knackpunkt zu sein. Der Hinweis auf fehlende Berechtigung ist ein sehr guter. Da werde ich mal nachforschen.
Das Wiederherstellungsmodell lasse ich unberührt, denn es werden ja sowieso ständig Vollsicherungen durchgeführt. Das ist also kein Hindernis. Anscheinend leert die Vollsicherung die TA Protokoll Datei zwar, aber verkleinert sie nicht physikalisch. Daher eben die Idee den T-SQL Task hinten dran anzufügen.
Die Datenbank trennen, um die logdatei löschen zu können, ist ja nicht notwendig, denn das manuelle Verkleinern durch den Wizzard funktioniert ja (wie oben geschrieben: Rechtsklick auf DB - Task - Verkleinern - Dateien -> Auswahl von Protokoll und dann die Datei)
Frage zum Vorschlag, die ganze DB zu verkleinern: Wird dann auch das logfile verkleinert? Außerdem dachte ich, dass es mit MS SQL (zumindest in Version 2005) nicht möglich ist, einmal physikalisch belegten Speicherplatz wieder freizugeben. Logisch (also innerhalb der DB Datei) geht das zwar - das nennt sich dann doch "leeren der DB" - aber verkleinern geht nicht, oder liege ich da auch vollkommen daneben?
Ich werde erstmal schauen, ob ich mit den Benutzerrechte weiterkomme. Vielen Dank.
Zitat von @Viprex:
Frage zum Vorschlag, die ganze DB zu verkleinern: Wird dann auch das logfile verkleinert? Außerdem dachte ich, dass es mit
MS SQL (zumindest in Version 2005) nicht möglich ist, einmal physikalisch belegten Speicherplatz wieder freizugeben. Logisch
(also innerhalb der DB Datei) geht das zwar - das nennt sich dann doch "leeren der DB" - aber verkleinern geht nicht,
oder liege ich da auch vollkommen daneben?
Frage zum Vorschlag, die ganze DB zu verkleinern: Wird dann auch das logfile verkleinert? Außerdem dachte ich, dass es mit
MS SQL (zumindest in Version 2005) nicht möglich ist, einmal physikalisch belegten Speicherplatz wieder freizugeben. Logisch
(also innerhalb der DB Datei) geht das zwar - das nennt sich dann doch "leeren der DB" - aber verkleinern geht nicht,
oder liege ich da auch vollkommen daneben?
Ja, auch die Logdatei wird verkleinert. Und auch die physikalische Datei kann verkleiner werden. Das war doch auch das, was Du mit dbcc shrinkfile versucht hast, oder?
Gruß, Mad Max
Ich habe mich wohl auch nicht ganz deutlich ausgedrückt. Sorry.
Also mit leeren ist das logische Platz schaffen innerhalb der DB Datei gemeint.
Mit verkleinern ist das Freigeben von Speicherplatz auf der Festplatte durch zusammenschrumpfen der Datei auf die virtuell benötigte Größe gemeint.
Ich dachte bisher immer, dass man bei MS SQL 2005 DB Dateien zwar leeren, aber nicht verkleinern kann.
Ganz im Gegenteil zu den Protokolldateien. Diese lassen sich sowohl leeren, als auch verkleinern.
Meinst du jetzt verkleinert oder geleert?
Wenn du auch vom Verkleinern redest, so wie ich hier, dann ist es genau das, was ich eigentlich gerne (automatisiert - denn manuell gehts ja) wollte.
Also mit leeren ist das logische Platz schaffen innerhalb der DB Datei gemeint.
Mit verkleinern ist das Freigeben von Speicherplatz auf der Festplatte durch zusammenschrumpfen der Datei auf die virtuell benötigte Größe gemeint.
Ich dachte bisher immer, dass man bei MS SQL 2005 DB Dateien zwar leeren, aber nicht verkleinern kann.
Ganz im Gegenteil zu den Protokolldateien. Diese lassen sich sowohl leeren, als auch verkleinern.
Meinst du jetzt verkleinert oder geleert?
Zitat von @MadMax:
Ja, auch die Logdatei wird verkleinert. Und auch die physikalische Datei kann verkleiner werden. Das war doch auch das, was Du mit
dbcc shrinkfile versucht hast, oder?
Ja, auch die Logdatei wird verkleinert. Und auch die physikalische Datei kann verkleiner werden. Das war doch auch das, was Du mit
dbcc shrinkfile versucht hast, oder?
Wenn du auch vom Verkleinern redest, so wie ich hier, dann ist es genau das, was ich eigentlich gerne (automatisiert - denn manuell gehts ja) wollte.
Hallo Viprex,
mit "verkleinert" meine ich verkleinert, deswegen habe ich auch "verkleinert" geschrieben. Wenn ich geleert gemeint hätte, hätte ich "geleert" geschrieben
Im Übrigen gibt es noch zwei weitere Möglichkeiten, Dein Problem zu lösen:
1. In den Datenbankeigenschaften, Fenster Optionen, gibt es den Schalter "Automatisch verkleinern". Allerdings hatte ich mit der Einstellung den Eindruck, daß die Geschwindigkeit der Zugriffe darunter leidet, weil der Server ständig mit dem Verkleinern und wieder Vergrößern beschäftigt war.
2. Einen Windows-Task einrichten und per sqlcmd den Befehl "dbcc shrinkwasauchimmer" ausführen.
Gruß, Mad Max
mit "verkleinert" meine ich verkleinert, deswegen habe ich auch "verkleinert" geschrieben. Wenn ich geleert gemeint hätte, hätte ich "geleert" geschrieben
Im Übrigen gibt es noch zwei weitere Möglichkeiten, Dein Problem zu lösen:
1. In den Datenbankeigenschaften, Fenster Optionen, gibt es den Schalter "Automatisch verkleinern". Allerdings hatte ich mit der Einstellung den Eindruck, daß die Geschwindigkeit der Zugriffe darunter leidet, weil der Server ständig mit dem Verkleinern und wieder Vergrößern beschäftigt war.
2. Einen Windows-Task einrichten und per sqlcmd den Befehl "dbcc shrinkwasauchimmer" ausführen.
Gruß, Mad Max
