Warum wächst das Transaktionsprotokoll im einfachen Wiederherstellungsmodus mit nächtlichen Sicherungen weiter?

Bevor ich sofort als Duplikat markiere , habe ich Mike Walshs Warum wächst das Transaktionsprotokoll weiter oder es steht nicht mehr genügend Speicherplatz zur Verfügung? , aber ich glaube nicht, dass es eine Antwort auf meine Situation gab. Ich habe ein Dutzend ähnlicher Fragen durchgesehen, aber die relevanten Fragen haben meistens nur "Duplikat" gesagt und auf Mikes Frage hingewiesen.

Details: Ich habe eine Menge von ~ 500 MB Datenbanken auf SQL Server 2008 R2, alle im einfachen Wiederherstellungsmodus (nicht meine Wahl), nächtliche vollständige Sicherungen, mit ~ 200 MB Datendateien und ~ 300 MB Protokolldateien. Das Protokoll wächst nicht sofort auf 300 MB, sondern langsam im Laufe von ein paar Monaten. Es gibt keine offenen Transaktionen für eine von ihnen, zumindest gemäß sp_who2 und dem Aktivitätsmonitor. Wenn ich mit der rechten Maustaste auf die Datenbank klicke und Eigenschaften auswähle, wird mir mitgeteilt, dass ~ 50 MB frei sind. Sollte nicht gerade nach einer Sicherung das gesamte Protokoll frei sein? Sollte das Protokoll im SIMPLE-Modus nicht frei sein, solange keine Transaktion offen ist?

log_reuse_wait_descfrom sys.databasessays sagt "NOTHING", was auf der Basis der oben genannten Frage und Antwort besagt, dass es auf nichts warten sollte, um den Platz wiederzuverwenden.

Wenn ich 'DBCC SHRINKFILE' verwende, wird die Protokolldatei auf 1 MB verkleinert, sodass sie bereit ist, den Speicherplatz zurückzugewinnen. Ich kann etwas einrichten, das die Protokolle wöchentlich verkleinert und verhindert, dass Dinge außer Kontrolle geraten, aber ich bin verwirrt, warum SQL Server mich dazu zwingt, das zu tun.

Ich kann verstehen, ob es eine verrückte Transaktion gab, für deren Protokollierung 300 MB erforderlich waren, aber wir tun nichts Extremes, nur einfaches OLTP. Aus Mikes Frage / Antwort:

Einfaches Wiederherstellungsmodell - Mit der obigen Einführung ist es am einfachsten, zuerst über das einfache Wiederherstellungsmodell zu sprechen. In diesem Modell sagen Sie SQL Server: Es ist in Ordnung, wenn Sie Ihre Transaktionsprotokolldatei zum Absturz bringen und die Wiederherstellung neu starten (Sie haben dort wirklich keine Wahl. Suchen Sie nach den ACID-Eigenschaften, und das sollte schnell Sinn machen.) Benötigen Sie es länger für diesen Absturz- / Neustart-Wiederherstellungszweck, fahren Sie fort und verwenden Sie die Protokolldatei erneut.

SQL Server überwacht diese Anforderung in Simple Recovery und speichert nur die Informationen, die für die Wiederherstellung nach einem Absturz / Neustart erforderlich sind. Sobald SQL Server sicher ist, dass es wiederhergestellt werden kann, da die Daten in der Datendatei (mehr oder weniger) gesichert sind, sind die gesicherten Daten im Protokoll nicht mehr erforderlich und werden zum Abschneiden markiert. Dies bedeutet, dass sie wiederverwendet werden.

Es wird immer wieder gesagt, dass der Protokollspeicherplatz wiederverwendet werden sollte, aber angesichts dieses langsamen Wachstums im Laufe der Monate scheint es nicht so zu sein.

Was vermisse ich? Hält etwas SQL Server davon ab, die Daten als "gehärtet" zu erkennen und das Protokoll freizugeben?

(edit) Der After Action Report - AKA ein wenig Wissen ist gefährlich

Nachdem ich herausgefunden hatte, dass dies eine "populäre Frage" ist, hatte ich das Gefühl, eine Erklärung dafür zu haben, was vor sieben Monaten passiert ist und was ich gelernt habe, um einigen anderen Menschen hoffentlich Trauer zu ersparen.

Zunächst ist der in SSMS verfügbare Speicherplatz, wenn Sie die Eigenschaften einer Datenbank anzeigen, der in der Datendatei verfügbare Speicherplatz. Sie können dies anzeigen, indem Sie Folgendes in einer Datenbank ausführen. Der von SSMS gemeldete verfügbare Speicherplatz ist der Unterschied zwischen FileSizeMB und UsedSpaceMB:

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

