Có bao nhiêu thiết bị sao lưu được khuyến nghị để cải thiện hiệu suất sao lưu?

Để cải thiện hiệu suất của các bản sao lưu SQL Server, chúng tôi sao lưu vào nhiều tệp sao lưu.

Trên hầu hết các bài đăng trên blog về chủ đề này, họ nói sẽ sử dụng nhiều tệp sao lưu, nhưng, có một điểm mà bạn có thể có quá nhiều tệp thay vì cải thiện hiệu suất, bạn sẽ có hiệu suất kém hơn do số lượng luồng lớn đang chờ?
Có bất kỳ khuyến nghị chung dựa trên, ví dụ, số lượng lõi trong máy chủ? Để cụ thể hơn, một trong những máy chủ của chúng tôi hiển thị BACKUPIOvà BACKUPBUFFERlà 2 người phạm tội hàng đầu chờ đợi thống kê.

Chúng tôi đang sao lưu một DB lớn (vài TB) bằng 10 tệp sao lưu, nhưng tôi nhận thấy máy chủ chỉ có 4 lõi và 32 GB RAM. Tôi đã thay đổi số lượng tệp sao lưu để sử dụng 4 tệp sao lưu thay thế. Tôi sẽ thấy nó diễn ra như thế nào vào tuần tới trong chu kỳ sao lưu tiếp theo, nhưng trong khi đó tôi đang cố gắng tìm bất kỳ đề xuất nào về số lượng tệp sao lưu sẽ sử dụng tùy thuộc vào thông số kỹ thuật của máy chủ.

sql-server backup

— Victor Barajas
nguồn

Câu trả lời:

Hãy giải quyết câu hỏi của bạn trước ...

Có một điểm mà bạn có thể có quá nhiều tệp thay vì cải thiện hiệu suất, bạn sẽ có hiệu suất kém nhất do số lượng luồng lớn đang chờ?

Số lượng luồng sao lưu phụ thuộc vào số lượng khối lượng logic được sử dụng cho các tệp cơ sở dữ liệu và số lượng thiết bị sao lưu. SQL Server hỗ trợ tối đa 64 thiết bị sao lưu cho một hoạt động sao lưu.

Vì vậy, khi bạn đang loại bỏ các bản sao lưu của mình, bạn đang tăng thông lượng. Đó là một nước cờ hay.

Có bất kỳ khuyến nghị chung dựa trên, ví dụ, số lượng lõi trong máy chủ?

Một ví dụ về các tệp và đĩa cân bằng cho hiệu suất sao lưu tốt từ bảng trắng tối ưu hóa sao lưu (lưu ý: đó là tài liệu từ) .

Những điều cần cân nhắc :

Kích hoạt khởi tạo tập tin tức thì.
Sử dụng nén sao lưu (máy chủ sql 2008 R2 trở lên có nén sao lưu trong phiên bản tiêu chuẩn). Nén sẽ tăng mức sử dụng CPU, vì vậy hãy đảm bảo bạn không có độ bão hòa CPU.
Thay đổi / điều chỉnh chiến lược sao lưu của bạn. Thay vì thực hiện sao lưu toàn bộ hàng ngày của cơ sở dữ liệu nhiều Terabyte, hãy nghĩ đến việc thực hiện khác biệt cùng với sao lưu nhật ký.
Trong môi trường thử nghiệm, chơi với BUFFERCOUNT(tổng số bộ đệm I / O) và MAXTRANSFERSIZE(đơn vị truyền lớn nhất tính bằng byte giữa máy chủ sql & phương tiện sao lưu) các tham số sao lưu cùng với cờ theo dõi 3605 & 3213.
Tham khảo câu trả lời của tôi SQL Backup điều chỉnh cơ sở dữ liệu lớn

Tư vấn thân thiện

Tôi nhận thấy máy chủ chỉ có 4 nhân và 32 GB RAM.

Vì bạn đang chạy một DB lớn (vài TB), 4 lõi và RAM 32 GB nghe có vẻ rất thấp. Tăng cường phần cứng của bạn.

Tham khảo :

— Kin Shah
nguồn

Dữ liệu của bảng này có vẻ lỗi thời. 2 lõi CPU cho mỗi tệp dữ liệu chắc chắn không được cân bằng trên các hệ thống ngày nay. Nói chung, câu lệnh đó cũng không thể đúng, bởi vì nó phụ thuộc vào tốc độ của đĩa và CPU. Các số trong bảng cảm thấy sai đến mức tôi nghĩ rằng nó sai.

