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

Кто-нибудь здесь работает с SQL Server на твердотельных дисках? Нашли какие-нибудь конкретные советы по оптимизации? Я особенно заинтересован в том, чтобы уменьшить частоту, с которой SQL Server выполняет небольшие операции произвольной записи, так как они являются критикой производительности SSD, особенно SSD-дисков MLC.

Конечно, можно сделать несколько очевидных оптимизаций: данные с большим объемом чтения должны подаваться с SSD, а материалы с большим объемом записи должны быть оставлены традиционным вращающимся дискам. Это включает в себя журналы транзакций, естественно!

Конечно, при достаточном бюджете можно было бы использовать SSD-диски SLC, такие как серии X25-E или Vertex Ex, или различные предложения корпоративного уровня. Но меня также интересуют советы, которые могут помочь настройкам SSD MLC. Я думаю, что это интересная область. У одного из клиентов моих клиентов небольшой бюджет и огромный набор данных, и им приходится полностью переписывать около ста запросов, чтобы поддерживать достойный уровень производительности. Тем не менее, у меня есть подозрение, что оперативная память и пространство на SSD менее 500 долларов могут принести им больший прирост производительности, чем время разработки (возможно, десятки тысяч) долларов.

Не уверен, что вы имеете в виду, уменьшая количество небольших случайных записей, которые делает SQL Server. SQL Server записывает страницы данных только во время контрольных точек - поэтому единственный способ ограничить количество записей - это изменить интервал контрольных точек или не так много операций IUD. Вы имели в виду что-то еще?

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

Ознакомьтесь с этой исследовательской статьей, созданной MS (к сожалению, не очень подробно описывающей специфику SQL Server): Перенос серверного хранилища на твердотельные накопители: анализ компромиссов .

Надеюсь это поможет!

Вы не можете изменять характеристики ввода-вывода SQL Server. Основной единицей доступа к диску для файлов данных является страница размером 8 КБ. Он будет писать их в основном во время контрольной точки, но также будет писать их лениво, когда сможет.
SQL не ожидает завершения записи на диск данных перед возвратом, а только запись в журнал, которая должна быть завершена. Если вы можете хранить только один журнал базы данных на диске, то это будет последовательная запись и будет нормально на обычных быстрых жестких дисках.
С точки зрения SQL, производительность падает, когда ему приходится читать диски. Если вы можете дать ему больше памяти, тогда SQL будет хранить больше страниц данных в памяти, что быстрее, чем любой другой тип диска, SSD или другой. Очевидно, что вы также можете уменьшить количество операций чтения с диска, создав соответствующие индексы. Я ожидаю, что SSD также поможет с этими чтениями, потому что они, вероятно, будут случайными и задерживаются в ожидании перемещения головок дисков.
Я не знаю, о каком размере базы данных мы говорим здесь, но, возможно, вы захотите взглянуть на HyperOS. Они делают диски SATA, которые на самом деле являются просто набором оперативной памяти DDR2, с SSD или 2,5-дюймовым диском в качестве резервной копии. Тогда схема доступа к серверу не будет иметь значения. Я бы не ставил логи на что-то подобное. Журналы - это то, что поддерживает ваши данные в целостности, они должны работать на надежном носителе, и, несмотря на резервное копирование SSD и батареи, а также на сервер, возможно, с ИБП и т. Д., Я все равно чувствую себя нелегко из-за отсутствия журналов на реальном жестком диске. в каком-то отказоустойчивом RAID-массиве.

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

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

Здесь пока нет смысла добавлять в ветку комментариев, но если вы зададите размер страницы / количество прочитанных БД для всего, что на SSD, кратным размеру страницы SSD, это не должно быть проблемой.

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

Я бы порекомендовал выровнять раздел, где хранятся файлы базы данных.

Я также рекомендовал бы решить, что идет на RAID 0 для perf (ldf и TempDB), и поместить критические данные на RAID 1 (mdf).

В-третьих, вам действительно нужно обновить прошивку накопителя, а также прошивку / драйверы контроллера SATA. Тем самым вы даете компании-производителю оборудования и ее разработчикам возможность оптимизировать работу для вас.