Nhật ký giao dịch Sao lưu nối tiếp hay song song?

Chúng tôi tình cờ sử dụng SQL Server 2012 Standard Edition. Tôi cũng tình cờ sử dụng các tập lệnh của Ola Hallengren để cung cấp một khung dễ dàng, linh hoạt hơn để thực hiện sao lưu và bảo trì.

Câu hỏi này không quá nhiều về các kịch bản của Ola vì chúng là về một thực tiễn tốt nhất. Tôi nhận ra câu trả lời cuối cùng là "nó phụ thuộc vào yêu cầu của công ty bạn". Nhưng tôi đang cố gắng tìm kiếm lời khuyên của cộng đồng về cách tốt nhất để thực hiện những gì tôi hiểu về các yêu cầu của công ty chúng tôi.

Tôi muốn thiết lập sao lưu nhật ký giao dịch cứ sau 15 phút. Bằng cách này, chúng tôi hy vọng sẽ mất không quá 15 phút dữ liệu. Tôi có nên thiết lập một công việc sử dụng ALL_DATABASES không? hoặc tốt hơn là thiết lập một công việc cho mỗi cơ sở dữ liệu và loại bỏ chúng song song? Tôi hỏi, bởi vì tôi có cảm giác dựa trên cách tôi thấy kịch bản của Ola hoạt động mà các bản sao lưu được khởi động nối tiếp. Nhược điểm của nối tiếp sẽ là mỗi bản sao lưu liên tiếp chờ đợi cho đến khi cái khác hoàn thành. Điều này có khả năng có thể tăng lượng thời gian giữa các lần sao lưu (nghĩa là lớn hơn 15 phút). Thêm vào đó, mối quan tâm của tôi là sự thất bại trong một bản sao lưu sẽ ngăn những người khác xảy ra và tôi không muốn điều đó xảy ra. Tôi muốn những người khác tiếp tục sao lưu.

Vì vậy, có đúng là các tập lệnh của Ola thực thi nối tiếp và cũng là một lỗi dừng các bản sao lưu liên tiếp?

Và nó là tốt hơn để có một công việc cho mỗi cơ sở dữ liệu? hoặc một công việc duy nhất làm tất cả? Xu hướng của tôi là hướng tới các công việc riêng biệt, nhưng tôi muốn hiểu về những gì DBA của SQL Server nói chung có xu hướng làm.

Tôi có nên thiết lập một công việc sử dụng ALL_DATABASES không? hoặc tốt hơn là thiết lập một công việc cho mỗi cơ sở dữ liệu và loại bỏ chúng song song?

Tôi sẽ đề nghị thiết lập một công việc sẽ sao lưu nhật ký giao dịch (theo kiểu thanh toán). Điều này cũng sẽ đảm bảo sao lưu không tiện ích nhiều cho I / O vì bạn đang chạy sao lưu cơ sở dữ liệu cùng một lúc.

Điều gì có thể là nhược điểm có thể xảy ra với việc chạy song song

1. Giả sử bạn có 50 cơ sở dữ liệu và bạn lên lịch sao lưu nhật ký giao dịch của tất cả các cơ sở dữ liệu và tất cả chúng bắt đầu chạy song song, điều này chắc chắn sẽ sử dụng rất nhiều I / O. Và nếu đĩa mà nó đang sao lưu các tệp xảy ra có các tệp dữ liệu khác, bạn sẽ thấy sự chậm chạp. Tôi đã thấy sao lưu trở nên chậm khi một truy vấn kém yêu cầu nhiều I / O chạy cùng với công việc sao lưu.

2. Một lần nữa, giả sử bạn có 50 cơ sở dữ liệu, sẽ không khó để quản lý 50 công việc trong tác nhân SQL Server và điều gì sẽ là điều kiện nếu bạn có 100-200 cơ sở dữ liệu, tôi sẽ không thích nó khi bạn mở tác nhân SQL Server và thấy nhiều công việc, chỉ cần giữ nó đơn giản Tôi chắc chắn trường hợp tương tự sẽ được với bạn.

Nhược điểm của nối tiếp sẽ là mỗi bản sao lưu liên tiếp chờ đợi cho đến khi cái khác hoàn thành. Điều này có khả năng có thể tăng lượng thời gian giữa các lần sao lưu (nghĩa là lớn hơn 15 phút).

Sao lưu nhật ký giao dịch hầu hết là nhỏ và nếu bạn có một cơ sở dữ liệu bận rộn tạo ra nhiều bản ghi nhật ký, bạn có thể cần phải thay đổi tần suất sao lưu. Hầu như tôi đã thấy sao lưu nhật ký giao dịch hoàn thành tốt khi tần suất là 15 phút. Tôi không nghĩ nên quan tâm đến bạn.

Thêm vào đó, mối quan tâm của tôi là sự thất bại trong một bản sao lưu sẽ ngăn những người khác xảy ra và tôi không muốn đó là trường hợp

