Tại sao nó rất quan trọng để sao lưu nhật ký giao dịch của bạn?

Chúng tôi hiện đang triển khai một giải pháp sao lưu cho khách hàng và giải pháp ERP của họ sử dụng SQL Server.

Giải pháp ERP được thiết lập bởi một công ty khác. Và họ đang nói với tôi rằng việc sao lưu và cắt bớt nhật ký giao dịch là cực kỳ quan trọng.

Tôi đã đọc một chút về nhật ký giao dịch này và tôi không hiểu tại sao điều này lại quan trọng khi tôi vẫn sao lưu toàn bộ máy (Chúng tôi đang sử dụng ArcServe UDP, nhận biết về SQL Server và sử dụng VSS). Theo hiểu biết của tôi, các tác vụ dọn dẹp trên SQL Server VM đã đảm nhiệm việc cắt bớt nhật ký, tuy nhiên, UDP cũng cho phép cắt bớt nhật ký SQL Server.

Theo hiểu biết của tôi rằng nhật ký giao dịch có thể được sử dụng để khôi phục cơ sở dữ liệu bị hỏng, bởi vì, đó là nhật ký của tất cả các giao dịch. Nhưng tôi đã có một bản sao lưu hàng giờ của toàn bộ cơ sở dữ liệu, vậy, tại sao tôi lại quan tâm?

Bạn chỉ phải thực hiện việc này nếu Chế độ khôi phục DB của bạn được đặt thành "đầy đủ". Nếu nó được đặt thành "đơn giản", bạn không cần phải sao lưu nhật ký giao dịch. Nhưng xem ra cho sự khác biệt giữa hai lựa chọn này!

Trước hết: Nếu bạn muốn có thể khôi phục DB về một thời điểm cụ thể, bạn phải sử dụng chế độ "đầy đủ". (Tôi nghĩ rằng bạn có thể điều chỉnh thời gian chính xác đến mức bạn thậm chí có thể chỉ định mili giây cho điểm khôi phục) Trong chế độ "đơn giản", bạn chỉ có thể quay lại bản sao lưu đầy đủ cuối cùng .

Nếu bạn không sao lưu / cắt bớt nhật ký giao dịch của mình, nó sẽ phát triển toàn bộ thời gian (ở chế độ đầy đủ). Tôi thấy các cơ sở dữ liệu trong đó tệp .trn lớn hơn gấp đôi so với cơ sở dữ liệu. Điều này phụ thuộc vào tần suất thay đổi được thực hiện đối với DB.

Một điểm khác là sao lưu nhật ký thường nhanh hơn sao lưu toàn bộ.

Vì vậy, tôi nghĩ rằng kế hoạch sao lưu của bạn để tạo một bản sao lưu đầy đủ mỗi giờ là không tối ưu. Nhưng nó phụ thuộc vào tình huống của bạn:

Nếu bạn nói: Được rồi nếu tôi có thể khôi phục DB đến giờ cuối cùng, mọi thứ đều ổn. -> Bạn cũng có thể suy nghĩ về việc đặt chế độ khôi phục thành "đơn giản" nếu bạn muốn giữ bản sao lưu đầy đủ mỗi giờ.

Theo tôi, một ý tưởng tốt hơn sẽ là tạo một bản sao lưu đầy đủ vào sáng sớm và sau đó thực hiện sao lưu nhật ký giao dịch mỗi giờ. Nó sẽ nhanh hơn nhiều và bạn có thể khôi phục lại bất kỳ thời điểm nào bạn muốn. Và tập tin .trn của bạn sẽ không phát triển quá nhiều ...

Hi vọng điêu nay co ich.

Tốt. Bạn quan tâm vì nếu mô hình khôi phục của bạn được đặt đầy đủ và bạn không sao lưu Nhật ký giao dịch bằng cách sử dụng bản sao lưu của SQL (chứ không phải bản sao lưu máy chủ), nhật ký giao dịch sẽ tiếp tục phát triển cho đến khi nó tiêu tốn hết dung lượng đĩa trống. (Tôi đã từng thấy một đồng nghiệp nhỏ hơn cài đặt SQL Server trên ổ đĩa hệ thống và không bao giờ sao lưu nhật ký giao dịch. Nó đã ăn Windows .)

Vâng, nó cũng sẽ khôi phục đến một thời điểm cụ thể. Xuống đến phút. Giống như Twinkles nói, vâng, mọi người đánh rơi bàn và những thứ tương tự.

