Tôi có thể thêm gì vào máy chủ để giúp SQL khôi phục nhanh hơn?


8

Tôi có cơ sở dữ liệu SQL 2,8TB (chủ yếu là các tệp dữ liệu, khoảng 400 GB tệp nhật ký) hiện mất khoảng 9 giờ để khôi phục. Cơ sở dữ liệu này được sử dụng cho mục đích thử nghiệm và phải được xóa và khôi phục từ bản sao lưu giữa mỗi lần chạy, để đảm bảo chúng tôi luôn bắt đầu từ cùng một điểm.

Câu hỏi của tôi là, máy chủ hiện có 12 nhân và 92GB RAM, với hệ thống con đĩa RAID 5 mà cơ sở dữ liệu đang bật. Khu vực nào thường gây ra tắc nghẽn cho các quy trình khôi phục SQL? Nó là đĩa, bộ nhớ hay CPU?


3
Phương tiện sao lưu nào bạn đang khôi phục? Bằng cách này, RAID 5 phải chịu một hình phạt ghi nặng khi so sánh với hầu hết các cấp RAID khác, vì vậy đây có thể không phải là cách tốt nhất để kiểm tra hiệu năng.
Chris McKeown

Các .bak (8 trong số chúng tách ra) nằm trên cùng một mảng RAID 5 chúng đang được khôi phục, điều này khiến tôi nhận ra mình có thể xử lý việc đó tốt hơn trong tương lai. Tôi không có một mảng khác đủ lớn để chứa tất cả .bak, nhưng tôi có thể chia chúng thành các ổ gắn trực tiếp khác nhau. Ngoài ra, điểm hay về RAID 5. Tôi biết điều đó, nhưng chúng tôi vẫn chưa thực hiện kiểm tra căng thẳng nên sẽ ổn nếu nó bị tắc nghẽn tại ổ đĩa ngay bây giờ trong các bài kiểm tra tải thực tế. Khi chúng tôi tiến xa hơn một chút, chúng tôi sẽ tăng hiệu suất đĩa thông qua SAN, RAID 0 hoặc RAID 1 + 0
Sean Long

2
Chắc chắn sự đau khổ của bạn quá mức khi có các bản sao lưu trên ổ đĩa bạn cũng đang khôi phục. Có bao nhiêu đĩa trong RAID5 hiện tại của bạn?
Mark Storey-Smith

Vì vậy, bạn đang sử dụng nén, tôi sẽ giả sử. Những tùy chọn sao lưu khác bạn đang sử dụng? Dữ liệu của bạn được phân vùng như thế nào? Bạn có thể phân phối dữ liệu thông minh giữa các nhóm tệp (sau đó bạn có thể thực hiện sao lưu nhóm tệp và khôi phục dữ liệu đã thay đổi) không?
swasheck

Vấn đề là các bài kiểm tra chạm vào một tỷ lệ rất lớn của cơ sở dữ liệu, vì vậy chúng tôi sẽ phải khôi phục trên nhiều nhóm tệp (và các bài kiểm tra sẽ thay đổi dựa trên nhu cầu và sự phát triển của khối lượng công việc). Vì vậy, chúng tôi sẽ phải liên tục nhìn vào trang điểm thử nghiệm và khôi phục các nhóm tập tin cụ thể. Mặc dù đó là một lựa chọn, tôi không chắc nó sẽ mua cho chúng tôi nhiều thời gian tiết kiệm.
Sean Long

Câu trả lời:


6

Nút cổ chai chính của bạn khi khôi phục sẽ là IO đĩa. Để khắc phục rằng về cơ bản bạn cần đĩa nhanh hơn hoặc cấu hình khác. Tôi không biết đủ về RAID hoặc SAN để đề xuất bất cứ điều gì ở đó. Bạn thậm chí có thể xem xét SSD. Họ đang nhanh chóng mù quáng. Tôi sẽ không muốn sử dụng chúng trên một cái gì đó không được tạo lại một cách thường xuyên (tempdb luôn là một ứng cử viên tốt cho việc này) nhưng vì bạn khôi phục nó thường xuyên nên có thể ổn. Mặt khác, bạn có thể muốn đảm bảo rằng máy chủ thử nghiệm của bạn càng gần càng tốt với máy chủ sản xuất của bạn nếu bạn đang thực hiện kiểm tra hiệu suất.

Có một vài điều khác bạn có thể làm để giúp mình. Trước tiên hãy nén các bản sao lưu của bạn nếu bạn chưa có. Điều này tất nhiên giả định SQL 2008 hoặc cao hơn. Nó sẽ giảm không chỉ không gian đĩa để lưu trữ bản sao lưu mà cả IO để đọc nó. Có một chi phí CPU liên quan vì vậy hãy lưu ý. Cũng đừng xóa cơ sở dữ liệu của bạn, chỉ cần khôi phục lại nó. Bằng cách này, các tệp đã được đặt đúng chỗ và không có chi phí để tạo chúng. Bạn có thể bật khởi tạo tệp tức thì (Đó là quyền cấp máy chủ) để tăng tốc đáng kể việc tạo / tăng trưởng tệp cho tệp dữ liệu của bạn nhưng nó sẽ không hoạt động đối với tệp nhật ký của bạn.