Dies hat bestätigt, dass wir unter normalen Umständen sehr wenig Protokollspeicher (20 MB oder weniger) verwendet haben, aber dies führt zum zweiten Element ...

Zweitens war meine Wahrnehmung der wachsenden Protokolle die eines langsamen Verlaufs der Zeit. In Wirklichkeit wuchsen die Protokolle jedoch in den Nächten, in denen der für das Anwenden von Patches für diese Drittanbieteranwendung Verantwortliche Patches anwendete, rapide. Der Patch wurde als einzelne Transaktion ausgeführt. Je nach Patch benötigten die 200-MB-Daten 300 MB Protokoll. Der Schlüssel, um dies festzustellen, war die Anfrage von Aaron Bertrand unter https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

Dies zeigte, dass das Protokoll an bestimmten Abenden wuchs, wenn der Kunde die Datenbank nicht benutzte. Das führte zu einem Gespräch mit dem Typen, der die Patches anbrachte und die Antwort auf das Rätsel gab.

Nochmals vielen Dank für Leute, die mir geholfen haben, die Antwort zu finden.

Es ist für uns unmöglich zu erraten, was es verursacht, aber SQL Server vergrößert nicht nur eine Protokolldatei auf 300 MB, sondern auch auf 300 MB, da dies irgendwann seit Ihrem letzten Verkleinerungsvorgang erforderlich war viel Speicherplatz (egal ob aufgrund einer großen Einzeltransaktion oder vieler kleinerer gleichzeitiger Transaktionen). Sie müssen das Wachstum von Protokolldateien nachverfolgen (ich habe hier und hier darüber gesprochen ), um einzugrenzen, wann oder warum dies geschieht (auch wenn die Einstellung für das Wachstum von Protokolldateien 300 MB oder etwas beträgt, wird sie um 300 MB zunehmen sobald es mehr als 1 MB Speicherplatz für aktive Transaktionen benötigt).

Warum sollten Sie die Protokolldatei nach Erreichen von 300 MB verkleinern? Haben Sie tatsächlich alle Antworten auf Mikes Frage gründlich gelesen ? Die Protokolldatei wird NICHT von selbst verkleinert, da das Verkleinern der Protokolldatei auf 1 MB - nur damit sie bei Ihren größten Transaktionen wieder wachsen kann - eine reine Zeitverschwendung ist. Was machen Sie in der Zwischenzeit mit all dem freien Speicherplatz?

Alle aktuellen Tests ( DBCC SHRINKFILE, log_reuse_wait_desc) erweisen sich einfach , dass gerade jetzt wiederverwenden Sie die geeignete virtuelle Protokolldateien des Transaktionsprotokolls. Wenn Ihre automatischen Wachstumsereignisse jedoch in Ihrer Transaktionsprotokolldatei auftreten, ist dies eine Reaktion darauf, dass das Protokoll nicht wiederverwendet werden kann.

Oft ist dies kein andauernder Zustand (genau so, wie es Ihnen gerade vorkommt, wenn Sie gerade keine Symptome bemerken). Es gibt eine Handvoll Dinge, die dieses Verhalten verursachen können, selbst im einfachen Wiederherstellungsmodell.

Am besten richten Sie einen Datenerfassungsjob ein, um routinemäßig die Daten log_reuse_wait_descfür Ihre Datenbank abzurufen und diese routinemäßig irgendwo zu protokollieren. Dann sollten Sie in der Lage sein, die Ursache für die fehlende Wiederverwendung von Protokollen zurückzuentwickeln.

Es wird immer wieder gesagt, dass der Protokollspeicherplatz wiederverwendet werden sollte, aber angesichts dieses langsamen Wachstums im Laufe der Monate scheint es nicht so zu sein.

Wie ich oben erwähnte, ist es nicht in der Regel eine laufende Bedingung , dass das Fehlen von Transaktionsprotokoll Wiederverwendung verursacht (save ein paar Sonderfälle, wie schlecht konstruiert Transaktionen), so würde man die Zeiten genau feststellen müssen, wenn dies ist passiert. Die leichte Diagnosedatensammlung sollte ein guter Anfang sein.

Haben Sie die automatische Verkleinerung für die DBs aktiviert? Und / oder haben Sie geplante Wartungspläne für die Indexwiederherstellung?

Eine automatische Verkleinerung, gefolgt von einer Indexpflege, erzeugt ein signifikantes Protokollvolumen.

Die Indexwartung allein führt auch zu einem signifikanten Protokollvolumen, wenn DB-Entwurfsprobleme wie Clustered-Indizes für GUIDs auftreten.

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog