it-swarm.com.de

TempDB Log Space und ACTIVE_TRANSACTION

Unsere Überwachungslösung (SCOM) weist derzeit darauf hin, dass im temporären Protokoll nicht genügend Speicherplatz vorhanden ist. Wir haben jedoch die automatische Vergrößerung für das Protokoll auf 1 GB festgelegt, und wir haben noch 25 GB Speicherplatz auf dem Laufwerk.

Ich habe mir angesehen, was der log_reuse_wait_desc War und fand, dass es ACTIVE_TRANSACTION Ist.

Ich begann mich zu fragen, ob sich die Protokolldatei aus irgendeinem Grund füllte und das automatische Wachstum nicht einsetzte, und nach einigen Recherchen stellte ich fest, dass die Protokolldatei auch während eines ACTIVE_TRANSACTION Noch wachsen sollte.

Ich habe einen Artikel zu ähnlichen Problemen gefunden, bei dem das Tempdb-Protokoll nicht mehr über genügend Speicherplatz verfügt:

http://sqltimes.wordpress.com/2014/07/05/sql-server-error-messages-the-transaction-log-for-database-tempdb-is-full-due-to-active_transaction/

Hier haben sie ein CHECKPOINT ausgegeben, um das Problem auf tempdb zu beheben. Ich weiß, dass ein CHECKPOINT schmutzige Seiten auf die Festplatte löscht, aber ich verstehe nicht, wie dies das Problem ACTIVE_TRANSACTION Beheben würde?

Außerdem weiß ich auch nicht, warum wir diese Warnung erhalten, wenn viel Platz vorhanden ist. Gibt es eine Situation, in der ein tempdb gefüllt werden kann und das automatische Wachstum aus irgendeinem Grund nicht funktioniert?

7
Tom

Wie Max erwähnte, wurde die Warnung wahrscheinlich kurz vor dem Wachsen des Protokolls ausgelöst. SCOM sammelt den freien Speicherplatz für das Transaktionsprotokoll%, obwohl ich nicht sicher bin, bei welchem ​​Schwellenwert die Warnung ausgelöst wird.

hier ist ein kurzes Beispiel, um Ihnen zu zeigen, in welchem ​​Zustand sich Tempdb wahrscheinlich befindet, wenn Sie diese Warnungen erhalten, aber kein Wachstum der Protokolldatei.

erstellen Sie zunächst eine Datenbank, setzen Sie die Wiederherstellung auf "Vollständig" und sichern Sie sie

    create database tlogspace
    on(name=tlogspace_dat,
        filename='c:\temp\tlogspace.mdf',
        size=4MB)
    log on (name=tlogspace_log,
        filename='c:\temp\tlogspace.ldf',
        size=1MB);
    go

    alter database tlogspace set recovery full;
    go
    backup database tlogspace to disk='nul';
    go

wechseln Sie nun zu dieser Datenbank, erstellen Sie eine Tabelle und führen Sie DBCC sqlperf (logspace) aus, um die Größe und den freien Speicherplatz in Ihrer Protokolldatei zu überprüfen.

use tlogspace
go

create table data(id int identity(1,1), col varchar(8000))
dbcc sqlperf(logspace)

Auf meinem System habe ich eine Protokolldateigröße von 0,9921875 und einen verwendeten Protokollspeicherplatz (%) von 48,4245. Fügen Sie nun einige Daten in die Tabelle ein und führen Sie DBCC sqlperf (logspace) erneut aus. Auf meinem System ergaben 45 eingefügte Zeilen die gewünschten Ergebnisse (die Anzahl der eingefügten Zeilen muss möglicherweise angepasst werden).

insert into data(col)
select replicate('a',8000)
go 45 --may need to adjust number
dbcc sqlperf(logspace)

Diesmal sollte die DBCC-Ausgabe von sqlperf anzeigen, dass die Protokollgröße gleich ist, der verwendete Protokollspeicher jedoch knapp 100% beträgt. In diesem Fall würde SCOM wahrscheinlich eine Warnung auslösen, dass der Protokollspeicherplatz niedrig ist. Es gibt keine weiteren Aktivitäten, die dazu führen, dass die Protokolldatei wächst, und (in diesem Beispiel) keine Tlog-Sicherung, um den verwendeten Speicherplatz freizugeben. tempdb befindet sich in einer einfachen Wiederherstellung, sodass Ihre aktive Transaktion wahrscheinlich den größten Teil des verfügbaren Speicherplatzes verbraucht und nicht freigegeben hat, aber in tempdb nicht genügend Aktivität vorhanden war, um das Wachstum von Protokolldateien auszulösen, wodurch der Alarm ausgelöst wurde.

bereinigungsdatenbank nach Abschluss

use master
drop database tlogspace
3
Bob Klimes

Dies beantwortet Ihre Frage nicht, aber ich dachte, Sie könnten es hilfreich finden, um festzustellen, ob es in letzter Zeit zu einem Protokollwachstum gekommen ist:

/*
    Description:    display growth events for all databases on the instance
    by:             Max Vernon
    date:           2014-10-01
*/
DECLARE @Version NVARCHAR(255);
DECLARE @VersionINT INT;
SET @Version = CONVERT(NVARCHAR(255),SERVERPROPERTY('ProductVersion'));
SET @VersionINT = CONVERT(INT, SUBSTRING(@Version,1 ,CHARINDEX('.',@Version)-1));
DECLARE @cmd NVARCHAR(2000);
SET @cmd = '';
IF @VersionINT >= 9
BEGIN
    SET @cmd = 
'
DECLARE @trcfilename VARCHAR(1000);

SELECT @trcfilename = path 
FROM sys.traces 
WHERE is_default = 1;

IF COALESCE(@trcfilename,'''') <> ''''
BEGIN
SELECT
    '''''''' + @@SERVERNAME + '''''','''''' +
     DB_NAME(mf.database_id) + '''''','''''' +
     mf.name + '''''','' +
     CONVERT(VARCHAR(255), a.NumberOfGrowths) + '','' +
     CONVERT(VARCHAR(255), CAST(a.DurationOfGrowthsInSeconds AS decimal(38, 20)))
    FROM
    (
        SELECT
            tt.DatabaseID AS database_id,
            tt.FileName AS LogicalFileName,
            COUNT(*) AS NumberOfGrowths,
            SUM(tt.Duration / (1000 * 1000.0)) AS DurationOfGrowthsInSeconds
            FROM sys.fn_trace_gettable(@trcfilename, default) tt
            WHERE (EventClass IN (92, 93))
            GROUP BY
                tt.DatabaseID,
                tt.FileName
    ) a
    INNER JOIN sys.master_files mf ON
        (mf.database_id = a.database_id) AND
        (mf.name = a.LogicalFileName);
END
ELSE
BEGIN
    SELECT @@SERVERNAME, ''NO TRACE FILE'';
END
';
EXEC sp_executesql @cmd;
END
ELSE
BEGIN
    SELECT @@SERVERNAME, SERVERPROPERTY('ProductVersion');
END
0
Max Vernon