Bảo trì Nhật ký giao dịch khi chuyển sang Phục hồi đơn giản

Lý lịch:

Gần đây tôi đã thừa hưởng hơn 50 máy chủ SQL với hơn 450 cơ sở dữ liệu. Các bản sao lưu hàng đêm có dung lượng khoảng 8TB và không cần phải nói, chúng tôi đang sử dụng nhiều dung lượng đĩa hơn mức chúng tôi muốn. Tất cả các cơ sở dữ liệu được đặt thành phục hồi ĐẦY ĐỦ và nhật ký giao dịch chưa bao giờ được sao lưu. Tôi đã trải qua tất cả các Máy chủ SQL và xác định các máy chủ ưu tiên thấp chỉ cần sao lưu hàng đêm và nơi mất dữ liệu một ngày là có thể chấp nhận được.

Câu hỏi:

Tôi đang chuyển rất nhiều cơ sở dữ liệu ưu tiên thấp sang SIMPLEchế độ phục hồi FULL. Nhật ký giao dịch hiện tại sẽ bị cắt ngắn (khi điểm kiểm tra được tạo)? Một số nhật ký giao dịch hiện tại là 50-100GB; cách tiếp cận tốt nhất trong việc xác định những gì tôi nên thu nhỏ chúng xuống cho mục đích tiến về phía trước là gì? Tôi rõ ràng không muốn giữ chúng lớn như vậy. Hoặc, họ sẽ tự thu nhỏ lại theo thời gian (tôi không nghĩ họ sẽ làm thế)?

Trước khi chuyển đổi từ FULLđể SIMPLEmô hình phục hồi, hãy tự hỏi có bao nhiêu dữ liệu bạn có thể đủ khả năng để mất. Đối với các cơ sở dữ liệu trong trường hợp xảy ra thảm họa, bạn vẫn ổn với việc khôi phục bản sao lưu cơ sở dữ liệu cuối cùng, SIMPLEsẽ ổn. Nếu đây không phải là trường hợp, ở lại với FULL.

Để thu nhỏ LDFtệp đến kích thước nhỏ nhất có thể, hãy làm theo các bước do Kimberly Tripp đưa ra tại đây: 8 bước để thông lượng Nhật ký giao dịch tốt hơn

1. Đợi thời gian khi có hoạt động thấp trên cơ sở dữ liệu

2. Chạy trong SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Sửa đổi kích thước tệp nhật ký giao dịch:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

Tôi đang chuyển đổi rất nhiều cơ sở dữ liệu sang chế độ khôi phục SIMPLE từ chế độ khôi phục FULL (Nhật ký T và khôi phục tại thời điểm là không cần thiết). Nhật ký giao dịch hiện tại sẽ bị cắt ngắn (khi điểm kiểm tra được tạo)?

Trong mô hình khôi phục đơn giản, công cụ cơ sở dữ liệu sẽ đưa ra các điểm kiểm tra tự động và tần số của nó được xác định bởi khoảng thời gian khôi phục (cài đặt cấu hình máy chủ nâng cao) hoặc nếu nhật ký đã đầy 70%.

Trừ khi bạn có một số giao dịch chạy dài xảy ra sẽ trì hoãn việc cắt bớt nhật ký, một điểm kiểm tra tự động sẽ cắt bớt phần không sử dụng của nhật ký T.

Một số nhật ký giao dịch hiện tại là 50-100GB, cách tiếp cận tốt nhất để xác định những gì tôi nên thu nhỏ chúng xuống cho mục đích di chuyển về phía trước. Tôi rõ ràng không muốn giữ chúng lớn như vậy.

Nếu bạn có mô hình khôi phục cơ sở dữ liệu được đặt thành ĐẦY ĐỦ cho các cơ sở dữ liệu đó với 50-100GB nhật ký T, thì bạn phải bắt đầu thực hiện sao lưu nhật ký T thường xuyên. Hãy nhớ trong mô hình khôi phục hoàn toàn, một khi chuỗi sao lưu nhật ký đã được thiết lập, ngay cả các điểm kiểm tra tự động sẽ không làm cho nhật ký bị cắt bớt.

