Meine templog.ldf ist riesig (45 GB). Was ist, wenn ich etwas tun soll?

Ich habe eine SQL 2005-Installation und meine Datei templog.ldf wächst ständig, um den gesamten freien Speicherplatz auf dem Laufwerk zu belegen, auf dem sie sich befindet. Manchmal hört es mit ein paar MB frei auf, aber manchmal geht es noch weiter. Dies ist das Laufwerk c, von dem ich denke, dass dieses Verhalten mit einigen anderen Problemen zusammenhängt, die ich gesehen habe.

Meine Frage ist, was soll ich tun, ich kann das Protokoll auf ein anderes Laufwerk verschieben, aber ich habe Grund zu der Annahme, dass es dort nicht dasselbe tut. Ich gehe davon aus, dass dieses Verhalten wahrscheinlich auf etwas zurückzuführen ist, das ich ändern kann, und dass 45 GB eine ungewöhnliche Größe für das Tempdb-Protokoll sind. Wir verwenden viele temporäre Tabellen und Funktionen mit Tabellenwerten in unserem Code, sodass es genügend Spielraum für die Verwendung von Tempdb gibt. Ich kann das Wachstum der Tempdb-Datenbank verstehen, verstehe aber nicht den Grund für das Wachstum des Templogs.

Bisher habe ich DBCC OPENTRAN ('tempdb') ausgeführt, um festzustellen, ob alte Transaktionen herumhängen, aber nicht. Ich habe gelesen, wie man die Tempdb verkleinert, und habe dies einige Male getan, aber ich frage mich wirklich, was ich tun kann, um dies zu verhindern, oder mehr Details darüber, warum es möglicherweise so stark wächst der erste Ort.

== EDITS ==

1) Die Tempdb verwendet ein einfaches Wiederherstellungsmodell

2) Das Wachstum des Templogs erfolgt über ein paar Stunden am Morgen, wenn einige geplante Abfragen ausgeführt werden, im Grunde genommen eine Menge Berichte, die für den kommenden Tag außerhalb der Bürozeiten liegen. Die Größe der Datei wächst in dieser Zeit stetig. Wir steuern, wie viele gleichzeitige Berichte gleichzeitig ausgeführt werden. Durch Erhöhen der Anzahl gleichzeitiger Berichte wird die Geschwindigkeit erhöht, mit der das Protokoll wächst.

Überprüfen Sie Ihre Berichtsanfragen. Haben Sie welche, die DISTINCT enthalten? Hat einer von ihnen eine kartesische Verbindung?

Greifen alle Berichtsabfragen als Mitglieder eines Joins auf Verbindungsserver zu? In diesem Fall kann das Tempdb-Protokoll und die Datenbank wachsen.

Wenn die Berichte am Morgen laufen, stürzt einer von ihnen ab?

Wir hatten ein ähnliches Problem, nachdem wir einen PSS-Anruf bei Microsoft ausgelöst und das Problem eingehend untersucht hatten. Wir haben die folgende mögliche Ursache und Lösung untersucht.

Ursache:

Die wahrscheinliche Ursache für die Symptome sind Festplatten / Lun's, auf denen Benutzerdatenbanken abgelegt sind, mit schwerwiegenden E / A-Antwortproblemen. Dies führt dazu, dass der automatische Prüfpunkt in Benutzerdatenbanken sehr lange dauert.

Jetzt tritt der Prüfpunkt für Tempdb nur auf, wenn das Tempdb-Protokoll zu 70% voll ist und eine niedrigere Priorität als die Prüfpunkte der Benutzerdatenbank hat. Wenn also ein automatischer Prüfpunkt für Benutzerdatenbank (en) ausgegeben wird und versucht wird, ihn zu vervollständigen, wird die Tempdb-Protokolldatei aufgrund der starken Verwendung von Tempdb schnell voll. Bei einer Protokollnutzung von 70% tritt der temporäre Prüfpunkt auf, befindet sich jedoch hinter dem Prüfpunkt der Benutzerdatenbank in der Warteschlange.

In der Zeit, die der Benutzerdatenbankprüfpunkt benötigt, um die Tempdb-Protokolldatei fertigzustellen, wird sie immer voll, und wenn Autogrow eingestellt ist, wächst die Protokolldatei, wenn mehr Speicherplatz benötigt wird. Aus diesem Grund wächst die Protokolldatei weiter.

Zusammenfassend lässt sich sagen, dass die wahrscheinlichste Ursache für die von Ihnen beschriebenen Symptome in einer schlechten E / A-Reaktion der Festplatten / Lun für Ihre Benutzer- und / oder Tempdb-Datenbank- / Protokolldateien liegt.

Lösung:

Wir haben das Problem umgangen, während wir das E / A-Subsystem aussortiert haben, indem wir eine Warnung eingerichtet haben, die ausgelöst wurde, als die Tempdb-Protokolldatei zu 75% voll war, und als Reaktion darauf einen Job ausgeführt haben, der einen manuellen "CHECKPOINT" erzwang (der Vorrang vor dem automatischen System hat) Checkpoints), um das Tempdb-Protokoll zu löschen und zu verhindern, dass es auf unbestimmte Zeit automatisch wächst. Es ist immer noch eine gute Idee, die Protokolldatei für alle anderen Fälle automatisch wachsen zu lassen. Ich empfehle Ihnen außerdem dringend, die Größe der Tempdb-Protokolldatei nach dem Einfügen des Fixes auf eine für Ihre Umgebung sinnvolle Größe zu reduzieren.

Hoffe das hilft.

Auf was ist das Wiederherstellungsmodell in der temporären Datenbank eingestellt? Wenn es nicht auf Einfach gesetzt ist, setzen Sie es auf Einfach. Dies sollte verhindern, dass es wächst. Wenn es bereits auf Einfach eingestellt ist, würde ich sagen, dass ein zugrunde liegendes Problem behoben werden muss, und jeder Versuch, die Datei zu verkleinern, behandelt lediglich die Symptome des Problems und nicht die Grundursache.

Ich habe die letzten Stunden damit verbracht, dies zu lesen und mir Notizen zu machen

http://technet.microsoft.com/en-gb/library/cc966545.aspx

Es gibt viele Details und Vorschläge zur Fehlerbehebung. Es scheint, dass Ihre Tempdb, sofern sie nicht wächst und nie aufhört zu wachsen, wahrscheinlich nur den benötigten Speicherplatz beansprucht und ursprünglich auf diese Größe konfiguriert werden sollte. Es gibt einen Abschnitt zum Schätzen des für Ihre Tempdb erforderlichen Speicherplatzes sowie zum Aufspüren, was möglicherweise Speicherplatz in Tempdb beansprucht. Infolgedessen werde ich als erstes tempdb auf ein größeres Laufwerk verschieben und sehen, was von dort aus passiert.

Es gibt einen Abschnitt mit dem Titel "Für die Tempdb-Protokollierung erforderlicher Speicherplatz", der angibt, welche Features das Protokoll verwenden. In einem anderen früheren Abschnitt wird die Obermenge der Features beschrieben, die Tempdb verwenden.

Der Abschnitt mit dem Titel "Überwachung von E / A" enthält einige Ideen zu Leistungsindikatoren. Ein kurzer Blick auf meinen Server zeigt, dass Sie wahrscheinlich einen Engpass haben. Ich werde diese für eine Weile überwachen und sehen, wie sich die Dinge entwickeln. Die Tempdb-Protokolldatei war tatsächlich zu weniger als 50% ausgelastet, was zu der Idee passt, dass sie heute Morgen unter Last erweitert wurde und diesen Speicherplatz seitdem beibehalten hat.

Ich gehe davon aus, dass die Größe, auf die es gewachsen ist, der Größe entspricht, die es haben muss, überwache diese Größe in Zukunft und stelle sicher, dass auf jedem Laufwerk, auf dem es sich befindet, Raum für Wachstum vorhanden ist. Wie von einigen hier vorgeschlagen, werde ich untersuchen, was ausgeführt wird, wenn das temporäre Protokoll erweitert wird, und prüfen, ob dort etwas optimiert werden kann. Ich werde auch diese io-Leistungsindikatoren im Auge behalten, um zu sehen, ob etwas erledigt werden muss.

Es gab einen weiteren interessanten Abschnitt mit dem Titel "Upgrade auf SQL Server 2005", der darauf hinweist, dass Tempdb 2005 für mehr Dinge als 2000 verwendet wurde (sowohl neue Funktionen als auch vorhandene Funktionen, die zuvor kein Tempdb verwendeten). Ich habe erst kürzlich ein Upgrade auf 2005 durchgeführt, daher könnte dies ein Grund dafür sein, dass dies plötzlich zu einem Problem geworden ist. Ich kann mich nicht erinnern, dies irgendwo anders in Bezug auf ein Upgrade auf 2005 gesehen zu haben, was ein bisschen schmerzhaft ist.

Dies wird höchstwahrscheinlich durch eine außer Kontrolle geratene Cross Join-Abfrage verursacht. Am besten verwenden Sie Profiler, um es zu finden und dann zu reparieren.

Die andere Möglichkeit, dies zu finden, besteht darin, die Größe der TempDB-Protokolldatei einzuschränken und dann abzuwarten, welche Abfrage fehlschlägt. Ich würde jedoch wetten, dass es bereits fehlschlägt und niemand es Ihnen sagt.

Wenn Sie die SQL-Engine neu starten, wird die Datei auf die ursprüngliche Größe gesetzt. Sie sollten eine maximale Größe für alle Ihre Autogrow-Dateien festlegen.

Einige SQL-Abfragen oder gespeicherte Prozesse machen schlechte Dinge. Das einzige, was Sie tun können, ist, die Tempdb zu profilieren, um das Ereignis "Datenbank: Protokolldatei automatisch wachsen" abzufangen. Verwenden Sie in diesem Fall den Profiler und Abfragen für Tabellen wie sysprocesses, um sie zu finden heraus, was der schlechte Prozess ist.

Leider liegt es an der altmodischen Detektivarbeit, den Schurkenprozess zu verfolgen.

Haben Sie versucht, die Größe der Tempdb-Protokolldatei (en) mit DBCC SHRINKFILE () zu ändern? Wenn ja, wie lange dauert es, bis [sehr kleiner Wert] auf 45 GB oder mehr erreicht ist?