Cấu hình ổ đĩa tối ưu cho SQL Server 2008R2

19

Tôi có một máy chủ cơ sở dữ liệu khá bận rộn chạy SQL Server 2008 R2 có cài đặt sau:

SATA RAID 1 (2 ổ đĩa) - Hệ điều hành / chương trình
SAS RAID 10 (4 ổ đĩa) - Tệp cơ sở dữ liệu Sql (dữ liệu và nhật ký)
SAS RAID 1 (2 ổ đĩa) - TempDB (dữ liệu và nhật ký)

Giả sử tôi không thể thêm ổ đĩa bổ sung vào máy chủ này, tôi đã sử dụng tốt nhất cấu hình tôi có sẵn chưa? Hoặc tôi nên xem xét một sơ đồ khác ở đây, nơi các bản ghi được cách ly khỏi các tệp dữ liệu, ví dụ?

Cập nhật:

Đối với những người yêu cầu thêm chi tiết phần cứng:

Các ổ đĩa SATA (được sử dụng cho phân vùng HĐH / Chương trình) là: WD 7200 RPM 3 Gb / s 3,5 inch SATA
Các ổ đĩa SAS được sử dụng trong các mảng khác là: Seagate 15K RPM 6 Gb / s 3.5 inch SAS
Bộ điều khiển RAID được sử dụng là: Cổng LSI 9260-8i SAS / SATA 6 Gb 8

Cập nhật 2:

Dựa trên phản hồi tôi đã nhận được, có vẻ như tôi có các tùy chọn khả thi sau đây để lựa chọn - Tôi sẽ trao tiền thưởng cho ai đó có thể cho tôi biết khả năng nào là tốt nhất trong môi trường mà tôi đã vạch ra:

Để lại mọi thứ như hiện tại - tôi có lẽ sẽ không làm tốt hơn nhiều
Di chuyển 2 ổ đĩa RAID 1 SAS của tôi vào mảng RAID 10 hiện tại của tôi để có tổng cộng 6 đĩa
Di chuyển các tệp nhật ký của tôi vào SAS RAID 1 và / hoặc di chuyển TempDB (dữ liệu hoặc nhật ký) trở lại RAID 10

sql-server hardware

— DanP
nguồn

Bản cập nhật thứ 2 của bạn đang hỏi chính xác các câu hỏi giống như câu hỏi ban đầu của bạn, vì vậy câu trả lời ban đầu được áp dụng. "... có khả năng là tốt nhất trong môi trường mà tôi đã vạch ra" ... bạn chưa cho chúng tôi thấy bất kỳ phân tích nào về khối lượng công việc, chỉ là nó "khá bận", nên một lần nữa câu trả lời tương tự được áp dụng .

— Mark Storey-Smith

Với NVMe hiệu suất cao và các ổ đĩa SSD khác trên thị trường, RAID không còn quá quan trọng trong quan điểm Thực tiễn tốt nhất về cấu hình đĩa của máy chủ SQL . Disk Pools (Storage Spaces) là cách để đi tiếp. Tuy nhiên, bạn cần phải phân tách hợp lý các ổ đĩa để khắc phục sự cố hiệu suất liên quan đến đĩa tốt hơn.

— Khuôn mặt của CNTT

14

Các biến thể của câu hỏi này xuất hiện bán thường xuyên:

Thỉnh thoảng cũng có những cuộc cãi vã về việc tách dữ liệu / nhật ký "thực hành tốt nhất".

Không có phân tích chi tiết hơn về những gì máy chủ này đang làm, lời khuyên tương tự được áp dụng như được đưa ra trước đây.

RAID 1 cho hệ điều hành
RAID 10 (6 đĩa) cho dữ liệu / nhật ký / tempdb

Hiếm khi có bất kỳ điểm nào trong một phân chia với rất ít cọc có sẵn. Một mảng duy nhất có công suất IOP lớn hơn thường sẽ hấp thụ các khối và khối lượng công việc của bạn tốt hơn 2 mảng nhỏ hơn.

