ВикторррrmkaХотелось бы свести все основополагающие рекомендации вместе.
1. 10 дисков делим на 5 зеркал
2. 1-е зеркало - данные используемые для оперативных действий
2-е зеркало - лог транзакций
3-е зеркало - tempdb
4-е зеркало - индексы
5-е зеркало - данные используемые для отчётов
3. tempdb = 20-30% от размера БД
4. Именованный кэш для tempdb надо подбирать ~ 500М
5. Именованный кэш для для лога транзакций надо подбирать ~ 50М
6. Именованный кэш для для постоянно используемых нагруженных таблиц... не всегда помогает
7. Настройка пулов. если строница 2К, то для default кэш соотношение пулов 2к/16к примерно 1/3 (1/4) (подбирать по sysmon).
8. Настройка пулов. если строница 2К, то для tempdb кэш соотношение пулов 2к/16к примерно 1/2 (1/3) (подбирать по sysmon).
9. После этого смотрим запросы отчётов и всего остального, т.к. 80% тормозов это кривые запросы.

п. 1-2. А рейд 10 уровня не более эффективно использовать? Ведь он позволяет размазать данные по всем дискам и тем самым повысить количество iops?
п. 5. Этого еще не сделал, вопрос как? Ведь именованный кеш можно (в централе) связать с базой данных, таблицей и индексом. А с логом как?
п. 6. Вчера прописал, но уже вижу, что кеши пустые. Может быть дело в стратегии кеша? У меня везде strict LRU replacement. Какая стратегия должна быть на default cache, на temp db, на кэше для для лога транзакций и кеше для таблиц (ведь в нем данные должны накапливаться)???
п. 7-8. Т.е. 16 к пулы должны быть в 2-3 раза больше чем 2к???

>п. 1-2. А рейд 10 уровня не более эффективно использовать? Ведь он позволяет размазать данные по всем дискам и тем самым повысить количество iops?
Не эфективно. Есть опыт 5 рэйда, тормоза с БД на 100Гб в 2 раза больше чем на 3-х отдельных дисках. На рэйд размазывается всё вместе и лог транзакций и данные и темпдб и в случае рэйда паралелизм сильно страдает. К примеру при большом количестве запросов для связки таблиц используются индексы, и данные не нужны, а данные нужны только конечного результата. Теперь посмотрим как будет выполняться такой запрос с точки зрения использования дисковой подсистемы. Индексы считаются с зеркала индексов (паралельно 2X), темпдб запись темповых таблиц со скорость 1X, считывание 2X, далее запись в лог (нет записи если это селект, и 1X если апдейт), считывание данных с оперативного сегмента данных 2X, считывание данных с неоперативного сегментаданных 2X. Фактически паралельно делается почти всё, что рэйд никак не обеспечит, т.к. у него и данные и индексы и лог, частично лежать на одном и томже диске, это это уже самое узкое место.
2. Рэйд не безопасно, как бы его не хвалили. Отказывает контроллер рэйда. всё смерть на месте, рэйд уже не соберёшь ни при каких условиях, а если ещё хотябы и один из дисков...


3. п. 5. можно связать с логом. Немного погорячился с размером кэша для лога.

EXEC sp_cacheconfig bcsc_log, "7M", "logonly"
/*Чтобы зарезервировать кэш для обслуживания только журнала
транзакций, измените тип кэша на “logonly”. В следующем примере
создается кэш bcsc_log, имеющий тип “logonly”:*/
EXEC sp_poolconfig bcsc_log, "3M", "32K"

цитата и sybase
"Создайте именованный кэш для журналов часто используемых баз
данных. Сконфигурируйте пулы в этом кэше в соответствии с разме-
ром буфера ввода-вывода журнала, установленным процедурой
sp_logiosize."

3. Стратегию кэша в большинстве случаем оставляют по умолчанию.
> что кеши пустые
в sp_sysmon смотришь процент использования кэша, хороший результат больше 96-100%
4.
>16 к пулы должны быть в 2-3 раза больше чем 2к???
Да, но зависит от преобладающих запросов, в основном данные выбираются большими блоками, соотношение опять же смотриться по sp_sysmon.
5
>а размер лога для для рабочей базы
Размер лога зависит от длительности транзакций, их количестве и стратегии согдания бэкапа лога транзакций. В нагруженных базах с с требованием минимального времени простоя бэкап лога транзакций может делаться каждые 15 мин, следовательно иметь большой лог не целесообразно, однако надо смотреть на длительность транзакций и как быстро заполняется лог.
для темпдб лог не имеет большого смысла т.к. на то он и тэмп дб чтобы хранить темповую инфу, а важные опрерации логируются в основном логе.

Жаль что Винда стоит, можно было бы сделать виртуальный диск в памяти (15.5 уже умеет так делать) и положить на него темпдб, и тогда просто летать будет.
ещё можно SSD диски отдельно поставить и хранить на них сильно загруженные на селекты таблицы.
ещё можно разбивать таблицы на партишены и хранить их на разных дисках для паралельного чтения.
Но, всёравно считаю, что большинство тормозов из-за неадекватных запросов, неграмотного использования индексов и триггеров.