Я шукаю поради щодо найкращого способу настройки моїх дисків / розділів для SQL Server. Ось деякі мої основні проблеми:
Як слід відокремлювати файли SQL (файли даних, журнали, темп)?
Чи краще RAID багато HDD і розділити простір або зробити кілька RAID з меншою кількістю дисків для кожного RAID?
Чи повинні дані та файли журналу мати різний тип RAID?
Чи повинні бази даних за замовчуванням (master, msdb тощо) розміщуватися на C: чи вони повинні знаходитися там же, що й інші файли даних / журналу?
Відповіді:
Ось приємна публікація в блозі: http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html
Біла книга про вирівнювання диска: http://msdn.microsoft.com/en-us/library/dd758814.aspx
Якщо коротко, ваша ОС повинна бути на RAID 1, ваші файли даних на RAID 10 (бажано) та файли журналів на RAID 1.
Стаття про ефективність SQL: http://www.sql-server-performance.com/faq/raid_1_raid_5_p1.aspx
PDF в топ-10 найкращих порад щодо ефективності: http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf
Також не забудьте помістити свій TEMPDB на окремий диск з міркувань продуктивності. Я впевнений, що Пол Рандал зайде сюди і підірве ваш розум, чому трохи.
MS говорить, чому для tempdb: http://msdn.microsoft.com/en-us/library/ms175527.aspx
Це велике питання "це залежить".
Я не можу відповісти, як створити для вас індивідуальне питання RAID-масивів, оскільки я не є спеціалістом із зберігання даних, але можу допомогти вам у всьому.
Перше, що ви не маєте врахувати, - це навантаження на різні бази даних - OLTP (читання / запис) або DSS / DW (в основному для читання). Для завантаження / запису робочих навантажень слід дивитись на RAID 1 або RAID 10 (RAID 1 + 0), оскільки вони забезпечують надмірність та чудову ефективність читання / запису. Для робочих навантажень, які в основному читаються, ви можете використовувати RAID 5. Причиною, що RAID 5 не слід використовувати для навантаження читання / запису, є те, що ви сплачуєте певну ефективність за запис.
Журнали транзакцій за своєю суттю читаються / записуються (або в основному записуються, залежно від того, використовуєте ви журнал транзакцій для чогось - наприклад, резервного копіювання або реплікації), і тому ніколи не слід ставити на RAID 5.
Це означає, що для деяких баз даних та робочих навантажень у вас можуть бути файли даних на RAID 5 та файли журналів на RAID 1/10, а для інших баз даних у RAID 1/10 може бути все. Якщо у вас є база даних з розділеними даними, вона може містити деякі здебільшого дані для читання та деякі дані для читання / запису, можливо навіть у межах однієї таблиці. Це можна розділити на окремі файлові групи, а потім кожну групу файлів встановити на відповідному рівні RAID.
Розділення фактичних баз даних знову залежить від завантаженості, а можливостей базової підсистеми вводу-виводу - для зберігання речей в окремих масивах RAID може знадобитися більш високий ступінь відокремлення, ніж, наприклад, в SAN.
Tempdb - це окремий випадок самостійно, оскільки це, як правило, сильно завантажена база даних і повинна зберігатися окремо від інших баз даних. Системні бази даних не повинні активно використовуватися, і їх можна розміщувати в будь-якому місці, поки є надмірність.
Ось посилання на довідку, яку я допоміг написати, що має допомогти вам: Дизайн фізичного зберігання баз даних . Також переконайтеся, що ваша підсистема вводу- виводу може працювати з очікуваним навантаженням . Нарешті, переконайтесь, що ви використовуєте правильний розмір смужки RAID (зазвичай 64 Кб або вище у новіших системах), правильний розмір одиниці розподілу NTFS (зазвичай 64К), а також, що в системах до Windows Server 2008 правильно встановити зсув розділу диска . Для отримання інформації про них та вказівників на додаткову інформацію про них, і чому ви повинні їх налаштувати таким чином, дивіться це повідомлення в блозі: Чи правильно встановлені зрушення в розділі диска, розміри смуг RAID та одиниці розподілу NTFS? .
Рядок Bototm: знайдіть навантаження та свої можливості підсистеми вводу-виводу, а потім реалізуйте їх відповідно.
Сподіваюся, це вам корисно.
PS Що стосується tempdb, то це велика банка хробаків щодо того, як слід його налаштувати, і там є всіляка суперечлива інформація. Я написав вичерпну публікацію в блозі про конфігурацію файлів даних tempdb на Помилках навколо TF 1118 .
Коротка відповідь для серверів, які я створив, завжди була
Журнали на окремих фізичних дисках, рейд 1 або 10 (зачистка + дзеркальне відображення)
База даних на власних дисках, залежно від продуктивних потреб, як правило, RAID5
Багато кешу на рейдових контролерах
Переважно знову наклейте ОС і Windows Pagefile на окремий масив, зазвичай це просто дзеркало (Raid 1). Це робить усі операції запису відокремленими, тому велика продуктивність не перетягує все.
У минулому я відчував, що те, що база даних пише + журнал пише + сторінка пише, призведе до збиття масиву Raid5, а продуктивність піде на чорт у сумочку. Проблема полягає в тому, що ваша продуктивність буде чудовою при тестуванні, розробці і т. Д. Але коли ви вступите у виробництво та використання, то ця проблема з’явиться «не в синьому», а скарга користувачів зростає.
Тут набагато кращі хлопці MSSQL, ніж я, але загалом я пропоную наступне;
ОС і код на C: - це повинні бути локальні диски, повинна бути пара масивів RAID1 - ми використовуємо для цього 2 x 2,5-дюймові диски SAS 146GB 10krpm, але ви можете використовувати 2 x SATA 7.2 диски. Дані повинні знаходитись у досить швидкому (10krpm або вище) RAID 1/10, 5/50/6/60 масиві будь-якого розміру, який вам потрібен - ми тримаємо наші у FC SAN LUNs, як правило, на дисковій групі 2-го рівня / 10krpm . Журнали повинні бути на окремій ДУЖЕ Швидкій (15кр / хв) невеликій (10 Гб або менше?) RAID 1-масив масиву - ми тримаємо нашу на FC SAN LUNs, як правило, на дуже маленькій дисковій групі tier1 / 15krpm або на 'tier0' / ssd група.
У будь-якому випадку ви хочете, щоб кожен з них був на окремих шпинделях / масивах для продуктивності - звичайно, все буде працювати на одному диску, але я думаю, ви шукаєте баланс продуктивності та вартості.
Ми зберігаємо наш головний / tempdb з нашими звичайними базами даних, але ви можете розбити його на окремий масив даних LUN.
Сподіваюсь, це допомагає.