— usr

Cũng phụ thuộc vào nén sao lưu. Nếu không có nó, một lõi có thể sao lưu 2GB / giây. Những con số này khác nhau, do đó, theo một thứ tự cường độ.

— usr

@usr dữ liệu bảng chỉ là một khuyến nghị chung theo whitepaper (tham chiếu máy chủ sql 2008). Chúng không hoàn toàn sai và nên được sử dụng như một điểm khởi đầu tốt. Bảng nói rằng một điểm khởi đầu tốt phải là ví dụ đối với hệ thống 2 lõi, cần có 2 tệp dữ liệu và 2 tệp sao lưu ... điều đó có gì sai? Sao lưu có thể được thực hiện nhanh hơn với buffercountvà loại maxtransfersizebỏ chúng.

— Kin Shah

Như một khuyến nghị chung, những con số này rất khủng khiếp vì những con số thực sự có thể sai lệch bởi một thứ tự cường độ. Đối với những gì sai với điều đó tôi sẽ đề cập đến câu trả lời của tôi, điều này giải thích tại sao những con số chung như vậy không thể tồn tại .

— usr

Tôi nghĩ rằng đó là một cách tiếp cận hiệu quả hơn nhiều để hiểu các quy tắc cơ bản và tại sao một số con số là tốt. Bằng cách đó, bạn thường có thể dự đoán chỉ bằng cách quay lại các tính toán của phong bì về các cài đặt phù hợp sẽ diễn ra. Ngoài ra, chỉ cần thử một số số và đo. Nhưng sao chép số từ một số hệ thống hoàn toàn khác mà không hiểu các nguyên tắc cơ bản là không đáng tin cậy.

— usr

Để cải thiện hiệu suất của các bản sao lưu SQL Server, chúng tôi sao lưu vào nhiều tệp sao lưu

Không nói chung, không. Đó là một kỹ thuật mục đích đặc biệt có thể giúp đỡ.

số lượng lớn các chủ đề đang chờ

Tại sao điều đó sẽ gây ra mất thông lượng? Chủ đề thường là một nguồn tài nguyên phong phú. Các vấn đề phát sinh trong các cấu hình nhất định trong đó bạn đốt cháy hàng trăm và vào hàng ngàn luồng.

dựa trên [số] số lõi trong máy chủ

Điều đó sẽ có ý nghĩa nếu hoạt động sao lưu bị ràng buộc CPU. Đó có thể là trường hợp. Miễn là IO bị ràng buộc, nó không thể giúp nhắm mục tiêu số lượng lõi với bất kỳ cài đặt nào.

một trong những máy chủ của chúng tôi hiển thị BACKUPIO và BACKUPBUFFER khi 2 người phạm tội hàng đầu thống kê chờ

Điều đó chỉ ra một quá trình sao lưu ràng buộc IO. Theo kinh nghiệm của tôi, nó phổ biến hơn nhiều so với giới hạn CPU.

một DB lớn (vài TB)

Kích thước của bản sao lưu không đóng một vai trò trong việc xem xét thông lượng. Thông lượng là hiệu suất trên mỗi đơn vị thời gian.

Chỉ có sự hiện diện của các luồng chờ thường không ảnh hưởng đến các luồng và hoạt động khác trên máy chủ. Chờ đợi chủ đề không làm gì.

vì vậy tôi đã thay đổi số lượng tệp sao lưu để sử dụng 4 tệp sao lưu thay thế

Điều đó là không có cơ sở vì sao lưu bị ràng buộc IO. Nhắm mục tiêu số lượng lõi không phải là một mục tiêu tốt.

Nếu bạn đã thêm 128 lõi CPU, bản sao lưu của bạn sẽ không trở nên nhanh hơn một giây.

Bạn có thể đã tăng hiệu suất nhưng chỉ vô tình.

Có bao nhiêu tệp sao lưu để sử dụng bị ảnh hưởng bởi nhiều thứ. Một cách dễ dàng để tìm một số tốt là chỉ cần kiểm tra các giá trị khác nhau, bao gồm 1 (giá trị rất có thể cho các hệ thống phổ biến).

— sử dụng
nguồn