Tôi không biết những gì bạn đang sử dụng để sao lưu toàn bộ cơ sở dữ liệu hàng giờ của mình và nếu đó là cùng một sản phẩm với những gì bạn đang sử dụng cho toàn bộ máy. Nếu vậy, một giải pháp sao lưu không nhận biết SQL không được hỗ trợ để khôi phục. Ví dụ, lượng thời gian cần thiết để VSS sao chép các tệp MDF và LDF có thể gây ra sự không khớp dấu thời gian nội bộ, ví dụ.

Chúng tôi quản lý một số hệ thống ERP là tốt. Và vấn đề thường là vào ban đêm thường có các công việc hàng loạt chạy dài đồng bộ hóa dữ liệu với các hệ thống khác. Và họ mất đôi khi một giờ hoặc nhiều hơn. Vì vậy, những gì bạn muốn làm trong trường hợp sụp đổ là nhảy đến một điểm mà bạn có dữ liệu phù hợp. (Có nghĩa là đúng giữa hai công việc hàng loạt.) Nếu bạn chỉ nhìn vào thời gian bạn có thể không phải lúc nào cũng biết chính xác trạng thái của cơ sở dữ liệu tại thời điểm này.

Nhưng tất nhiên nó phụ thuộc vào tình hình. Nếu bạn không có bất kỳ công việc tự động, vv bạn có thể hoàn toàn ổn với một bản sao lưu hàng giờ.

Có một số lý do tại sao bạn muốn làm điều đó:

1. Một hệ thống cơ sở dữ liệu thường bận rộn, có thể thực hiện hàng ngàn giao dịch mỗi giây. Dữ liệu có thể được trải ra trên một số tệp trên các hệ thống tệp khác nhau. Nó không phải là tầm thường để đảm bảo rằng cơ sở dữ liệu ở trạng thái nhất quán (còn gọi là có thể sử dụng) sau khi khôi phục. Nếu giải pháp sao lưu của bạn phụ thuộc vào nhiệm vụ, thật tuyệt, nhưng bạn nên chắc chắn về điều này trước khi đặt cược công việc của mình vào nó.
2. Một ví dụ: Ai đó đánh rơi một bảng có dữ liệu quan trọng do nhầm lẫn. Nếu bạn có một bản sao lưu cơ sở dữ liệu với khả năng phục hồi tại thời điểm, bạn có thể khôi phục dữ liệu nhanh chóng mà không phải khôi phục toàn bộ hệ thống.
3. Nếu cơ sở dữ liệu ở chế độ khôi phục hoàn toàn, nhật ký giao dịch của SQL Server sẽ phát triển. Dung lượng lưu trữ trong nhật ký giao dịch chỉ được sử dụng lại nếu nhật ký giao dịch đã được sao lưu. Nếu bạn không sao lưu nhật ký giao dịch thường xuyên, hệ thống tệp của bạn sẽ lấp đầy cho đến khi không còn chỗ trống. Tại thời điểm đó, mọi thứ sẽ dừng lại ngay lập tức , vì không có giao dịch mới nào có thể được bắt đầu.

Khi cơ sở dữ liệu của bạn phát triển vượt quá những gì bạn có thể sao lưu trong một giờ, bạn cần một mô hình khác.

Một bản sao lưu đầy đủ cơ sở dữ liệu của bạn sẽ cắt bớt nhật ký của bạn, nhưng nó cần phải là "nhận thức SQL", bởi vì trong kịch bản đó, đó là phần mềm sao lưu cho máy chủ SQL biết những gì nó đã sao lưu và những gì cần cắt bớt.

Như những người khác đề cập, nếu bạn có cơ sở dữ liệu trong mô hình khôi phục "Đầy đủ", nhật ký giao dịch sẽ phát triển vô hạn, cho đến khi bạn tạo bản sao lưu nhận biết SQL đầy đủ.

Phục hồi thực sự là vấn đề ở đây, không phải Sao lưu. Và đó không phải là một quyết định kỹ thuật, đó là một quyết định kinh doanh!

Nếu chủ doanh nghiệp của bạn đồng ý với việc mất một giờ hoặc nhiều hơn các giao dịch cơ sở dữ liệu của họ (có thể RẤT khó khăn hoặc không thể làm lại!) Thì mô hình của bạn sẽ hoạt động. Nếu họ ổn với hệ thống ngừng hoạt động trong nhiều giờ trong khi bạn khôi phục toàn bộ cơ sở dữ liệu từ bản sao lưu, thì mô hình của bạn sẽ hoạt động.