Một biến thể có thể đáng thử nghiệm là đưa tempdb vào ổ đĩa hệ điều hành. Chỉ làm như vậy nếu bạn có khối lượng công việc đại diện mà bạn có thể phát lại nhiều lần, để đảm bảo so sánh công bằng về cấu hình. Nếu bạn thực hiện sắp xếp này trong sản xuất, hãy đảm bảo tăng trưởng tempdb bị hạn chế để bạn vô tình tiêu thụ hết dung lượng trống trên ổ đĩa hệ điều hành.

Cho rằng các ổ đĩa hệ điều hành của bạn là 7200RPM đế lót ly, tôi sẽ ngạc nhiên nếu tempdb trên cấu hình ổ đĩa OS mang lại bất kỳ lợi ích nào.

— Mark Storey-Smith
nguồn

7

Tất cả phụ thuộc vào khối lượng công việc của bạn, nhưng chỉ với 6 ổ đĩa, nó sẽ giới hạn các tùy chọn của bạn. Nếu khối lượng công việc của bạn không phụ thuộc nhiều vào tempdb cho những thứ như sắp xếp, bảng băm và cách ly ảnh chụp nhanh, thì bạn có thể sử dụng các ổ 6 SAS cùng nhau trong RAID 10. Tuy nhiên, nếu bạn biết hoặc có các số liệu để chứng minh rằng tempdb được sử dụng rất nhiều, sau đó bạn nên giữ nó tách biệt như bạn có.

— Patrick Keisler
nguồn

Cảm ơn câu trả lời, việc thay đổi cấu hình của các phạm vi là (không may) không phải là một tùy chọn vì máy chủ này đang được sản xuất. Tôi tò mò về việc chuyển tempdb trở lại RAID 10 và đặt tất cả các tệp nhật ký vào RAID 1 - đây có phải là một lựa chọn thông minh không?

— DanP

2

Hãy nhớ rằng SQL Server cần ghi vật lý tất cả các giao dịch vào nhật ký như một phần của cam kết, vì vậy bạn muốn hiệu suất ghi nhanh nhất có thể trong cấu hình của mình. RAID 10 cung cấp hiệu suất ghi tốt hơn RAID 1, vì vậy tôi sẽ để các bản ghi trên ổ đĩa nhanh hơn.

— Patrick Keisler

2

Nó phụ thuộc rất nhiều vào ý nghĩa của bạn bởi "rất bận": các mẫu khối lượng công việc khác nhau (viết nặng hay không, hoạt động hàng loạt có phổ biến hay không, mức độ truy cập đồng thời, để đặt tên nhưng ba trong số nhiều biến) có thể có tác động mạnh mẽ đến hiệu suất của bất kỳ sắp xếp trục chính cho trước.

Đối với tình huống ghi nặng, việc tách các nhật ký khỏi dữ liệu có thể tạo ra sự khác biệt đáng kể vì mỗi lần ghi liên quan đến việc cập nhật cả nhật ký và tệp dữ liệu, do đó liên quan đến một số lượng lớn đầu lật nếu cả hai bộ tệp nằm trên cùng một bộ trục chính .

Không cần tham khảo thêm về khối lượng công việc của bạn (và thông số kỹ thuật của các ổ đĩa đó và bất kỳ bộ điều khiển nào nằm giữa chúng và máy) Tôi sẽ có xu hướng sử dụng ba tập: một cho các chương trình OS + và tempdb (dữ liệu), một cho DB chính dữ liệu và thứ ba cho các bản ghi (cả tempdb và DB chính).

Tất nhiên, nếu khối lượng công việc của bạn rất nhẹ cho các thao tác ghi thì bạn không nên dành quá nhiều thời gian để lo lắng về việc giữ dữ liệu và nhật ký riêng biệt, vì nó sẽ tạo ra sự khác biệt nhỏ về hiệu suất và dành toàn bộ khối lượng cho chúng sẽ khá lãng phí không gian.

