Không gian đăng nhập TempDB và ACTIVE_TRANSACTION


7

Giải pháp giám sát của chúng tôi (SCOM) hiện đang gắn cờ rằng nhật ký tempdb sắp hết dung lượng. Tuy nhiên, chúng tôi đã tự động phát triển thành 1 GB cho nhật ký và chúng tôi còn 25 GB dung lượng trên ổ đĩa.

Tôi nhìn vào những gì log_reuse_wait_descđã được và thấy nó làACTIVE_TRANSACTION

Tôi bắt đầu tự hỏi liệu vì lý do nào đó, tệp nhật ký đã được lấp đầy và tự động phát triển không khởi động, và sau một số nghiên cứu tôi thấy rằng tệp nhật ký vẫn sẽ phát triển ngay cả trong khi ACTIVE_TRANSACTION.

Tôi đã tìm thấy một bài viết về một vấn đề tương tự trong đó nhật ký tempdb hết dung lượng:

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

Ở đây họ đã ban hành một CHECKPOINTđể giải quyết vấn đề trên tempdb. Tôi biết một CHECKPOINTtrang bẩn thỉu vào đĩa, tuy nhiên tôi không hiểu làm thế nào điều này sẽ khắc phục ACTIVE_TRANSACTIONvấn đề?

Hơn nữa, tôi cũng không biết tại sao chúng ta lại nhận được cảnh báo này khi có nhiều không gian. Có một tình huống mà một tempdbcó thể điền và tự động phát triển không hoạt động vì một số lý do?


Công cụ giám sát SCOM kiểm tra giá trị ngưỡng được đặt để cảnh báo trong trường hợp không gian đĩa và trong trường hợp của bạn, tôi đoán ngưỡng được đặt ở đâu đó khoảng 30-25 G, nó đã bị vượt qua để cảnh báo được kích hoạt
Shanky

@Tom Blog bạn đề cập ở trên là blog của tôi . Hy vọng nó hữu ích để giải quyết vấn đề của bạn.
ToC

Câu trả lời:


3

Như Max đã đề cập, cảnh báo có thể được kích hoạt ngay trước khi nhật ký tăng / cần phát triển. SCOM thu thập không gian trống nhật ký giao dịch% mặc dù tôi không chắc cảnh báo sẽ phát ở ngưỡng nào.

đây là một ví dụ nhanh để cho bạn thấy tempdb trạng thái nào có thể có khi bạn nhận được các cảnh báo này nhưng không phát triển tệp nhật ký.

đầu tiên tạo cơ sở dữ liệu, đặt recovery thành đầy đủ và sao lưu nó

    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

bây giờ chuyển sang cơ sở dữ liệu đó, tạo một bảng và chạy DBCC sqlperf (logspace) để kiểm tra kích thước và không gian trống trong tệp nhật ký của bạn.

use tlogspace
go

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

Trên hệ thống của tôi, tôi có kích thước logfile là 0,9921875 và không gian nhật ký được sử dụng (%) là 48,4245. Bây giờ chèn một số dữ liệu vào bảng và chạy DBCC sqlperf (logspace) một lần nữa. Trên hệ thống của tôi, 45 hàng được chèn cho kết quả mong muốn (số lượng hàng được chèn có thể cần được điều chỉnh).

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

Lần này, đầu ra sqlperf của DBCC sẽ hiển thị rằng kích thước nhật ký là như nhau nhưng không gian nhật ký được sử dụng chỉ dưới 100%. Trong trường hợp này, SCOM có thể sẽ đưa ra một cảnh báo rằng không gian đăng nhập thấp. Không có thêm hoạt động nào xảy ra để làm cho tệp nhật ký phát triển và (trong ví dụ này) không có bản sao lưu tlog để giải phóng không gian sử dụng. tempdb đang trong quá trình khôi phục đơn giản, vì vậy giao dịch hoạt động của bạn có thể đã sử dụng hầu hết dung lượng có sẵn và không giải phóng nó nhưng không có đủ hoạt động trong tempdb để kích hoạt tăng trưởng tệp nhật ký, do đó gây ra cảnh báo cháy.

dọn dẹp cơ sở dữ liệu khi hoàn thành

use master
drop database tlogspace

0

Điều này không trả lời câu hỏi của bạn, tuy nhiên tôi nghĩ bạn có thể thấy hữu ích để xem liệu có bất kỳ sự tăng trưởng nhật ký nào gần đây không:

/*
    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
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.