Tại sao nhật ký giao dịch tiếp tục phát triển trong chế độ khôi phục đơn giản với các bản sao lưu hàng đêm

Trước khi ngay lập tức đánh dấu là trùng lặp , tôi đã đọc Mike Walsh Tại sao Nhật ký giao dịch tiếp tục phát triển hoặc hết dung lượng? , nhưng tôi không nghĩ rằng nó đã đưa ra câu trả lời cho tình huống của tôi. Tôi đã xem qua hàng tá câu hỏi tương tự, nhưng những câu hỏi liên quan chủ yếu chỉ nói "trùng lặp" và chỉ vào câu hỏi của Mike.

Chi tiết: Tôi có một loạt cơ sở dữ liệu ~ 500MB trên SQL Server 2008 R2, tất cả đều ở chế độ khôi phục SIMPLE (không phải lựa chọn của tôi), sao lưu toàn bộ hàng đêm, với ~ 200 MB tệp dữ liệu và ~ 300 MB tệp nhật ký. Nhật ký không tăng lên 300 MB ngay lập tức, nhưng khá chậm trong vài tháng. Không có giao dịch mở trên bất kỳ trong số chúng, ít nhất là theo sp_who2 và giám sát hoạt động. Nếu tôi nhấp chuột phải vào cơ sở dữ liệu và chọn thuộc tính, nó sẽ cho tôi biết có ~ 50 MB miễn phí. Đặc biệt ngay sau khi sao lưu, toàn bộ nhật ký có nên miễn phí không? Trong chế độ SIMPLE không nên đăng nhập miễn phí miễn là không có giao dịch mở?

log_reuse_wait_desctừ sys.databasesnói "KHÔNG CÓ", dựa trên câu hỏi và câu trả lời được tham chiếu ở trên nói rằng không nên chờ đợi bất cứ điều gì để sử dụng lại không gian.

Nếu tôi thực hiện 'DBCC SHRINKFILE', tệp nhật ký co lại thành 1MB, do đó, nó sẵn sàng lấy lại dung lượng. Tôi có thể thiết lập một cái gì đó thu nhỏ nhật ký hàng tuần và giữ mọi thứ khỏi tầm kiểm soát, nhưng tôi bối rối không biết tại sao SQL Server lại bắt tôi làm điều đó.

Tôi có thể hiểu nếu có một số giao dịch điên rồ cần 300 MB để đăng nhập nó, nhưng chúng tôi không làm gì cực đoan, chỉ là OLTP cơ bản. Từ câu hỏi / câu trả lời của Mike:

Mô hình phục hồi đơn giản - Vì vậy, với phần giới thiệu ở trên, trước tiên, dễ dàng nhất để nói về mô hình Phục hồi đơn giản. Trong mô hình này, bạn đang nói với SQL Server - Tôi ổn với bạn khi sử dụng tệp nhật ký giao dịch của bạn để khắc phục sự cố và khởi động lại phục hồi (Bạn thực sự không có lựa chọn nào ở đó .. Tra cứu các thuộc tính ACID và điều đó sẽ nhanh chóng có ý nghĩa), nhưng một khi bạn không còn cần nó cho mục đích khôi phục sự cố / khởi động lại, tiếp tục và sử dụng lại tệp nhật ký.

SQL Server lắng nghe yêu cầu này trong Phục hồi đơn giản và nó chỉ giữ thông tin cần thiết để thực hiện khôi phục sự cố / khởi động lại. Khi SQL Server chắc chắn có thể khôi phục được vì dữ liệu được làm cứng vào tệp dữ liệu (ít nhiều), dữ liệu đã được làm cứng không còn cần thiết trong nhật ký và được đánh dấu để cắt bớt - có nghĩa là nó được sử dụng lại.

Nó tiếp tục nói rằng không gian nhật ký nên được sử dụng lại, nhưng với tốc độ tăng trưởng chậm này trong nhiều tháng, có vẻ như không phải vậy.

Tôi đang thiếu gì? Có điều gì đó khiến SQL Server không nhận ra dữ liệu là "cứng" và giải phóng nhật ký không?

(chỉnh sửa) Báo cáo hành động sau - AKA một chút kiến ​​thức là nguy hiểm

Sau khi nhận thấy đây là một "câu hỏi phổ biến", tôi cảm thấy như mình nợ một lời giải thích về những gì đã xảy ra 7 tháng trước và những gì tôi học được để hy vọng cứu một số người khác một số đau buồn.

Trước hết, không gian có sẵn mà bạn thấy trong SSMS khi bạn xem các thuộc tính trên cơ sở dữ liệu là không gian có sẵn trong tệp dữ liệu. Bạn có thể xem điều này bằng cách chạy các mục sau trên cơ sở dữ liệu và bạn sẽ thấy không gian có sẵn được báo cáo bởi SSMS là sự khác biệt giữa FileSizeMB và 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'

Điều này đã xác nhận rằng trong các trường hợp thông thường, chúng tôi đã sử dụng rất ít không gian nhật ký (20MB trở xuống), nhưng điều này dẫn đến mục thứ hai ...

Thứ hai, nhận thức của tôi về các bản ghi đang phát triển là từ từ theo thời gian. Tuy nhiên, trên thực tế, nhật ký phát triển nhanh chóng vào những đêm anh chàng chịu trách nhiệm áp dụng các bản vá cho ứng dụng bên thứ 3 này đang áp dụng các bản vá. Bản vá được thực hiện dưới dạng một giao dịch, do đó tùy thuộc vào bản vá, dữ liệu 200MB cần 300 MB nhật ký. Chìa khóa trong việc theo dõi đó là truy vấn của Aaron Bertrand tại 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;

Điều này cho thấy rằng nhật ký đã tăng lên vào một số buổi tối nhất định, khi khách hàng không sử dụng cơ sở dữ liệu. Điều đó dẫn đến cuộc trò chuyện với anh chàng áp dụng các bản vá và câu trả lời cho bí ẩn.

Cảm ơn một lần nữa cho những người đã giúp đỡ để đưa tôi đến câu trả lời.

Chúng tôi không thể đoán được nguyên nhân gây ra nó, nhưng SQL Server không chỉ tăng một tệp nhật ký lên 300 MB, nó tăng lên 300 MB bởi vì tại một số điểm kể từ hoạt động thu nhỏ cuối cùng của bạn, nó cần điều đó nhiều không gian đăng nhập (cho dù do một số giao dịch lớn hoặc nhiều giao dịch đồng thời nhỏ hơn). Bạn phải theo dõi các sự kiện tăng trưởng tệp nhật ký (tôi đã nói về vấn đề này ở đây và ở đây ) để thử và thu hẹp khi nào hoặc tại sao điều này xảy ra (cũng như nếu bạn đăng nhập cài đặt tăng trưởng tệp là 300 MB hoặc thứ gì đó, thì nó sẽ tăng thêm 300 MB ngay khi nó cần nhiều hơn 1 MB dung lượng để chứa các giao dịch đang hoạt động).

Dù sao, tại sao bạn nghĩ rằng bạn cần phải thu nhỏ tệp nhật ký khi nó đã đạt tới 300 MB? Bạn đã thực sự đọc tất cả các câu trả lời, một cách kỹ lưỡng, về câu hỏi của Mike ? Tệp nhật ký KHÔNG tự thu nhỏ lại, vì thu nhỏ tệp nhật ký thành 1MB - chỉ để nó có thể phát triển lại trong các giao dịch lớn nhất của bạn - là một sự lãng phí toàn bộ thời gian. Trong lúc này, bạn sẽ làm gì với tất cả không gian trống đó?

Tất cả các thử nghiệm hiện tại của bạn ( DBCC SHRINKFILE, log_reuse_wait_desc) chỉ đơn giản là chứng minh rằng ngay bây giờ bạn đang sử dụng lại các tệp nhật ký ảo của nhật ký giao dịch một cách thích hợp. Nhưng khi các sự kiện tăng trưởng tự động của bạn xảy ra trên tệp nhật ký giao dịch của bạn, đó là một phản ứng đối với nhật ký không thể được sử dụng lại.

Thông thường, đó không phải là một tình trạng đang diễn ra (chính xác là nó dường như đối với bạn ngay bây giờ với việc thiếu các triệu chứng mà bạn hiện đang thấy). Có một số điều có thể gây ra hành vi này, ngay cả trong mô hình khôi phục đơn giản.

Đặt cược tốt nhất của bạn sẽ là thiết lập một công việc thu thập dữ liệu để thường xuyên lấy log_reuse_wait_desccơ sở dữ liệu của bạn và thường xuyên đăng nhập cái này ở đâu đó. Sau đó, bạn sẽ có thể đảo ngược kỹ sư những gì gây ra việc thiếu sử dụng lại nhật ký.

Nó tiếp tục nói rằng không gian nhật ký nên được sử dụng lại, nhưng với tốc độ tăng trưởng chậm này trong nhiều tháng, có vẻ như không phải vậy.

Như tôi đã trình bày ở trên, nó không phải là thường là một điều kiện liên tục gây ra sự thiếu tái sử dụng nhật ký giao dịch (tiết kiệm một vài trường hợp góc, như giao dịch kém xây dựng), vì vậy bạn phải xác định thời gian khi điều này được xảy ra. Việc thu thập dữ liệu chẩn đoán nhẹ nên là một khởi đầu tốt.

Bạn có tự động thu nhỏ kích hoạt trên DB không? Và / hoặc bạn có kế hoạch bảo trì theo lịch trình thực hiện xây dựng lại chỉ mục?

Tự động thu nhỏ theo sau là bảo trì chỉ mục sẽ tạo ra khối lượng nhật ký đáng kể.

Bản thân việc bảo trì chỉ mục cũng sẽ tạo ra khối lượng nhật ký đáng kể, nếu có các vấn đề về thiết kế DB như các chỉ mục được nhóm trên GUID.

 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