— David Spillett
nguồn

Tôi chắc chắn sẽ mô tả môi trường của chúng tôi là một "viết nặng" - tôi sẽ cập nhật câu hỏi của tôi với thông số kỹ thuật phần cứng chi tiết hơn vào thứ Hai.

— DanP

Bất cứ ý tưởng về số lượng ổ đĩa mà OP có? Tôi đang nghĩ nhiều hơn về Raid 1 mà anh ta có cho các tệp nhật ký. Điều đó không có vẻ là một lựa chọn tuyệt vời cho mục đích ghi và các tệp nhật ký AFAIK không bị giới hạn đọc, nhưng hãy viết ..

— Marian

Tôi đã thêm thông số kỹ thuật bổ sung về phần cứng của máy.

— DanP

1

Sự hiểu lầm này có thể là gốc rễ của nhiều ý kiến phân tách dữ liệu / nhật ký, vì vậy xin lỗi nhưng tôi sẽ gọi nó ra. "... vì mỗi lần ghi liên quan đến việc cập nhật cả nhật ký và tệp dữ liệu" - không, không. Ghi vào các trang dữ liệu xảy ra trên điểm kiểm tra, không phải trên mỗi sửa đổi.

— Mark Storey-Smith

1

@DavidSpillett Đúng, sẽ luôn có trường hợp chia tách có lợi. Điều quan trọng là bạn đã kiểm tra và xác nhận rằng cấu hình có lợi cho khối lượng công việc cụ thể đó.

— Mark Storey-Smith

2

Câu trả lời thực tế phụ thuộc vào nhu cầu của bạn nhưng nhìn chung "đặt dữ liệu và đăng nhập vào các mảng khác nhau" có tầm quan trọng cao hơn so với "đặt tempdb trên mảng riêng".

Với số lượng ổ đĩa bạn có sẵn, điểm bắt đầu của tôi sẽ là:

Hai ổ đĩa, RAID 1 - Hệ điều hành, tệp thực thi, pagefile.
Bốn ổ đĩa, RAID 5 - Tất cả các tệp dữ liệu (cách khác, RAID 1 + 0)
Hai ổ đĩa, RAID 1 - Tất cả các tệp nhật ký

Điều nên làm là sử dụng SQLIO để kiểm tra hiệu năng của các cấu hình ổ đĩa khác nhau.

— Greenstone Walker
nguồn

Điều này chắc chắn đại diện cho "mặt khác" của lời khuyên tôi đã đọc. Tôi ước có một phương pháp dứt khoát để xác định lựa chọn nào sẽ tốt hơn mà không cần dùng đến "dùng thử" trong môi trường sản xuất.

— DanP

2

@DanP Vâng, cá nhân tôi đã đi theo lời khuyên của Mark và chọn RAID10 với các ổ còn lại (trừ HĐH). Các tệp nhật ký được ghi chuyên sâu và cần hiệu năng tốt hơn so với những gì RAID 1 cung cấp, theo như tôi nghĩ về nó. Nhưng tôi không phải là một chuyên gia phần cứng. Chỉ 2 xu của tôi.

— Mary

2

Tôi nên đề cập rằng ý kiến của tôi chỉ xuất phát từ kinh nghiệm của một quá khứ (loại) di chuyển thất bại sang một máy chủ tốt hơn, nhưng với hiệu suất kém hơn. Chúng tôi chưa bao giờ thử tải thực sự trên máy chủ mới này, chúng tôi chưa bao giờ có cơ hội, máy chủ chưa sẵn sàng đúng giờ. Hóa ra máy chủ thử nghiệm TRƯỚC KHI di chuyển sang sản xuất phải là BẮT BUỘC. Xin lỗi vì sự nhấn mạnh. Vì vậy, câu thần chú của tôi cho tất cả các lần di chuyển / nâng cấp là: KIỂM TRA, KIỂM TRA, KIỂM TRA, ... thử nghiệm kỳ dị nhất có thể.

