Оптимальна конфігурація накопичувача для SQL Server 2008R2

У мене досить зайнятий сервер баз даних, на якому працює SQL Server 2008 R2, який має такі налаштування:

• SATA RAID 1 (2 диски) - ОС / програми
• SAS RAID 10 (4 диски) - файли бази даних Sql (дані та журнали)
• SAS RAID 1 (2 диски) - TempDB (дані та журнали)

Якщо припустити, що я не можу додавати додаткові диски на цей сервер, чи я найкраще скористався доступною конфігурацією? Чи варто розглянути іншу схему, де журнали ізольовані, наприклад, від файлів даних?

Оновлення:

Для тих, хто вимагає додаткових деталей обладнання:

• SATA-накопичувачі (використовуються для ОС / Програми розділу): WD 7200 RPM 3 Гбіт / с 3,5-дюймовий SATA
• Пристрої SAS, що використовуються в інших масивах, є: Seagate 15K RPM 6 Гбіт / с 3,5 дюймовим SAS
• Використовуваний контролер RAID - це порт LSI 9260-8i SAS / SATA 6 Gb 8

Оновлення 2:

Виходячи з відгуку, який я отримав, схоже, що у мене є наступні життєздатні варіанти - я присуджую нагороду тому, хто зможе сказати мені, що, можливо, буде найкращим у тому середовищі, яке я окреслив:

1. Залиште все так, як є - я, мабуть, краще не зроблю
2. Перемістіть мої 2 диски SAS RAID 1 у мій існуючий масив RAID 10, щоб він складався з 6 дисків загалом
3. Перемістити мої файли журналів на SAS RAID 1 та / або перемістити TempDB (дані або журнали) назад до RAID 10

Варіанти цього питання виникають напіврегулярно:

• Збірка SQL Server
• Допоможіть мені вибрати комбінацію рівня RAID для екземпляра SQL Server 2008
• Як я повинен налаштувати ці диски на SQL Server для конфігурації BI?

Існують також періодичні поєдинки з бантами з приводу розділення даних / журналу "найкраща практика".

• Розміщення журналу транзакцій на окремому томі [твердий стан]?
• SQL Server - розділення файлів даних, журналу та TempDB в SAN

Без більш детального аналізу того, що робить цей сервер, застосовуються ті самі поради, що і раніше.

• RAID 1 для ОС
• RAID 10 (6 диск) для даних / журналів / tempdb

Рідко є якась точка розколу з такою кількістю доступних шпинделів. Один масив із більшою ємністю ВГД, як правило, намочує грудочки та грудочки вашої навантаження краще, ніж 2 менші масиви.

Один з варіантів, який може бути вартим тестування, - це розміщення tempdb на дисководі ОС. Зробіть це лише в тому випадку, якщо у вас є репрезентативна навантаження, яку ви можете повторно повторювати, щоб забезпечити справедливе порівняння конфігурації. Якщо ви дотримуєтеся цієї домовленості у виробництві, переконайтесь, що зростання tempdb обмежений, щоб ви ненароком не витрачали весь вільний простір на накопичувачі ОС.

З огляду на те, що ваші диски ОС - це 7200RPM, я буду здивований, якщо налаштування tempdb на накопичувачі ОС матиме якусь користь.

Все залежить від вашої завантаженості, але, маючи лише 6 дисків, це обмежує ваші можливості. Якщо ваше навантаження не сильно залежить від tempdb для таких речей, як сортування, хеш-таблиці та ізоляція знімків, можливо, вам буде краще використовувати 6 приводів SAS разом у RAID 10. Однак, якщо ви знаєте чи маєте показники, щоб довести це tempdb сильно використовується, то вам слід тримати його окремо, як у вас є.

Це дуже залежить від того, що ви маєте на увазі під "дуже зайнятим": різні схеми навантаження (пишіть важкі чи ні, масові операції звичайні чи ні, рівень одночасного доступу, якщо назвати, але три з багатьох змінних) можуть мати різкий вплив на виконання будь-якої заданої шпинделя.

У важкій ситуації запису відокремлення журналів від даних може суттєво змінитись, оскільки кожне записування передбачає оновлення як журналу, так і файлів даних, тому передбачає велику кількість додаткового гортання голови, якщо обидва набори файлів знаходяться на одному наборі шпинделів .

Без додаткового посилання на ваше навантаження (та специфікацію цих накопичувачів та будь-який контролер, який знаходиться між ними та машиною), я схильний би перейти на три томи: один для ОС + програми та tempdb (дані), один для основної БД даних, третій - для журналів (як tempdb, так і основні БД).

Звичайно, якщо ваші робочі навантаження дуже легкі на операціях запису, тоді вам не слід витрачати занадто багато часу на занепокоєння щодо збереження даних і журналів розділеними, оскільки це призведе до невеликої різниці в продуктивності, а виділення цілого обсягу для них буде досить марно доступним простір.

Фактична відповідь залежить від ваших потреб, але, як правило, "розміщення даних і ведення журналу на різних масивах" має більш важливе значення, ніж "розміщення tempdb у власному масиві".

З огляду на кількість наявних дисків, моєю відправною точкою буде:

1. Два накопичувачі, RAID 1 - Операційна система, виконувані файли, файл сторінки.
2. Чотири диски, RAID 5 - усі файли даних (альтернативно, RAID 1 + 0)
3. Два накопичувачі, RAID 1 - Усі файли журналу

Що потрібно зробити, це використовувати SQLIO для перевірки працездатності різних конфігурацій приводу.

Залежно від того, для чого ви використовуєте БД для (OLTP проти складування), ваш конфігурація виглядає як хороша загальна конфігурація. Якби у вас було більше дисків, у вас було б більше варіантів.

Ви можете досягти кращої продуктивності, якщо переключити диск для свого TempDB на RAID 0 (смуга). Це збільшує ризик відмови, але оскільки TempDB буферує лише дані, ви не можете зазнати втрати даних. Тому більшість людей вважають це розумним компромісом. Просто тримайте запас (або гарячий запас).

Одне, що ви не згадували, але можете спробувати (якщо ви ще цього не зробили): Microsoft рекомендує розділити ваш TempDB на кілька файлів (один на центральний процесор). Звичайно, найкраще, якщо вони знаходяться на окремих дисках, але просто мати окремі файли допомагає. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx