Thu hẹp Nhật ký giao dịch máy chủ SQL

Tôi hiện đang phải đối phó với nhật ký giao dịch SQL Server đã vượt khỏi tầm kiểm soát. Tuyên bố miễn trừ trách nhiệm: Tôi không phải là một dba và đây không phải là lĩnh vực chuyên môn của tôi vì vậy hãy đồng ý với tôi.

Hiện tại tôi có tệp nhật ký giao dịch 115GB cho cơ sở dữ liệu 500 MB (rõ ràng) được quản lý kém trong một thời gian để nó có được trạng thái này.

Ưu tiên hàng đầu là lấy lại không gian trên đĩa được lấy bởi tập tin này trước khi chúng tôi hết! Tôi đã được thông báo rằng việc tăng kích thước của ổ đĩa không phải là một lựa chọn, thậm chí là tạm thời và dựa trên sự tăng trưởng trong quá khứ, chúng ta cần phải hành động khá sớm.

Theo tôi hiểu, cách tiếp cận tốt nhất là giữ db ở chế độ khôi phục hoàn toàn nhưng thực hiện sao lưu thường xuyên tệp nhật ký, theo dõi điều này trong một khoảng thời gian và điều chỉnh kích thước ban đầu và gia tăng cho phù hợp. Tất cả ổn.

Thấy rằng chúng tôi thường xuyên sao lưu db đầy đủ vào nửa đêm, tôi có thể tạm thời đặt cơ sở dữ liệu vào Chế độ khôi phục đơn giản (sau khi một trong các bản sao lưu này chạy), thu nhỏ tệp nhật ký để lấy lại (hầu như tất cả) không gian và sau đó đưa nó trở lại Full Recovery với chiến lược sao lưu được đề cập ở trên?

Tôi nghĩ rằng nếu có gì đó xảy ra trong khoảng thời gian này, chúng ta có thể khôi phục lại toàn bộ bản sao lưu mà không cần sử dụng nhật ký.

CẬP NHẬT

Một vài chi tiết bổ sung để trả lời một số câu trả lời và bình luận:

• Chúng tôi muốn giữ lại khả năng thực hiện khôi phục tại thời điểm để cơ sở dữ liệu vẫn ở chế độ khôi phục hoàn toàn.

• Lý do mà tệp t-log đã phát triển quá lớn là vì nó chưa bao giờ được sao lưu . Được xác minh là log_Vuse_wait_desc trả về 'LOG_BACKUP'.

Nhật ký giao dịch cho cơ sở dữ liệu đó chứa tất cả các giao dịch kể từ lần sao lưu nhật ký giao dịch cuối cùng hoặc lần cuối cùng được chuyển từ chế độ khôi phục đơn giản. Thực hiện các thao tác sau để có câu trả lời dứt khoát về lý do tại sao SQL Server không thể cắt bớt nhật ký và sau đó là lý do tại sao nhật ký đang phát triển.

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

Nếu bạn muốn khôi phục kịp thời điểm thì hãy để DB trong mô hình khôi phục hoàn toàn và thực hiện sao lưu nhật ký thường xuyên. Mỗi bản sao lưu nhật ký sẽ chứa tất cả các giao dịch kể từ lần sao lưu nhật ký cuối cùng. Quá trình sao lưu nhật ký cũng chịu trách nhiệm xóa nhật ký và đánh dấu không gian để sử dụng lại, tức là giao dịch tiếp theo được thực hiện trong DB sẽ được ghi vào đầu nhật ký bị cắt theo kiểu vòng tròn. Sao lưu và tái sử dụng nhật ký này là những gì ngăn chặn tệp nhật ký phát triển.

Nếu bạn không quan tâm đến việc khôi phục kịp thời và muốn đơn giản hóa việc quản trị cơ sở dữ liệu. Sau đó đặt cơ sở dữ liệu thành mô hình khôi phục đơn giản và không thực hiện sao lưu t-log. SQL Server sẽ tự động cắt bớt nhật ký giao dịch sau mỗi giao dịch được cam kết. Có nghĩa là một khi giao dịch đã được cam kết với nhật ký, hồ sơ sẽ bị ghi đè bởi giao dịch tiếp theo, v.v.

Dù bằng cách nào, một khi bạn đã đưa ra một trong hai quyết định này, bạn có thể thu nhỏ tệp nhật ký xuống kích thước hợp lý hơn. Lưu ý lý tưởng là bạn muốn làm cho nó đủ lớn để nó không phát triển nhưng không lớn đến mức bạn sẽ cần phải thu nhỏ lại. Cũng lưu ý rằng bạn không thể thu nhỏ phần hoạt động của nhật ký.

Tải xuống và triển khai https://ola.hallengren.com/ giải pháp quản trị cơ sở dữ liệu để bao gồm các bản sao lưu, phân mảnh chỉ mục, thống kê và CHECKDB.

Bạn cũng có thể thấy báo cáo 'sử dụng đĩa' được trả về bằng cách nhấp chuột phải vào DB trong Object Explorer> Báo cáo> Báo cáo chuẩn> 'sử dụng đĩa' hữu ích để trả lại không gian trống trong nhật ký t.

Tôi cũng khuyên bạn nên Google tại sao điều quan trọng là giữ cho chuỗi nhật ký không bị ảnh hưởng từ quan điểm DR và ​​cách chuyển từ đầy đủ sang đơn giản phá vỡ chuỗi khiến bạn bị mất dữ liệu.

Thấy rằng chúng tôi thường xuyên sao lưu db đầy đủ vào nửa đêm, tôi có thể tạm thời đặt cơ sở dữ liệu vào Chế độ khôi phục đơn giản (sau khi một trong các bản sao lưu này chạy), thu nhỏ tệp nhật ký để lấy lại (hầu như tất cả) không gian và sau đó đưa nó trở lại Full Recovery với chiến lược sao lưu được đề cập ở trên?

Có, sẽ an toàn nếu bạn can thiệp vào không có giao dịch khi bạn thực hiện việc này, chẳng hạn như tải đêm muộn. Nói chung, nếu cơ sở dữ liệu phải ở chế độ khôi phục hoàn toàn, bạn muốn sao lưu T-Log thường xuyên. Điều này sẽ làm giảm vấn đề bạn gặp phải. Tôi viết "nói chung" bởi vì trong một số trường hợp, tôi đã thấy mọi người đặt cơ sở dữ liệu đầy đủ mà không biết lý do tại sao họ làm điều đó. Hãy giả sử đây không phải là trường hợp đó.

Tuy nhiên, bạn có thể muốn xem xét tại sao nhật ký có kích thước này so với kích thước cơ sở dữ liệu. Một cơ sở dữ liệu 500 MB với nhật ký 116 GB dường như không cân xứng cho một sự kiện một lần. Tôi sẽ đề nghị theo dõi những gì đang xảy ra trên cơ sở dữ liệu để xem làm thế nào nó đến kích thước đó ở nơi đầu tiên.