Việc làm cho tệp nhật ký nhỏ hơn thực sự nên được dành cho các trường hợp mà nó gặp phải sự tăng trưởng bất ngờ mà bạn không mong đợi 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ì việc thu nhỏ tạm thời sẽ không thực hiện được nhiều. 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 rằng bạn có thể khôi phục nó nếu xảy ra sự cố.
Nếu bạn quan tâm đến khôi phục 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 vào bất kỳ thứ gì khác ngoài bản sao lưu toàn bộ hoặc khác biệt.)
Có lẽ cơ sở dữ liệu của bạn ở FULL chế độ phục hồi. Nếu không, hãy đảm bảo rằng đó là:
ALTER DATABASE testdb SET RECOVERY FULL;
Ngay cả khi bạn đang sao lưu đầy đủ 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 nhật ký sao lưu - điều này là để bảo vệ bạn, không cần ăn mất dung lượng ổ đĩa của bạn. Bạn nên thực hiện các sao lưu nhật ký này khá thường xuyên, theo mục tiêu khôi phục của bạn. Ví dụ:nếu bạn có một quy tắc kinh doanh quy định rằng bạn có thể đủ khả năng để mất dữ liệu không quá 15 phút trong trường hợp xảy ra thảm họa, bạn nên có công việc sao lưu nhật ký sau mỗi 15 phút. Đây là một tập lệnh sẽ tạo tên tệp có dấu thời gian dựa trên thời gian hiện tại (nhưng bạn cũng có thể làm điều này với các kế hoạch bảo trì, v.v., chỉ cần không chọn bất kỳ tùy chọn thu nhỏ nào trong kế hoạch bảo trì, chúng thật 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ữ cơ bản khác. Sao lưu những thứ này vào cùng một máy (hoặc vào một máy khác sử dụng cùng một đĩa bên dưới hoặc một máy ảo khác trên cùng một máy chủ vật lý) không thực sự giúp ích cho bạn, vì nếu máy bị nổ, bạn đã mất cơ sở dữ liệu của mình. và các 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 khi sao lưu cục bộ và sau đó chuyển chúng đến một vị trí khác ở hậu trường; trong cả hai trường hợp, bạn muốn gỡ bỏ chúng khỏi máy cơ sở dữ liệu chính càng nhanh càng tốt.
Bây giờ, khi bạn đã chạy các bản sao lưu nhật ký thường xuyên, nên thu nhỏ tệp nhật ký thành một thứ gì đó hợp lý hơn bất cứ thứ gì nó bị nổ tung cho đến nay. Điều này không nghĩa là chạy SHRINKFILE lặp đi lặp lại cho đến khi tệp nhật ký là 1 MB - ngay cả khi bạn sao lưu nhật ký thường xuyên, nó vẫn cần phải đáp ứng tổng của bất kỳ giao dịch đồng thời nào có thể xảy ra. Sự kiện tự động duyệt tệp nhật ký rất tốn kém, vì SQL Server phải xóa tệp (không giống như tệp dữ liệu khi khởi tạo tệp tức thì được bật) và các giao dịch của người dùng phải đợi trong khi điều này xảy ra. Bạn muốn thực hiện quy trình phát triển-thu nhỏ-phát triển này càng ít càng tốt và bạn chắc chắn không muốn bắt người dùng của mình phải 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 đưa ra kích thước thực tế cho tệp nhật ký của mình. Không ai ở đây có thể cho bạn biết đó là gì nếu không biết nhiều hơn về hệ thống của bạn, nhưng nếu bạn thường xuyên thu nhỏ tệp nhật ký và nó đang phát triển trở lại, hình mờ tốt có thể cao hơn 10-50% so với mức lớn nhất. . Giả sử rằng con số đó lên đến 200 MB và bạn muốn bất kỳ sự kiện tự động phát triển nào tiếp theo 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 có> 200 MB, trước tiên bạn có thể cần chạy tệp này:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Nếu bạn không quan tâm đến khôi phục tại thời điểm
Nếu đây là cơ sở dữ liệu thử nghiệm và bạn không quan tâm đến 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 ở SIMPLE chế độ khôi phục.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Đưa cơ sở dữ liệu vào SIMPLE chế độ 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ữ bản ghi của tất cả giao dịch (như FULL phục hồi cho đến khi bạn sao lưu nhật ký). CHECKPOINT các sự kiện sẽ giúp kiểm soát nhật ký và đảm bảo rằng nhật ký đó không cần phát triển trừ khi bạn tạo nhiều hoạt động t-log giữa CHECKPOINT s.
Tiếp theo, bạn nên đảm bảo 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ử, dọn dẹp hàng năm vào mùa xuân hoặc xây dựng lại các chỉ mục lớn nhất của bạn) chứ không phải do việc sử dụng bình thường hàng ngày. Nếu bạn thu nhỏ tệp nhật ký thành một kích thước nhỏ đến mức nực cười và SQL Server chỉ phải phát triển lại nó để đáp ứng hoạt động bình thường của bạn, bạn đã thu được gì? Bạn có thể sử dụng không gian đĩa mà bạn chỉ giải phóng tạm thời không? Nếu bạn cần sửa chữa 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, hãy đặt kích thước và tốc độ tăng trưởng thích hợp. Theo ví dụ trong trường hợp khôi phục điểm trong thời gian, bạn có thể sử dụng cùng một mã và logic để xác định kích thước tệp phù hợp và đặt các thông số tự động phát triển 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_ONLYrồi chọnSHRINKFILE. Đối với một,TRUNCATE_ONLYnày tùy chọn đã không được dùng nữa và không còn khả dụng trong các phiên bản SQL Server hiện tại. Thứ hai, nếu bạn đang ở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 đủ. -
Tách 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 rằng điều này có thể nguy hiểm như thế nào. Cơ sở dữ liệu của bạn có thể không sao lưu, có thể xuất hiện một cách đáng ngờ, bạn có thể phải hoàn nguyên về bản sao lưu (nếu có), v.v., 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 điều 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 mộ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 nó một cách độc lập, sử dụngDBCC SHRINKFILEhoặcALTER 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ì, này, SQL Server sẽ cho phép tôi làm điều đó trong một số trường hợp 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ế độ chỉ đọc (và đúng như vậy, 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ẽ chỉ dẫn đến nhiều sự kiện tăng trưởng không cần thiết, vì nhật ký phải đáp ứng các giao dịch hiện tại bất kể mô hình khôi phục là gì. Giải phóng không gian đó tạm thời có ích gì, chỉ để SQL Server có thể khôi phục nó một cách từ từ và khó chịu? -
Tạo tệp nhật ký thứ hai . Điều này sẽ tạm thời cứu trợ ổ đĩ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 một phổi bị thủng bằng một băng hỗ trợ. Bạn nên xử lý trực tiếp tệp nhật ký có vấn đề thay vì chỉ thêm một vấn đề tiềm ẩn khác. Ngoà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 làm gì cho bạn (không giống như tệp dữ liệu thứ hai), vì chỉ có thể sử dụng một trong các tệp tại một thời điểm. 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.
Hãy chủ động
Thay vì thu nhỏ tệp nhật ký của bạn thành một số lượng nhỏ và để nó liên tục tự động tự động với tốc độ nhỏ, hãy đặt nó thành một số kích thước lớn hợp lý (một kích thước sẽ phù hợp với tổng tập hợp lớn nhất của các giao dịch đồng thời của bạn) và đặt thời gian tự động hợp lý thiết lập như một dự phòng, để nó không phải tăng lên nhiều lần để đáp ứng các giao dịch đơn lẻ và do đó, nó sẽ tương đối hiếm khi phải phát triển trong các hoạt động kinh doanh bình thường.
Cài đặt tồi tệ nhất có thể xảy ra ở đây là tăng trưởng 1 MB hoặc tăng trưởng 10%. Thật buồn cười, đây là những mặc định cho SQL Server (mà tôi đã phàn nàn và yêu cầu thay đổi nhưng không có kết quả) - 1 MB cho tệp dữ liệu và 10% cho tệp nhật ký. Cái trước là quá nhỏ trong thời đại ngày nay và cái sau dẫn đến các sự kiện ngày càng dài hơn mọi lúc (giả sử tệp nhật ký của bạn là 500 MB, lần tăng đầu tiên là 50 MB, lần tăng tiếp theo là 55 MB, lần tă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ự nhận thấy đường cong này).
Đọc thêm
Xin đừng dừng lại ở đây; trong khi phần lớn lời khuyên bạn thấy trên mạng về việc thu nhỏ tệp nhật ký là không tốt và thậm chí có khả năng gây tai hại, nhưng có một số người quan tâm đến tính toàn vẹn của dữ liệu hơn là giải phóng dung lượng ổ đĩa.
Một bài đăng trên blog mà tôi đã viết vào năm 2009, khi tôi thấy một vài bài đăng "đâ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 cách đây bốn năm, chỉ đến nhiều tài nguyên, để phản hồi lại một bài báo trên Tạp chí SQL Server rằng 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ại 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 về 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.
