Thiết lập phân vùng đĩa / phân vùng được đề xuất cho SQL Server

Tôi đang tìm kiếm một số lời khuyên về cách tốt nhất để thiết lập đĩa / phân vùng cho SQL Server. Đây là một số mối quan tâm chính của tôi:

Các tệp SQL nên được phân tách như thế nào (tệp dữ liệu, nhật ký, temp)?

Liệu có tốt hơn để RAID nhiều ổ cứng và phân vùng không gian hoặc tạo nhiều RAID với ít đĩa hơn cho mỗi RAID không?

Dữ liệu và tệp nhật ký có nên thuộc loại RAID khác không?

Các cơ sở dữ liệu mặc định (master, msdb, v.v ...) nên được đặt trên C: hoặc chúng nên ở cùng một nơi với các tệp dữ liệu / nhật ký khác?

Đây là một bài đăng blog hay: http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html

Giấy trắng về căn chỉnh đĩa: http://msdn.microsoft.com/en-us/l Library / dd758814.aspx

Nói tóm lại, hệ điều hành của bạn phải có trên RAID 1, các tệp dữ liệu của bạn trên RAID 10 (tốt nhất là) và các tệp nhật ký trên RAID 1.

Bài viết về Hiệu suất SQL: http://www.sql-server-performance.com/faq/ston_1_ston_5_p1.aspx

PDF trên 10 mẹo hiệu suất tốt nhất: http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf

Cũng nhớ đặt TEMPDB của bạn trên một đĩa riêng vì lý do hiệu suất. Tôi chắc chắn Paul Randal sẽ đến đây và thổi bay tâm trí của bạn với lý do tại sao một chút.

MS nói tại sao cho tempdb: http://msdn.microsoft.com/en-us/l Library / ms175527.aspx

Đây là một câu hỏi lớn 'nó phụ thuộc'.

Tôi không thể trả lời cách tạo câu hỏi mảng RAID riêng cho bạn, vì tôi không phải là chuyên gia lưu trữ, nhưng tôi có thể giúp bạn phần còn lại.

Điều đầu tiên bạn cần xem xét là khối lượng công việc trên các cơ sở dữ liệu khác nhau - OLTP (đọc / ghi) hoặc DSS / DW (chủ yếu là đọc). Đối với khối lượng công việc đọc / ghi, bạn nên xem RAID 1 hoặc RAID 10 (RAID 1 + 0), vì chúng cung cấp dự phòng và hiệu suất đọc / ghi tuyệt vời. Đối với khối lượng công việc chủ yếu là đọc, bạn có thể sử dụng RAID 5. Lý do không nên sử dụng RAID 5 cho khối lượng công việc đọc / ghi là bạn phải trả tiền phạt hiệu suất khi ghi.

Nhật ký giao dịch, về bản chất là đọc / ghi (hoặc chủ yếu là ghi, tùy thuộc vào việc bạn đang sử dụng nhật ký giao dịch cho bất cứ điều gì - ví dụ: sao lưu nhật ký hoặc sao chép) và vì vậy không bao giờ nên đưa vào RAID 5.

Điều này có nghĩa là đối với một số cơ sở dữ liệu và khối lượng công việc, bạn có thể có các tệp dữ liệu trên RAID 5 và các tệp nhật ký trên RAID 1/10 và đối với các cơ sở dữ liệu khác, bạn có thể có mọi thứ trên RAID 1/10. Đi xa hơn, nếu bạn có một cơ sở dữ liệu được phân vùng, nó có thể chứa một số dữ liệu chủ yếu là đọc và ghi, thậm chí có thể trong cùng một bảng. Điều này có thể được chia thành các nhóm fileg riêng biệt và sau đó mỗi fileggroup đưa vào một cấp độ RAID phù hợp.

Việc tách cơ sở dữ liệu thực tế một lần nữa phụ thuộc vào khối lượng công việc và khả năng của hệ thống con IO cơ bản - có thể cần một mức độ phân tách cao hơn để lưu trữ mọi thứ trên các mảng RAID riêng lẻ so với SAN.

Tempdb là một trường hợp đặc biệt, vì nó thường là một cơ sở dữ liệu được tải nặng và nên được lưu trữ tách biệt với các cơ sở dữ liệu khác. Các cơ sở dữ liệu hệ thống không nên được sử dụng nhiều và có thể được đặt ở bất cứ đâu miễn là có dự phòng.

