Làm cách nào để giảm kích thước sao lưu nhật ký giao dịch sau khi sao lưu toàn bộ?

Tôi có ba gói bảo trì được thiết lập để chạy trên phiên bản Sql Server 2005:

• Tối ưu hóa cơ sở dữ liệu hàng tuần theo sau là một bản sao lưu đầy đủ
• Sao lưu vi sai hàng ngày
• Sao lưu nhật ký giao dịch hàng giờ

Các bản sao lưu nhật ký hàng giờ thường nằm trong khoảng vài trăm Kb và 10Mb tùy thuộc vào mức độ hoạt động, chênh lệch hàng ngày thường tăng lên khoảng 250Mb vào cuối tuần và sao lưu hàng tuần là khoảng 3,5Gb.

Vấn đề tôi gặp phải là sự tối ưu hóa trước khi sao lưu toàn bộ dường như khiến bản sao lưu nhật ký giao dịch tiếp theo tăng lên gấp đôi kích thước của bản sao lưu đầy đủ, trong trường hợp này là 8Gb, trước khi trở lại bình thường.

Ngoài ra BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, có cách nào để giảm kích thước của bản sao lưu nhật ký đó hay ngăn chặn sự tối ưu hóa được ghi lại trong nhật ký giao dịch, vì chắc chắn chúng sẽ được tính vào bản sao lưu đầy đủ trước đó?

Một số gợi ý thú vị ở đây, mà tất cả dường như cho thấy sự hiểu lầm về cách sao lưu nhật ký hoạt động. Một bản sao lưu nhật ký chứa TẤT CẢ nhật ký giao dịch được tạo từ bản sao lưu nhật ký trước đó, bất kể sao lưu toàn bộ hoặc khác biệt được thực hiện trong thời gian tạm thời. Dừng sao lưu nhật ký hoặc chuyển sang sao lưu toàn bộ hàng ngày sẽ không ảnh hưởng đến kích thước sao lưu nhật ký. Điều duy nhất ảnh hưởng đến nhật ký giao dịch là sao lưu nhật ký, khi chuỗi sao lưu nhật ký đã bắt đầu.

Ngoại lệ duy nhất cho quy tắc này là nếu chuỗi sao lưu nhật ký đã bị hỏng (ví dụ: bằng cách đi đến mô hình khôi phục SIMPLE, hoàn nguyên từ ảnh chụp nhanh cơ sở dữ liệu, cắt bớt nhật ký bằng BACKUP LOG VỚI NO_LOG / TRUNCATE_ONLY), trong trường hợp đó là sao lưu nhật ký đầu tiên sẽ chứa tất cả nhật ký giao dịch kể từ lần sao lưu đầy đủ cuối cùng - khởi động lại chuỗi sao lưu nhật ký; hoặc nếu chuỗi sao lưu nhật ký chưa được bắt đầu - khi bạn chuyển sang FULL lần đầu tiên, bạn sẽ hoạt động theo kiểu mô hình khôi phục giả SIMPLE cho đến khi thực hiện sao lưu toàn bộ đầu tiên.

Để trả lời câu hỏi ban đầu của bạn, không cần đi sâu vào mô hình khôi phục SIMPLE, bạn sẽ phải sao lưu tất cả nhật ký giao dịch. Tùy thuộc vào các hành động bạn đang thực hiện, bạn có thể thực hiện sao lưu nhật ký thường xuyên hơn để giảm kích thước của chúng hoặc thực hiện nhiều cơ sở dữ liệu được nhắm mục tiêu hơn.

Nếu bạn có thể đăng một số thông tin về bảo trì mà bạn đang làm, tôi có thể giúp bạn tối ưu hóa chúng. Bạn có, trong bất kỳ trường hợp nào, thực hiện xây dựng lại chỉ mục theo sau là một cơ sở dữ liệu thu nhỏ để lấy lại không gian được sử dụng để xây dựng lại chỉ mục?

Nếu bạn không có hoạt động nào khác trong cơ sở dữ liệu trong khi bảo trì đang diễn ra, bạn có thể làm như sau:

• đảm bảo hoạt động của người dùng được dừng lại
• thực hiện sao lưu nhật ký cuối cùng (điều này cho phép bạn phục hồi ngay đến điểm bắt đầu bảo trì)
  • chuyển sang mô hình khôi phục SIMPLE
  • thực hiện bảo trì - nhật ký sẽ cắt ngắn trên mỗi điểm kiểm tra
  • chuyển sang mô hình phục hồi FULL và sao lưu toàn bộ
  • tiếp tục như bình thường

Hy vọng điều này sẽ giúp - mong được biết thêm.

Cảm ơn

[Chỉnh sửa: sau tất cả các cuộc thảo luận về việc liệu một bản sao lưu đầy đủ có thể thay đổi kích thước của bản sao lưu nhật ký tiếp theo hay không (tôi không thể) Tôi kết hợp một bài đăng blog toàn diện với tài liệu nền và một tập lệnh chứng minh điều đó. Hãy xem thử tại https://www.sqlskills.com/bloss/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]

Bạn có thể thu nhỏ chúng, nhưng chúng sẽ chỉ phát triển trở lại, cuối cùng gây ra sự phân mảnh đĩa. Index xây dựng lại và phân mảnh làm cho nhật ký giao dịch rất lớn. Nếu bạn không cần khả năng phục hồi tại thời điểm, bạn có thể thay đổi sang chế độ khôi phục Đơn giản và loại bỏ hoàn toàn các bản sao lưu nhật ký giao dịch.

Tôi đoán bạn đang sử dụng một kế hoạch bảo trì để tối ưu hóa, bạn có thể thay đổi nó để sử dụng tập lệnh chỉ chống phân mảnh khi đạt đến một mức phân mảnh nhất định và bạn sẽ không gặp phải bất kỳ ảnh hưởng nào về hiệu suất. Điều này sẽ tạo ra các bản ghi nhỏ hơn nhiều.

Tôi sẽ bỏ qua sự khác biệt hàng ngày để ủng hộ BTW sao lưu đầy đủ hàng ngày.

Câu hỏi cuối cùng của bạn là: "Khác với BACKUP LOG VỚI TRUNCATE_ONLY, có cách nào để giảm kích thước của bản sao lưu nhật ký đó hay ngăn chặn tối ưu hóa được ghi lại trong nhật ký giao dịch, vì chắc chắn chúng sẽ được tính toán đầy đủ sao lưu họ đi trước? "

Không, nhưng đây là một cách giải quyết. Nếu bạn biết rằng các hoạt động duy nhất trong cơ sở dữ liệu đó tại thời điểm đó sẽ là các công việc bảo trì chỉ mục, thì bạn có thể dừng sao lưu nhật ký giao dịch trước khi bảo trì chỉ mục bắt đầu. Ví dụ: một số máy chủ của tôi vào tối thứ bảy, lịch trình công việc trông như thế này:

• 9:30 PM - sao lưu nhật ký giao dịch chạy.
• 9:45 PM - sao lưu nhật ký giao dịch chạy lần cuối. Lịch trình dừng lại lúc 9:59.
• 10:00 PM - công việc bảo trì chỉ mục bắt đầu và có các điểm dừng tích hợp để kết thúc trước 11:30.
• 11:30 PM - công việc sao lưu đầy đủ bắt đầu và kết thúc trong vòng dưới 30 phút.
• 12:00 AM - Sao lưu nhật ký giao dịch bắt đầu lại sau mỗi 15 phút.

Điều đó có nghĩa là tôi không có khả năng phục hồi tại thời điểm từ 9:45 đến 11:30 tối, nhưng mức chi trả là hiệu suất nhanh hơn.

Câu trả lời dễ dàng: Thay đổi công việc tối ưu hóa hàng tuần của bạn để chạy theo cách cân bằng hơn trên cơ sở hàng đêm. tức là lập chỉ mục lại các bảng ae vào tối chủ nhật, f - l vào tối thứ hai, v.v ... tìm một số dư tốt, nhật ký của bạn sẽ trung bình bằng 1/6 kích thước. Tất nhiên điều này hoạt động tốt nhất nếu bạn không sử dụng công việc bảo trì chỉ số ssis tích hợp.

Nhược điểm của điều này và nó đáng kể tùy thuộc vào tải trải nghiệm db của bạn là nó tàn phá trình tối ưu hóa và sử dụng lại các kế hoạch truy vấn.

Nhưng nếu tất cả những gì bạn quan tâm là kích thước của nhật ký t của bạn trên cơ sở hàng tuần, hãy chia nó từ ngày này sang ngày khác hoặc giờ này sang giờ khác và chạy các bản sao lưu t-log ở giữa.

Bạn cũng có thể xem xét một công cụ của bên thứ ba (Litespeed từ Quest, SQL Backup từ Red Gate, Hyperbac) để giảm kích thước của các bản sao lưu và nhật ký. Họ có thể tự trả tiền nhanh chóng trong việc tiết kiệm băng.

Có thể giả định rằng "tối ưu hóa" của bạn bao gồm việc xây dựng lại chỉ mục. Chỉ thực hiện các tác vụ này hàng tuần có thể được chấp nhận trên cơ sở dữ liệu không gặp phải nhiều cập nhật và chèn, tuy nhiên nếu dữ liệu của bạn rất linh hoạt, bạn có thể muốn thực hiện một số điều:

1. Xây dựng lại hoặc sắp xếp lại các chỉ mục của bạn hàng đêm nếu lịch trình của bạn cho phép và nếu tác động được chấp nhận. Khi thực hiện các nhiệm vụ bảo trì chỉ mục hàng đêm này, chỉ nhắm mục tiêu đến các chỉ mục bị phân mảnh vượt quá 30% cho việc xây dựng lại và trong phạm vi 15-30% cho các reorgs.

2. Các tác vụ này là các giao dịch được ghi lại, vì vậy nếu bạn lo lắng về tăng trưởng nhật ký thì tôi sẽ ủng hộ những gì Paul đề xuất. Sao lưu nhật ký giao dịch cuối cùng trước khi bảo trì chỉ mục, chuyển sang Phục hồi đơn giản, sau đó là quy trình bảo trì và sau đó chuyển trở lại Phục hồi hoàn toàn, sau đó sao lưu toàn bộ dữ liệu nên thực hiện thủ thuật.

Tôi có một cách tiếp cận giống như zen đối với các tệp nhật ký của mình: chúng là kích thước mà chúng muốn có. Chừng nào họ chưa chịu đựng được sự tăng trưởng quá mức do thực tiễn sao lưu kém so với hoạt động cơ sở dữ liệu là câu thần chú tôi sống.

Đối với các tập lệnh thực hiện bảo trì chỉ mục tùy ý nhìn trực tuyến: có một tấn ra khỏi đó. Andrew Kelly đã xuất bản một bài đàng hoàng trên Tạp chí SQL khoảng một năm trước. SQLServerPedia có một số tập lệnh từ Michelle Ufford và số mới nhất của Tạp chí SQL (tháng 7 năm 2009 tôi tin) cũng có một bài viết đầy đủ về chủ đề này. Điểm quan trọng là tìm một thứ phù hợp với bạn và biến nó thành của riêng bạn với các tùy chỉnh tối thiểu.

Bạn có thể sao lưu đặc biệt nhật ký giao dịch của mình tại nhiều điểm khác nhau trong quá trình tối ưu hóa cơ sở dữ liệu của bạn không? Tổng kích thước của nhật ký t sẽ giống nhau, nhưng mỗi cái sẽ nhỏ hơn, có thể giúp bạn theo một cách nào đó.

Bạn có thể thực hiện tối ưu hóa cơ sở dữ liệu được nhắm mục tiêu nhiều hơn để tạo ra ít giao dịch hơn không (ai đó đã đề cập đến điều này nhưng tôi không chắc chắn các hàm ý đã được đánh vần). Chẳng hạn như chịu đựng một lượng phân mảnh nhất định hoặc lãng phí không gian trong một thời gian. Nếu 40% số bảng của bạn chỉ bị phân mảnh 5%, không chạm vào chúng có thể tiết kiệm được một chút hoạt động.