Như một phương sách cuối cùng, bạn có thể cắt bớt tệp nhật ký và sau đó ngay lập tức sao lưu toàn bộ và sau đó bắt đầu thực hiện sao lưu T-log để bạn có thể thực hiện khôi phục tại thời điểm nếu thảm họa xảy ra.

Hoặc, họ sẽ tự thu nhỏ lại theo thời gian (tôi không nghĩ họ sẽ làm thế)?

Như @TomTom đã chỉ ra, đây là một thao tác thủ công.

Đọc lên :

• Quản lý kích thước của tệp nhật ký giao dịch
• CÁCH CHIA SẺ ĐĂNG NHẬP SQL SERVER - Tuyệt vời Viết lên.
• Làm thế nào để các trạm kiểm soát hoạt động và những gì được ghi lại - Bởi: Paul Randal

Nhiều câu hỏi không thể được trả lời bởi chúng tôi. Bao lâu là một mảnh của chuỗi?

Một số nhật ký giao dịch hiện tại là 50-100GB, cách tiếp cận tốt nhất để xác định những gì tôi nên thu nhỏ chúng xuống cho mục đích di chuyển về phía trước.

Miễn là họ cần. Tôi đề nghị KHÔNG thu nhỏ. Nhật ký trunacate, quay lại sau một tuần và xem có bao nhiêu dung lượng được sử dụng, THEN quyết định. Nhưng BẠN phải trả lời cái này.

Các bản sao lưu hàng đêm khoảng 8TB và không cần phải nói, chúng tôi đang sử dụng nhiều dung lượng đĩa hơn mức chúng tôi muốn.

Vậy tại sao lại biến chúng thành đơn giản? Ý tôi là, nghiêm túc đấy.

Tất cả các cơ sở dữ liệu được đặt thành phục hồi ĐẦY ĐỦ và nhật ký giao dịch chưa bao giờ được sao lưu.

Một logic nhỏ sẽ cho bạn biết rằng igf bạn cắt chúng ONCE, sau đó bạn có thể sẽ sử dụng rất ít không gian để sao lưu chúng. Kết quả có thể là bạn cũng có thể giữ chúng ở chế độ phục hồi hoàn toàn. Hãy thử nó trước. Nếu chúng tăng với khối lượng thấp, vv thì bản sao lưu nhật ký sẽ nhỏ hơn rất nhiều trong tương lai.

Tôi đã trải qua tất cả các Máy chủ SQL và xác định các ưu tiên THẤP chỉ cần sao lưu hàng đêm và mất dữ liệu trong một ngày ngay cả khi xảy ra thảm họa sẽ không thành vấn đề (cơ sở dữ liệu Fax và những thứ tương tự).

Đúng. Đó là cho đến khi bạn kết thúc tại tòa án và nhận được ass của bạn vì không có tài liệu pháp lý quan trọng. Bạn có biết rằng nhật ký fax có thể là một phần của những gì bạn bắt buộc phải giữ trong nhiều năm như thông tin liên quan đến kinh doanh không? Nó là như thế trong thẩm quyền của tôi (10 năm). Nếu bạn là một công ty chứng khoán U, có thể có sự ngạc nhiên tương tự (SOX). Việc không làm như vậy sẽ khiến RẤT tệ tại tòa nếu bạn muốn chứng minh rằng bạn không nhận được fax. Hoặc đã gửi một. Không ai quan tâm liệu điều này có xảy ra hàng tháng không và bạn có nhiều nhật ký gần đây hơn - bạn không đạt yêu cầu của pháp luật. Hãy chắc chắn rằng điều này được ký bởi một người RẤT cao, bởi vì doanh nghiệp của bạn không quan trọng có thể là lý do sa thải của bạn.

Hoặc, họ sẽ tự thu nhỏ lại theo thời gian (tôi không nghĩ họ sẽ làm thế)?

Không. Và họ không nên làm điều đó. Đăng nhập lại kích thước là một hoạt động thủ công ngoại trừ cơ sở dữ liệu khối lượng thấp.