Tuy nhiên, nếu doanh nghiệp của bạn coi hệ thống ERP của họ là tài sản quan trọng cho hoạt động của họ (không phải tất cả sao?), Thì việc đặt thời gian phục hồi tối đa chấp nhận được (còn gọi là RTO, Mục tiêu thời gian phục hồi) cho các dịch vụ quan trọng của bạn sẽ là một quyết định kinh doanh.

Ngoài ra, chủ doanh nghiệp hoặc các bên liên quan trong hệ thống cần xác định số lượng dữ liệu họ sẵn sàng chịu rủi ro mất trong một sự cố, còn gọi là RPO (Mục tiêu điểm khôi phục).

Câu trả lời nếu bạn hỏi họ có thể là "KHÔNG có dữ liệu nào bị mất! Hệ thống ERP phải có sẵn 24/7/365!" ... mà tất cả chúng ta đều biết là rất khó có hiệu quả về chi phí. Nếu bạn đưa ra cho họ chi phí liên quan đến việc xây dựng một hệ thống hoàn toàn dự phòng, không ngừng nghỉ như vậy, họ sẽ đưa ra con số hợp lý hơn ..;)

Vấn đề là, nếu bạn có thể tránh mất bất kỳ giao dịch nào, bạn đang tiết kiệm doanh nghiệp của mình có khả năng hàng trăm hoặc hàng ngàn giờ làm việc bị mất. Số tiền này tiết kiệm rất lớn trong bất kỳ công ty nào và phát triển cùng với quy mô của công ty bạn ...

Mọi người đều có câu trả lời tuyệt vời cho vấn đề này, nhưng tôi muốn thêm một ghi chú quan trọng khác ... hoặc hai.

Biết các chi tiết của các mô hình phục hồi SQL Server và các yêu cầu kinh doanh của bạn về mất dữ liệu đều rất quan trọng; tuy nhiên, trong trường hợp này bắt buộc bạn phải hiểu cách sản phẩm sao lưu của bạn hoạt động với SQL Server. (Dựa trên các nhận xét ở trên, có vẻ như bạn đang sao lưu dung lượng ổ đĩa thông qua bản sao VSS, điều đó có nghĩa là sao lưu SQL Server có thể hoặc không cần thiết thêm vào.)

Gần đây đã đánh giá một sản phẩm tương tự, một số điểm quan trọng bạn có thể cần hỏi là:

• Làm thế nào để khôi phục được thực hiện đến một thời điểm cho một cơ sở dữ liệu trong phục hồi đầy đủ?
• Làm thế nào là sao lưu ban đầu được xử lý cho một cơ sở dữ liệu mới trong phục hồi đầy đủ?
• Sản phẩm sao lưu có yêu cầu sao lưu nhật ký SQL Server để khôi phục đến một thời điểm không? (Trong trường hợp của tôi, câu trả lời là có.)
• Cơ sở hạ tầng lưu trữ của bạn có thể xử lý khối lượng dữ liệu cho các bản sao / vi sai VSS (tại một khoảng nhất định) ngoài tải SQL thông thường không?

Hy vọng điều này là hữu ích.

Kinh nghiệm mà nhóm của tôi có với đánh giá gần đây của chúng tôi cung cấp một số câu trả lời rất thú vị cho các câu hỏi trên. Một điều chắc chắn là, các bản sao lưu phức tạp hơn đối với chúng tôi với một sản phẩm sao lưu VSS.

Như nhiều người khác đã nói, nếu bạn đang sử dụng công cụ của bên thứ ba để sao lưu / chụp nhanh VM hoặc bộ lưu trữ, bạn vẫn có nguy cơ không có bản sao lưu hợp lệ. Tất cả các công cụ của bên thứ ba quản lý sao lưu SQL Server sẽ triển khai và kết nối với SQL Server bằng VSS. Nó thực hiện điều này để yêu cầu SQL Server kiểm tra tất cả I / O cho các tệp dữ liệu để có thể chụp ảnh nhanh nhất quán. Nếu không, thì bạn có thể có nhiều giao dịch ở nhiều trạng thái khác nhau và khôi phục sẽ không biết liệu các giao dịch đó có thể được chuyển tiếp hay lùi lại.

Tôi chưa từng làm việc với mọi công cụ chụp nhanh VM / Storage của bên thứ ba ngoài đó, nhưng những công cụ tôi đã làm việc không bao giờ có thể chụp nhanh lưu trữ nơi Cơ sở dữ liệu hệ thống được đặt - SQL Server không thể kiểm tra các cơ sở dữ liệu đó. Họ TẤT CẢ đã sao lưu các cơ sở dữ liệu đó theo cách truyền phát - tức là ... ban hành các lệnh BACKUP DATABASE và sau đó chụp tệp sao lưu.

