В чем суть, хотим купить SSD для одного не очень важного сервера, бюджет ограничен, сейчас там все на обычных дисках, три рейда 1 и один 10 рейд. Так вот если посмотреть io_virtual_stats по чтению самая нагруженная база это tempdb, write stall у всех 4 файлов (лежат они вместе) в 3 три раза выше чем у DB_One (назовем ее так), но Read в раз 10 меньше чем у DB_One, у которой Read_stall самый большой. DB_One лежит отдельно от tempdb, но вместе с DB_Two которая по нагрузка примерно равна DB_One.
Итго рейд 1.1 - система, рейд 1.2 tepmdb с кучей остальных мелких баз, рейд 1.3 Логи всех баз, рейд 10 DB_One и DB_Two, файлы данных. Надо как-то эту свалку разобрать, и тут у нас с коллегами возник спор:
1) Я предлагаю купить один SSD на 512 (в tempdb очень много пишется во время разных загрузок она бывает до 200-400 ГБ вырастает), если он полетит ничего страшного, их устравивает остановка в рабочее время на 10-20 минут. После переноса DB_One перенести на рейд 1.2 где был tempd. DB_Two весит очень много и ее не перенести.
2) Коллеги предлагают, купить два SDD по 256, сделать 1 рейд, засунуть туда DB_One и ничего больше не трогать.
3) Предлагают просто купить оперативы (не вариант конечно).
Добавлю, что 50 самых тяжелых запросов в плане IO, если посмотреть по планам, в большинстве вствка во временные таблицы и update временных таблиц.

Добавлю, что по типам ожиданий, если не брать cxpacket, Buckup* и т.д. останется PAGEIOLATCH и WRITELOG. Оперативы сейчас 70 под SQL, если покупать то это 32 примерно можно купить или ССД, деньги только на одно.
Запросы корявые до жути, но никто ничего трогать не будет. Вопрос только в железках.

a_shats,

Сумарно, в 5 файлов (4 + лог) за сутки примерно 80-100 гигов пишется. Там идут постоянные загрузки, архитектура конечно странная, как я понял, загрузка идет сначала в tempdb, там данные агрегируются, где нужно что-то считается, опять же все это грузится во временные таблицы и потом какая-та часть этих данных грузится в базы. При этом эти временные таблицы еще висят какое-то время, пока идут разные проверки. Прикол в том что все эти загрузки идут постоянно, т.е. и в рабочее время. Как они идут это просто шик тоже, загрузка запускается, разом штук 20-25 может быть, делает какую-то часть, потом waitfor на час и ждем пока не выполнится другая загрузка или еще какая нибудь хрень, на вопрос What the fu** разработчики говорят типа: "Я художник, я так вижу".
Сейчас Avg Write Stall у файлов tempdb 900, тогда как у главной базы в районе 100.
Плюс эти художники за каким то повешали на каждый FK индексы. Т.е. обсолютно на каждом во всех таблицах, best practice видать. То есть таблица широка, 70-80 стобцеов, 40 это FK, ссылки на разные справочники в которые практически всегда идут только вставки, оттуда ничего не удаляется практически и PK не обновляется, т.е. обрашения к основной таблицы для проверки нет, а вот в таблицу с этими 40 FK вставки идут постоянно, в итоге смотрим статистику по индексам, несколько сотен тысяч обновлений у каждого и ни одного seek или scan. Решил проверить, на тесте вставка только с clustered 10000 строк заняла примерно 6 сек с холодным кэшем, добавил 40 индексов 20 с копейками секунд на холодном. Еще местные админы предлагали разрабам создать несколько FG и раскидать их по разным рейдам (сейчас все в primary) эти творческие люди сказали что так делать нельзя.

alexeyvg,

Т.е. к примеру один файл на 10 рейде из 8 будет лучше чем два файла на 2х 10 рейдов из 4, при условии что нагрузка на эти файлы будет примерно равна?
Суть в том, что в этой БД структура такая: таблиц 50 основные, широки, на каждых до фига FK, практически у каждой таблицы свой набор справочников которые практически всегда используются лишь этой таблицей. Как я писал есть множество загрузок, которые пашут считай всегда, идея была в том чтобы взять несколько таблиц, к которым редко обращаются юзеры, но в которые много грузится (такие есть) и связанных с ними справочников и перенести на одтельный рейд. Это также уменьшить время простоя когда все полетит, ибо Enterprise.

alexeyvg,

А все умные книги говорят что надо распределять по разным FG и дискам, никому нельзя верить :(
Как вы писали выше "А уж что бы делить по файлгруппам и т.п. - это должно быть совсем много накопителей, сотни-тысячи.", в таком случае какая выгода, ведь получается эти сотни также "распределит эту нагрузку на все диски с гарантией"?
Просто с железом редко занимался, везде где работал это делал другой отдел, поэтому тут небольшие пробелы, буду благодарен если просветите.