Câu trả lời:
Nó sẽ tự động cắt ngắn nhưng điều đó rất khác nhau để thu nhỏ. Cắt ngắn lấy lại không gian nhật ký để sử dụng lại, thu nhỏ về mặt vật lý làm giảm kích thước tệp để giải phóng không gian trở lại HĐH. Nếu nhật ký của bạn đã phát triển đến kích thước hiện tại thì có khả năng nó sẽ tăng trở lại nếu bạn thu nhỏ nó.
Tôi khuyên bạn nên nắm được cách sử dụng nhật ký tối đa và điển hình cho hệ thống của bạn. Truy vấn bên dưới (không phải của tôi, được tăng cường từ các tập lệnh DMV của Glen Berrys) có thể được chạy thủ công hoặc bạn có thể nắm bắt đầu ra tới một bảng thông qua một công việc đại lý. Nếu bạn đăng nhập nó vào một bảng trong một tuần hoặc lâu hơn, bạn sẽ có được một bức tranh về cách sử dụng thông thường và quan trọng hơn, khi một quá trình làm cho nhật ký phát triển vượt quá những gì bạn mong đợi.
SELECT
db.[name] AS [Database Name]
, db.recovery_model_desc AS [Recovery Model]
, db.log_reuse_wait_desc AS [Log Reuse Wait Description]
, ls.cntr_value AS [Log Size (KB)]
, lu.cntr_value AS [Log Used (KB)]
, CAST(
CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT)
AS DECIMAL(18,2)
) * 100 AS [Log Used %]
, db.[compatibility_level] AS [DB Compatibility Level]
, db.page_verify_option_desc AS [Page Verify Option]
, db.is_auto_create_stats_on, db.is_auto_update_stats_on
, db.is_auto_update_stats_async_on, db.is_parameterization_forced
, db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
INNER JOIN sys.dm_os_performance_counters AS lu
ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters AS ls
ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%'
AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
AND ls.cntr_value > 0
OPTION (RECOMPILE);
Cắt ngắn Nhật ký giao dịch mô tả cả thời điểm và lý do cắt ngắn nhật ký xảy ra.
Nếu các bản ghi nhật ký không bao giờ bị xóa khỏi nhật ký giao dịch, cuối cùng nó sẽ lấp đầy tất cả không gian đĩa có sẵn cho các tệp nhật ký vật lý. Nhật ký cắt ngắn tự động giải phóng không gian trong nhật ký logic để sử dụng lại bởi nhật ký giao dịch.
Các yếu tố có thể trì hoãn cắt ngắn nhật ký là một tài liệu tham khảo hữu ích để hiểu lý do tại sao nhật ký của bạn có thể không cắt bớt và do đó phát triển lớn hơn dự kiến.
Như đã đề cập trước đó, không nó sẽ không tự động thu nhỏ. Nó sẽ dọn sạch một số rác tuy nhiên.
Lý do là trong mô hình khôi phục đầy đủ, bạn đang nói với SQL rằng bạn muốn thực hiện sao lưu dự phòng để phục hồi kịp thời, do đó nó giữ một bản ghi về tất cả các giao dịch được thực hiện đối với cơ sở dữ liệu.
Vì bạn đang nói với nó rằng bạn muốn khôi phục kịp thời, bạn cần thực hiện sao lưu toàn bộ và sao lưu dự phòng. Khi bạn hoàn thành các bản sao lưu tlog của mình, nó sẽ xóa nội dung của nhật ký (bên cạnh phần đuôi) và bắt đầu lại.
Nó có thể hữu ích nếu bạn nghĩ về các tệp này như các thùng chứa.
Đề nghị của tôi là nếu các tlog đã trở nên lớn và không thể quản lý được, hãy cắt một bản sao lưu đầy đủ. Chuyển sang SIMPLE phục hồi mô hình và SHRINK file tlog. Chuyển về mô hình khôi phục hoàn toàn và thực hiện bảo trì phân mảnh *. Giống như những người khác đã đăng bài này không phải là thực tiễn tốt nhất và sẽ dẫn đến mức độ phân mảnh cao.
Lập kế hoạch và bắt đầu một chế độ sao lưu sau đó.
* Lập chỉ mục xây dựng lại / sắp xếp lại các hoạt động và phân mảnh cấp độ đĩa . Đây không phải là một phần của bảo trì nhật ký: Bạn duy trì Nhật ký T của mình bằng cách sao lưu chúng. Chúng là những container phát triển khi chúng gần đạt công suất. Xây dựng lại / sắp xếp lại có thể giúp phục hồi từ quản lý nhật ký không đúng cách dẫn đến việc sử dụng ổ đĩa lớn.