SQL Server 2K / 2K5 / 2K8 і твердотілі диски: специфічна оптимізація?

Хтось тут працює з SQL Server на твердотільних накопичувачах? Ви знайшли якісь конкретні поради щодо оптимізації? Мене конкретно цікавлять способи зменшення частоти, з якою SQL Server виконує невеликі операції з випадковим записом, оскільки вони є враженням продуктивності SSD, зокрема дисками MLC SSD.

Звичайно, можна зробити декілька очевидних оптимізацій: дані з важких даних для читання повинні надходити з SSD, а важкі для запису речі слід залишати на традиційних спінінг-дисках. Це, природно, включає журнали транзакцій!

Зважаючи на достатній бюджет, звичайно, хочеться використовувати SLC-диски SSD, такі як X25-E або серія Vertex Ex або різні пропозиції на рівні підприємств. Але мене також цікавлять поради, які можуть принести користь настройкам MLC SSD. Я думаю, що це цікава область. Один з клієнтів моїх клієнтів має невеликий бюджет і набір даних, який зростає неабияк, і вони стикаються з повним переписом близько ста запитів, щоб підтримувати гідний рівень продуктивності. Однак у мене є підозрілість, що менше 500 доларів оперативної пам’яті та місця на SSD можуть принести їм більший приріст продуктивності, ніж тисячі (можливо, десятки тисяч) доларів, що варті часу розробника.

Не впевнений, що ви маєте на увазі, зменшуючи кількість маленьких, випадкових записів, які робить SQL Server. SQL Server виписує сторінки даних лише під час контрольних точок - тому єдиний спосіб обмежити кількість записів - це змінити інтервал контрольної точки або зробити не так багато операцій ВМС. Ви мали на увазі щось інше?

У всіх реалізаціях SSD, які я бачив (декілька), це щось протилежне тому, що ви пропонуєте - найкраще використання SSD-дисків, здається, для запису великих журналів транзакцій і tempdb - в основному, де найбільший я Вузьке вузьке місце підсистеми / O і вставити туди SSD - оскільки час і час затримки зводяться до низької постійної.

Ознайомтеся з цим дослідницьким документом, який склали MS (на жаль, не дуже детально про особливості SQL Server): Міграція зберігання сервера на SSD: Аналіз компромісів .

Сподіваюся, це допомагає!

Ви не можете змінювати характеристику вводу-виводу SQL-серверів. Основна одиниця доступу до диска для файлів даних - це 8Kb сторінка. Він пише їх здебільшого під час контрольного пункту, але також ліниво запише їх, коли зможе.
SQL не чекає завершення запису на диск даних перед поверненням, це лише запис журналу, який повинен бути завершений. Якщо ви можете зберегти на диску лише один журнал баз даних, це буде послідовне записування і буде нормально на звичайних швидких жорстких дисках.
Ударність продуктивності з точки зору SQL - це коли вона має читати диски. Якщо ви можете дати їй більше пам’яті, то SQL буде зберігати більше сторінок даних у пам'яті, що швидше, ніж будь-який диск, SSD або інше. Очевидно, ви також можете зменшити кількість прочитаних дисків, створивши відповідні індекси. Я сподіваюся, що SSD також допоможе в цих показаннях, оскільки вони, ймовірно, будуть випадковими і чекають, поки головки приводу будуть рухатися.
Я не знаю, про який розмір бази даних ми говоримо тут, але ви можете поглянути на HyperOS. Вони роблять сата-диски, які насправді є лише завантаженням оперативної палиці DDR2, із SSD або 2,5-дюймовим диском в якості резервної копії. Тоді схема доступу до сервера не матиме жодного значення. Я б не ставив журнали на щось подібне. Журнали - це те, що зберігає ваші дані консистентом, вони повинні працювати на надійному носії, і, незважаючи на резервне копіювання SSD та акумулятора, а сервер, ймовірно, має ДБЖ і т.д. у якомусь відмовному відбитті RAID-масиву.

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

При тривалих послідовних операціях стандартні диски працюють досить добре, тому не було б ніякої мети використовувати SSD (звичайно з точки зору продуктивності).

Тут не додайте точку додавання до теми коментарів, але якщо ви встановите розмір сторінки / кількість читання для БД для будь-чого на SSD, то це кратне розміру сторінки SSD, це не повинно бути проблемою.

Я довго не працював над SQL Server, тому не впевнений, чи є ці параметри там. Я займаюся Oracle і DB2 протягом останніх декількох років, і це вирішило б ваші занепокоєння, оскільки БД буде правильно налаштовано на характеристики диска.

Я рекомендую вирівняти розділ, де зберігаються файли бази даних.

Я також рекомендую визначити, що стосується RAID 0 для perf (ldf та TempDB), та розмістити критичні дані на RAID 1 (mdf).

По-третє, вам дійсно слід оновити прошивку диска, а також прошивку / драйвери контролера SATA. Тим самим ви даєте апаратній компанії та їх розробникам шанс оптимізувати для вас перф.