Đây là một liên kết đến một whitepaper tôi đã viết để giúp bạn: Thiết kế lưu trữ cơ sở dữ liệu vật lý . Ngoài ra, hãy đảm bảo hệ thống con IO của bạn có thể xử lý khối lượng công việc dự kiến ​​- xem bảng trắng này: Thực hành tốt nhất I / O dự đoán . Cuối cùng, hãy đảm bảo rằng bạn sử dụng kích thước dải RAID chính xác (thường là 64K trở lên trên các hệ thống mới hơn), kích thước đơn vị phân bổ NTFS chính xác (thường là 64K) và trên các hệ thống trước Windows Server 2008, bạn đặt chính xác phân vùng đĩa . Để biết thông tin về những điều này và gợi ý thêm thông tin về chúng và tại sao bạn nên định cấu hình chúng theo cách này, hãy xem bài đăng trên blog này: Các phân vùng đĩa của bạn có được bù đắp, kích thước sọc RAID và đơn vị phân bổ NTFS được đặt chính xác không? .

Dòng Bototm: biết khối lượng công việc của bạn và khả năng của hệ thống con IO của bạn và sau đó thực hiện theo.

Tôi hy vọng điều này hữu ích cho bạn.

PS Liên quan đến tempdb, đó là một con sâu lớn về cách bạn nên cấu hình nó và có tất cả các loại thông tin mâu thuẫn. Tôi đã viết một bài đăng blog toàn diện về cấu hình tệp dữ liệu tempdb tại Quan niệm sai lầm xung quanh TF 1118 .

Câu trả lời ngắn gọn cho các máy chủ tôi đã thiết lập luôn là

Đăng nhập vào các đĩa vật lý riêng biệt, đột kích 1 hoặc 10 (tước + phản chiếu)

Cơ sở dữ liệu trên các đĩa riêng, tùy thuộc vào nhu cầu hiệu năng thường là RAID5

Rất nhiều bộ nhớ cache trên (các) bộ điều khiển đột kích

Tốt nhất là dán lại HĐH và Windows Pagefile của bạn trên một mảng riêng biệt, thường chỉ là một bản sao (Raid 1). Điều này giữ cho tất cả các hoạt động ghi được phân tách để hiệu suất nặng không kéo mọi thứ xuống.

Những gì tôi đã trải qua trong quá khứ là việc có cơ sở dữ liệu ghi + ghi nhật ký + ghi trang sẽ ghi lại một mảng Raid5 và hiệu suất sẽ bị chậm lại trong một cái khăn tay. Vấn đề là hiệu suất của bạn sẽ ổn trong thử nghiệm, dev, v.v. Nhưng khi bạn bắt đầu sản xuất và sử dụng skyrockets, vấn đề này sẽ xuất hiện "hết màu xanh" và khiếu nại của người dùng tăng vọt.

Có những người MSSQL tốt hơn nhiều ở đây hơn tôi nhưng nói chung, tôi đề nghị như sau;

Hệ điều hành và mã trên C: - đây phải là đĩa cục bộ, phải là cặp mảng RAID1 - chúng tôi sử dụng đĩa 2 x 2,5 inch SAS 146GB 10krpm cho việc này nhưng bạn có thể sử dụng 2 x SATA 7.2. Dữ liệu phải có tốc độ khá nhanh (10krpm hoặc tốt hơn) RAID 1/10, 5/50/6/60 với bất kỳ kích thước nào bạn cần - chúng tôi giữ chúng tôi trên FC SAN LUNs, thường là trên nhóm đĩa 'tier 2' / 10krpm . Các bản ghi phải ở một cặp RAID 1 RẤT NHANH (15krpm) nhỏ (10GB hoặc ít hơn?) - chúng tôi giữ các nhóm trên FC SAN LUN, thường là trên nhóm đĩa 'tier1' / 15krpm rất nhỏ hoặc trên 'tier0' / nhóm ssd.

Dù bằng cách nào bạn cũng muốn mỗi phần của chúng trên các trục / mảng riêng biệt để thực hiện - tất nhiên tất cả sẽ hoạt động trên một đĩa đơn nhưng tôi đoán bạn đang tìm kiếm sự cân bằng giữa hiệu suất và chi phí.

Chúng tôi lưu trữ master / tempdb của chúng tôi với cơ sở dữ liệu thông thường của chúng tôi nhưng bạn có thể chia nó thành một mảng dữ liệu LUN riêng.

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