Tôi sẽ nói rằng đừng lo lắng về nó. Sao lưu nhật ký giao dịch chỉ không thể thất bại trừ khi bạn mắc một số sai lầm. Những sai lầm có thể là

1. Chủ sở hữu đang chạy công việc được xóa khỏi AD

2. Ai đó đã thay đổi mô hình phục hồi của cơ sở dữ liệu.

3. Dung lượng đĩa không đủ

Ngoài ra, tôi không thấy bất kỳ lý do nào để sao lưu nhật ký giao dịch không thành công. Nó rất mạnh mẽ, bạn có thể dựa vào nó.

Nói chung, luôn luôn chạy các bản sao lưu T-log của bạn nối tiếp; nhiều phiên bản của tôi có một vài chục cơ sở dữ liệu và một số cơ sở rất tích cực và các bản sao lưu nhật ký giao dịch chỉ mất vài giây; lên đến nửa phút hoặc lâu hơn khi nó đặc biệt bận rộn.

Chạy các bản sao lưu song song chỉ thực sự có ích nếu tất cả các điều kiện sau là đúng:

• Tất cả các cơ sở dữ liệu và tệp nhật ký của bạn đều nằm trên các trục độc lập duy nhất (hoặc trên các đĩa trạng thái rắn trong bất kỳ kết hợp nào)

  • Đối với chỉ sao lưu T-log, chỉ các tệp nhật ký sẽ cần phải đáp ứng yêu cầu này.

• Các mục tiêu sao lưu của bạn cho mỗi cơ sở dữ liệu nằm trên các trục chính riêng biệt.

• Bạn không sử dụng SAN HBA hoặc iSCSI được chia sẻ hoặc băng thông khác giữa phiên bản SQL Server và phương tiện truyền thông.

• tức là IOPS từ việc đọc Cơ sở dữ liệu A và viết Sao lưu A KHÔNG sử dụng cùng các đĩa như đọc Cơ sở dữ liệu B và viết Sao lưu B.

Nếu tất cả những điều này là đúng, thì có thể một mức độ song song nào đó sẽ làm giảm tổng thời gian lịch. Nếu tất cả những điều này là không đúng, nhiều khả năng bạn sẽ khiến một hoặc nhiều bộ đĩa bị phá hủy và các bản sao lưu song song của bạn thực sự sẽ mất nhiều thời gian hơn so với nối tiếp, nhưng cũng có thể gây ra sự phân mảnh cấp hệ điều hành hoặc mức lưu trữ, bởi vì bạn đang viết Sao lưu A và Sao lưu B cùng một lúc!

Đừng lo lắng về một lần sao lưu thất bại và phần còn lại thành công - nếu có thất bại, bạn vẫn cần kiểm tra mọi thứ và lần duy nhất tôi thấy sao lưu thất bại là do:

• Lỗi đĩa

• Lỗi phần mềm nén Hyperbac / Litespeed / bên thứ ba (nếu bạn có phần mềm giữa SQL và đĩa bị lỗi)

  • Như một cảnh báo, sự thất bại có thể ở dạng một công việc sao lưu không bao giờ kết thúc, do đó, có một số kiểm tra cho "các công việc chạy lâu hơn dự kiến" gửi thông báo là có giá trị.

• Lỗi sản phẩm mã hóa (nếu bạn có phần mềm giữa SQL và đĩa bị lỗi)

• Lỗi mạng (nếu tệp cơ sở dữ liệu, hoặc nhiều khả năng là tệp sao lưu, nằm trên mạng)

• Quyền

  • phổ biến nhất với cài đặt hoàn toàn mới

  • hoặc vị trí sao lưu hoàn toàn mới

  • thay đổi người dùng Dịch vụ máy chủ SQL (đây là điều cần có quyền cho các bản sao lưu thông thường)

  • khóa người dùng dịch vụ SQL Server vì nó được sử dụng bởi nhiều hơn một phiên bản SQL Server

• Lỗi cấu hình

• Mất điện

• Sự cố hệ điều hành

Hầu hết trong số đó sẽ không ảnh hưởng đến một và không phải những người khác trừ khi các điều kiện trên cũng được đáp ứng.

Chỉ cần thêm, Ola thiết kế các tập lệnh của mình trong đó nếu một bản sao lưu cơ sở dữ liệu không thể sao lưu vì bất kỳ lý do gì, thì (các) tiếp theo sẽ được thử. Như đã nêu trước đó, bạn có thể có một cảnh báo được thiết lập để thông báo cho bạn về thất bại công việc vì công việc sao lưu vẫn thất bại, ngay cả khi chỉ có một bản sao lưu cơ sở dữ liệu bị lỗi trong tất cả các cơ sở dữ liệu người dùng - giả sử bạn đang sao lưu tất cả các cơ sở dữ liệu (một công việc cho tất cả).