Thông tin tốt, tôi đã không nhận ra rằng khôi phục lại hiện tại tốt hơn là bỏ / khôi phục từ bản sao lưu. Chúng tôi đã sử dụng tính năng nén và tôi dự định xác minh rằng khởi tạo tệp tức thì được bật cho tài khoản thực hiện khôi phục. Tôi thực sự đánh giá cao sự rõ ràng của câu trả lời của bạn, cảm ơn!
Sean Long

Đảm bảo rằng khởi tạo tệp tức thì cũng được bật trên tài khoản chạy SQL Server. Đối với một cơ sở dữ liệu nhỏ, nó có thể không phải là một vấn đề lớn, nhưng đối với một cái gì đó kích thước bạn đang xem nó có thể tạo ra một sự khác biệt lớn.
Kenneth Fisher

Cuộc gọi tốt Cũng cảm ơn vì đã nhận ra rằng kiểm tra hiệu suất không phải lúc nào cũng có nghĩa là kiểm tra căng thẳng (và hiện tại tôi khá bị giới hạn bởi cách cấu hình sản xuất của tôi được thiết lập).
Sean Long

OT: "xem xét SSD. ... Tôi sẽ không muốn sử dụng chúng trên một cái gì đó không được tạo lại một cách thường xuyên" ... tại sao?
Martin

Tôi vẫn sẽ lo lắng về việc họ thất bại. Tất cả mọi thứ tôi đã đọc đều nói rằng sử dụng chúng cho cơ sở dữ liệu như tempdb, được tạo lại mỗi khi phiên bản bắt đầu, nhưng không sử dụng chúng cho cơ sở dữ liệu người dùng thông thường. Mặc dù tôi chắc chắn rằng điều đó đang thay đổi theo thời gian.
Kenneth Fisher

7

Đừng sao lưu và khôi phục; sử dụng Ảnh chụp nhanh máy chủ SQL. Phải mất rất nhiều dung lượng đĩa để lưu trữ một tệp thưa thớt có cùng kích thước với các tệp bạn đã chụp, nhưng quay lại nhanh hơn hàng trăm lần.

Chúng có sẵn trong phiên bản SQL Server Enterprise và SQL Server Developer.


Đó là một ý tưởng tốt, và nếu đây là bất kỳ máy chủ nào khác ngoài máy chủ kiểm tra hiệu năng, thì đó có vẻ là một cách tuyệt vời để đi. Tuy nhiên, có vẻ như ảnh chụp nhanh DB sẽ không hoạt động vì nó sẽ gây ra thêm chi phí cho DB nguồn mà tôi không thể có. Việc kiểm tra đang được thực hiện là kiểm tra hiệu suất (tải, ứng suất, v.v.) vì vậy chúng tôi phải tránh mọi thứ bên ngoài có thể gây căng thẳng.

Cá nhân tôi đã không nhận thấy bất kỳ sự khác biệt về hiệu suất khi có một ảnh chụp nhanh, nhưng tôi đoán rằng sao chép trên ghi có một số chi phí; không biết khối lượng công việc của bạn, tôi không thể đánh giá.
Mark Henderson

2
Đề xuất của @SeanLong Mark có lẽ là lựa chọn tốt nhất cho kịch bản của bạn. Những gì tôi nghĩ bạn hiểu lầm là khi nào và những gì bạn chụp ảnh nhanh. Kế hoạch trên máy chủ thử nghiệm sẽ là khôi phục cơ sở dữ liệu kiểm tra từ bản sao lưu trực tiếp của bạn, sau đó chụp nhanh cơ sở dữ liệu kiểm tra, chạy chu trình kiểm tra của bạn, sau đó hoàn nguyên ảnh chụp nhanh, rửa và lặp lại. Định kỳ bạn có thể quay lại bước 1 và khôi phục bản sao lưu trực tiếp để kiểm tra lại.
Mark Storey-Smith

Ah tôi thấy. Tôi nghĩ rằng việc duy trì ảnh chụp nhanh đòi hỏi một lượng chi phí không đổi từ cơ sở dữ liệu kiểm tra, điều này sẽ ảnh hưởng đến các lần tải (rất nặng / đọc) của chúng tôi. Tôi không phiền nếu khối lượng công việc của chúng tôi gây ra tắc nghẽn tại ổ đĩa, tôi chỉ không muốn một yếu tố bên ngoài (mà tôi nghĩ rằng snap snapshot sẽ là) để gây ra nó.
Sean Long
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.