Trên hết, như nhiều người cũng đã nói, nếu bạn đang ở trong mô hình phục hồi ĐẦY ĐỦ và bạn không phát hành các câu lệnh BACKUP LOG thường xuyên, nhật ký giao dịch sẽ tiếp tục phát triển cho đến khi không còn chỗ trống trên đĩa.

Câu hỏi thực sự bạn cần được hỏi, và tôi có thể đã bỏ lỡ nó ở trên ... bạn đã khôi phục thành công từ các bản sao lưu này nhiều lần chưa và bạn có hài lòng với tính nhất quán của dữ liệu trong các lần khôi phục đó không. Cá nhân, ngay cả điều đó là không đủ đối với tôi, nó vẫn cảm thấy giống như một con xúc xắc, và đó là điều mà một DBA tốt không bao giờ có được khi sao lưu và phục hồi.

Nhận ra rằng nhật ký giao dịch không chỉ đơn giản là một cơ chế phục hồi. Bảo trì nhật ký thích hợp cũng có thể đóng một vai trò quan trọng trong hiệu suất cơ sở dữ liệu tổng thể (nghĩa là thông lượng giao dịch).

Thường xuyên sao lưu các tệp nhật ký của bạn thực hiện một số điều:

1. Nó làm giảm số lượng VLF trong các tệp nhật ký vật lý tốt cho hiệu suất.
2. Bạn nên chuẩn bị tốt hơn để sử dụng các bản sao lưu nhật ký trong trường hợp bạn cần khôi phục cơ sở dữ liệu.
3. Nó khá nhanh hơn một bản sao lưu đầy đủ

Nếu bạn có thể thoát khỏi việc thực hiện sao lưu toàn bộ hàng giờ thì bạn không chắc mình sẽ được hưởng lợi bao nhiêu từ các bản sao lưu nhật ký thường xuyên hơn. Sau khi tôi hiểu, một bản sao lưu đầy đủ cũng sẽ sao lưu càng nhiều nhật ký cần thiết để đảm bảo khôi phục hoàn toàn.

Mặt khác, nếu ứng dụng của bạn tạo ra vô số giao dịch ở giữa các bản sao lưu đầy đủ hàng giờ của bạn thì điều đó có thể giải thích tại sao các nhà phát triển ban đầu đề xuất bảo trì nhật ký chi tiết hơn. Rất nhiều giao dịch có thể tăng số lượng VLF trong nhật ký của bạn, điều này có thể bị phạt hiệu suất cho đến khi nhật ký bị cắt ngắn. Tôi đã thấy điều này được biểu thị dưới dạng lỗi 'hết thời gian truy vấn' trong một ứng dụng (không lâu trước khi nó bị treo).

Các khuyến nghị liên quan đến bảo trì nhật ký giao dịch được mô tả rất tốt trong bài viết này 8 bước để thông lượng nhật ký giao dịch tốt hơn . Ngoài ra, bài viết này Lời khuyên hàng đầu để bảo trì cơ sở dữ liệu hiệu quả đề cập đến số lượng VLF hơi tùy tiện để nhắm tới (<200) đã hoạt động rất tốt đối với tôi.

Những người khác đã đưa ra hầu hết các lý do cho một bản sao lưu translog, vv Có vẻ như có một số nghi ngờ về lý do tại sao đây là chiến lược tốt khi bạn đã sao lưu máy chủ.

Một vài lý do tốt đã đưa ra cho tôi mà không phải ở trên. Điều gì sẽ xảy ra nếu ứng dụng của bên thứ 3 không thể sao lưu mà bạn có thể khôi phục? Bạn đã cố gắng khôi phục lại bản sao lưu của mình chưa? Còn máy chủ mới bạn vừa xây dựng từ các mẫu của bạn (nghĩ DR) thì sao? Điều gì về một máy chủ khác trên miền của bạn có đối chiếu khác nhau? hoặc SQL dụ?

Tôi không sao lưu dự phòng mà không có lý do nào khác ngoài việc đôi khi ứng dụng bên thứ ba của bạn không phải là cách nhanh nhất để khôi phục. Đôi khi, bộ nhớ mà ứng dụng bên thứ 3 của bạn đang lưu cũng bị ảnh hưởng hoặc bị hỏng vì những lý do riêng.