— Mary

1

Không chắc chắn nên bắt đầu với RAID 5 hay SQLIOSIM ... chúng ta hãy đi với phần sau vì cái trước nói cho chính nó. SQLIOSIM là một công cụ kiểm tra chính xác và căng thẳng , nó không phải là một công cụ kiểm tra hiệu năng hoặc tải. Nó hoàn toàn không có chỗ trong việc so sánh hiệu suất của config-X so với config-Y cho khối lượng công việc-Z. Tất cả những gì sẽ cho bạn biết là config-X hoạt động tốt như thế nào so với config-Y khi chạy SQLIOSIM. Nếu bạn muốn so sánh hiệu suất cho khối lượng công việc-Z, hãy kiểm tra khối lượng công việc-Z.

— Mark Storey-Smith

1

@GreenstoneWalker "RAID1 viết nhanh hơn RAID1 + 0" là vô nghĩa. Ý tưởng này đến từ đâu?

— Mark Storey-Smith

-1

Tùy thuộc vào những gì bạn đang sử dụng DB cho (OLTP so với kho), cấu hình của bạn trông giống như một cấu hình chung tốt. Nếu bạn có nhiều đĩa hơn, bạn sẽ có nhiều lựa chọn hơn.

Bạn có thể có hiệu suất tốt hơn nếu bạn chuyển đĩa cho TempDB sang RAID 0 (sọc). Nó làm tăng nguy cơ thất bại của bạn, nhưng vì TempDB chỉ đệm dữ liệu, bạn không thể bị mất dữ liệu. Vì vậy, hầu hết mọi người coi đó là một sự đánh đổi hợp lý. Chỉ cần giữ một phụ tùng xung quanh (hoặc một phụ tùng nóng).

Một điều bạn chưa đề cập, nhưng có thể thử (nếu bạn chưa có): Microsoft khuyên bạn nên chia TempDB của bạn lên trên một số tệp (mỗi tệp cho mỗi CPU). Tất nhiên, tốt nhất là nếu chúng nằm trên các đĩa riêng biệt, nhưng chỉ cần có các tệp riêng biệt sẽ giúp ích. http://msdn.microsoft.com/en-us/l Library / ms175527 (v = Vista.105).aspx

— TimG
nguồn

4

Tempdb được sử dụng cho nhiều thứ, nhưng đừng coi nó là cơ sở dữ liệu bỏ đi và đặt nó vào RAID 0. Hãy nhớ rằng nếu khối lượng RAID 0 bị lỗi, SQL Server sẽ không thể khởi động.

— Patrick Keisler

Tôi thực sự đã tạo một db temp cho mỗi lõi như được đề xuất, nhưng cảm ơn vì đã nâng cao điểm đó :)

— DanP

1

Vâng, những gợi ý này không tốt lắm và không phù hợp với mọi môi trường. Đầu tiên được đề cập bởi @PatrickKeisler trước đó. Thứ hai là một huyền thoại mà Paul Randal đã trình làng cách đây một thời gian. Bài viết này là một: Một huyền thoại DBA của SQL Server mỗi ngày: (12/30) tempdb phải luôn có một tệp dữ liệu cho mỗi lõi bộ xử lý . Vì vậy, tài liệu MS có thể sai, đừng lấy nó làm trái tim.

— Mary

2

"vì TempDB chỉ đệm dữ liệu, bạn không thể bị mất dữ liệu" ... và tôi chắc chắn rằng người dùng hệ thống sẽ đánh giá cao rằng trong X giờ ngừng hoạt động mà họ phải chịu trong khi a) hoạt động trong tầng hầm cho một đĩa thay thế hoặc b) một DBA cố gắng giải thích cho bộ phận trợ giúp cách di chuyển tempdb, từ điện thoại di động của anh ta.

— Mark Storey-Smith