Làm cho một tệp nhật ký nhỏ hơn thực sự nên được dành riêng cho các tình huống mà nó gặp phải sự tăng trưởng bất ngờ mà bạn không mong muốn xảy ra lần nữa. Nếu tệp nhật ký sẽ phát triển trở lại cùng kích thước, thì sẽ không thực hiện được nhiều bằng cách thu nhỏ tạm thời. Bây giờ, tùy thuộc vào mục tiêu khôi phục cơ sở dữ liệu của bạn, đây là những hành động bạn nên thực hiện.
Đầu tiên, hãy sao lưu toàn bộ
Không bao giờ thực hiện bất kỳ thay đổi nào đối với cơ sở dữ liệu của bạn mà không đảm bảo bạn có thể khôi phục nó nếu có sự cố.
Nếu bạn quan tâm đến việc phục hồi tại thời điểm
(Và bằng cách khôi phục tại thời điểm, ý tôi là bạn quan tâm đến việc có thể khôi phục lại bất cứ thứ gì ngoài bản sao lưu đầy đủ hoặc khác biệt.)
Có lẽ cơ sở dữ liệu của bạn đang ở FULLchế độ phục hồi. Nếu không, hãy chắc chắn rằng nó là:
ALTER DATABASE testdb SET RECOVERY FULL;
Ngay cả khi bạn đang thực hiện sao lưu toàn bộ thường xuyên, tệp nhật ký sẽ phát triển và phát triển cho đến khi bạn thực hiện sao lưu nhật ký - đây là để bảo vệ bạn, không cần phải ăn mất không gian đĩa. Bạn nên thực hiện các bản sao lưu nhật ký này khá thường xuyên, theo mục tiêu phục hồi của bạn. Ví dụ: nếu bạn có một quy tắc kinh doanh nói rằng bạn có thể đủ khả năng để mất không quá 15 phút dữ liệu trong trường hợp xảy ra thảm họa, bạn nên có một công việc sao lưu nhật ký cứ sau 15 phút. Đây là một tập lệnh sẽ tạo các tên tệp được đánh dấu thời gian dựa trên thời gian hiện tại (nhưng bạn cũng có thể thực hiện việc này với các kế hoạch bảo trì, v.v., đừng chọn bất kỳ tùy chọn thu nhỏ nào trong các kế hoạch bảo trì, chúng thật tồi tệ).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
Lưu ý rằng \\backup_share\phải ở trên một máy khác đại diện cho một thiết bị lưu trữ bên dưới khác. Sao lưu chúng vào cùng một máy (hoặc cho một máy khác sử dụng cùng một đĩa bên dưới hoặc một VM khác trên cùng một máy chủ vật lý) không thực sự giúp bạn, vì nếu máy nổ, bạn đã mất cơ sở dữ liệu của mình và bản sao lưu của nó. Tùy thuộc vào cơ sở hạ tầng mạng của bạn, có thể có ý nghĩa hơn để sao lưu cục bộ và sau đó chuyển chúng đến một vị trí khác phía sau hậu trường; trong cả hai trường hợp, bạn muốn đưa chúng ra khỏi máy cơ sở dữ liệu chính càng nhanh càng tốt.
Bây giờ, một khi bạn có các bản sao lưu nhật ký thường xuyên đang chạy, sẽ rất hợp lý khi thu nhỏ tệp nhật ký thành một cái gì đó hợp lý hơn bất cứ thứ gì nó được thổi cho đến bây giờ. Điều này không có nghĩa là chạy đi chạy SHRINKFILElại cho đến khi tệp nhật ký là 1 MB - ngay cả khi bạn thường xuyên sao lưu nhật ký, nó vẫn cần điều chỉnh tổng của bất kỳ giao dịch đồng thời nào có thể xảy ra. Các sự kiện autogrow tệp nhật ký rất tốn kém, vì SQL Server phải loại bỏ các tệp (không giống như các tệp dữ liệu khi bật khởi tạo tệp tức thời) và các giao dịch của người dùng phải chờ trong khi điều này xảy ra. Bạn muốn thực hiện thói quen tăng-giảm-tăng-thu nhỏ này càng ít càng tốt và bạn chắc chắn không muốn làm cho người dùng của mình trả tiền cho nó.
Lưu ý rằng bạn có thể cần sao lưu nhật ký hai lần trước khi có thể thu nhỏ (cảm ơn Robert).
Vì vậy, bạn cần phải đưa ra một kích thước thực tế cho tệp nhật ký của bạn. Không ai ở đây có thể cho bạn biết đó là gì mà không biết nhiều về hệ thống của bạn, nhưng nếu bạn thường xuyên thu hẹp tệp nhật ký và nó đã phát triển trở lại, một hình mờ tốt có thể cao hơn 10-50% so với lớn nhất . Giả sử có tới 200 MB và bạn muốn bất kỳ sự kiện tự động phát sinh tiếp theo nào là 50 MB, thì bạn có thể điều chỉnh kích thước tệp nhật ký theo cách này:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
Lưu ý rằng nếu tệp nhật ký hiện tại> 200 MB, bạn có thể cần chạy tệp này trước:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Nếu bạn không quan tâm đến việc phục hồi tại thời điểm
Nếu đây là cơ sở dữ liệu kiểm tra và bạn không quan tâm đến việc khôi phục tại thời điểm, thì bạn nên đảm bảo rằng cơ sở dữ liệu của mình đang ở SIMPLEchế độ khôi phục.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Đặt cơ sở dữ liệu vào SIMPLEchế độ khôi phục sẽ đảm bảo rằng SQL Server sử dụng lại các phần của tệp nhật ký (về cơ bản loại bỏ các giao dịch không hoạt động) thay vì phát triển để giữ một bản ghi của tất cả các giao dịch (như FULLphục hồi cho đến khi bạn sao lưu nhật ký). CHECKPOINTcác sự kiện sẽ giúp kiểm soát nhật ký và đảm bảo rằng nó không cần phát triển trừ khi bạn tạo ra nhiều hoạt động t-log giữa CHECKPOINTcác s.
Tiếp theo, bạn nên chắc chắn tuyệt đối rằng sự tăng trưởng nhật ký này thực sự là do một sự kiện bất thường (giả sử, làm sạch mùa xuân hàng năm hoặc xây dựng lại các chỉ số lớn nhất của bạn), và không phải do sử dụng hàng ngày, bình thường. Nếu bạn thu nhỏ tệp nhật ký thành kích thước nhỏ một cách lố bịch và SQL Server chỉ cần phát triển lại để phù hợp với hoạt động bình thường của bạn, bạn đã đạt được gì? Bạn có thể sử dụng không gian đĩa mà bạn đã giải phóng tạm thời không? Nếu bạn cần khắc phục ngay lập tức, thì bạn có thể chạy như sau:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
Nếu không, thiết lập một kích thước phù hợp và tốc độ tăng trưởng. Theo ví dụ trong trường hợp khôi phục tại thời điểm, bạn có thể sử dụng cùng mã và logic để xác định kích thước tệp nào là phù hợp và đặt tham số tự động hợp lý.
Một số điều bạn không muốn làm
Sao lưu nhật ký với TRUNCATE_ONLYtùy chọn và sau đóSHRINKFILE . Đối với một, TRUNCATE_ONLYtùy chọn này đã không được chấp nhận và không còn có sẵn trong các phiên bản hiện tại của SQL Server. Thứ hai, nếu bạn đang ở trong FULLmô hình khôi phục, điều này sẽ phá hủy chuỗi nhật ký của bạn và yêu cầu một bản sao lưu mới, đầy đủ.
Tháo cơ sở dữ liệu, xóa tệp nhật ký và đính kèm lại . Tôi không thể nhấn mạnh mức độ nguy hiểm của nó. Cơ sở dữ liệu của bạn có thể không sao lưu, nó có thể xuất hiện dưới dạng nghi ngờ, bạn có thể phải quay lại bản sao lưu (nếu bạn có), v.v.
Sử dụng tùy chọn "thu nhỏ cơ sở dữ liệu" . DBCC SHRINKDATABASEvà tùy chọn kế hoạch bảo trì để làm tương tự là những ý tưởng tồi, đặc biệt nếu bạn thực sự chỉ cần giải quyết vấn đề về nhật ký. Nhắm mục tiêu tệp bạn muốn điều chỉnh và điều chỉnh độc lập, sử dụng DBCC SHRINKFILEhoặc ALTER DATABASE ... MODIFY FILE(ví dụ ở trên).
Thu nhỏ tệp nhật ký thành 1 MB . Điều này có vẻ hấp dẫn bởi vì, hey, SQL Server sẽ cho phép tôi làm điều đó trong các tình huống nhất định và xem xét tất cả không gian mà nó giải phóng! Trừ khi cơ sở dữ liệu của bạn chỉ được đọc (và đó là, bạn nên đánh dấu nó như vậy bằng cách sử dụng ALTER DATABASE), điều này hoàn toàn sẽ dẫn đến nhiều sự kiện tăng trưởng không cần thiết, vì nhật ký phải điều chỉnh các giao dịch hiện tại bất kể mô hình khôi phục. Điểm giải phóng không gian đó tạm thời là gì, để SQL Server có thể lấy lại từ từ và đau đớn?
Tạo một tệp nhật ký thứ hai . Điều này sẽ cung cấp cứu trợ tạm thời cho ổ đĩa đã lấp đầy đĩa của bạn, nhưng điều này giống như cố gắng sửa chữa phổi bị thủng bằng băng hỗ trợ. Bạn nên trực tiếp xử lý tệp nhật ký có vấn đề thay vì chỉ thêm một vấn đề tiềm năng khác. Khác với việc chuyển hướng một số hoạt động nhật ký giao dịch sang một ổ đĩa khác, tệp nhật ký thứ hai thực sự không có gì cho bạn (không giống như tệp dữ liệu thứ hai), vì mỗi lần chỉ có một tệp có thể được sử dụng. Paul Randal cũng giải thích lý do tại sao nhiều tệp nhật ký có thể cắn bạn sau này .
Được chủ động
Thay vì thu nhỏ tệp nhật ký của bạn xuống một số lượng nhỏ và để nó tự động liên tục ở một tỷ lệ nhỏ, hãy đặt nó ở một kích thước lớn hợp lý (một giao dịch sẽ chứa tổng số các giao dịch đồng thời lớn nhất của bạn) và đặt tự động hợp lý thiết lập như một dự phòng, để nó không phải tăng trưởng nhiều lần để đáp ứng các giao dịch đơn lẻ và do đó sẽ tương đối hiếm khi nó phải phát triển trong các hoạt động kinh doanh thông thường.
Các cài đặt tồi tệ nhất có thể có ở đây là tăng trưởng 1 MB hoặc tăng trưởng 10%. Thật thú vị, đây là những mặc định cho SQL Server (tôi đã phàn nàn và yêu cầu thay đổi không có kết quả ) - 1 MB cho các tệp dữ liệu và 10% cho các tệp nhật ký. Cái trước quá nhỏ trong thời đại ngày nay và cái sau dẫn đến các sự kiện dài hơn và dài hơn mỗi lần (giả sử, tệp nhật ký của bạn là 500 MB, tăng trưởng đầu tiên là 50 MB, tăng trưởng tiếp theo là 55 MB, tăng trưởng tiếp theo là 60,5 MB , v.v. - và trên I / O chậm, tin tôi đi, bạn sẽ thực sự chú ý đến đường cong này).
đọc thêm
Xin đừng dừng lại ở đây; trong khi nhiều lời khuyên bạn thấy ngoài kia về việc thu hẹp các tệp nhật ký vốn đã xấu và thậm chí có khả năng gây thảm họa, có một số người quan tâm nhiều hơn đến tính toàn vẹn dữ liệu hơn là giải phóng không gian đĩa.
Một bài đăng trên blog tôi đã viết vào năm 2009, khi tôi thấy một vài bài viết "đây là cách thu nhỏ tệp nhật ký" xuất hiện .
Một bài đăng trên blog Brent Ozar đã viết bốn năm trước, chỉ ra nhiều tài nguyên, để đáp lại bài viết của Tạp chí SQL Server không nên được xuất bản .
Một bài đăng trên blog của Paul Randal giải thích lý do tại sao bảo trì t-log là quan trọng và tại sao bạn cũng không nên thu nhỏ các tệp dữ liệu của mình .
Mike Walsh cũng có một câu trả lời tuyệt vời bao gồm một số khía cạnh này, bao gồm cả lý do tại sao bạn không thể thu nhỏ tệp nhật ký của mình ngay lập tức .
