Стратегии организации SQL Server с большим объемом оперативной памяти

Теперь у нас есть новый сервер для нашей БД, и среди прочего у нас доступно 128 ГБ ОЗУ (ранее у меня было 16 ГБ). Я знаю, что SQL Server очень хорошо справляется с управлением своими ресурсами, но мне было интересно, есть ли какие-либо специальные настройки или стратегии, которые я должен использовать либо в настройках сервера / БД, либо в коде обработки (сохраненные процы / индексы и т. Д.), Чтобы гарантировать, что SS принимает лучшее преимущество имеющегося барана.

БД составляет около 70 ГБ и не является транзакционной (это хранилище данных). Так что в основном большой WRITE, за которым следует массивный READ, - это нормальный поток вещей.

Несмотря на то, что у вас есть запасная память на данный момент (база данных 70 ГБ против сервера 128 ГБ), я все равно настроил бы ее maximum server memoryсогласно последним указаниям .

... зарезервируйте 1 ГБ ОЗУ для ОС, 1 ГБ на каждые 4 ГБ ОЗУ, установленного на 4–16 ГБ, а затем 1 ГБ на каждые 8 ​​ГБ ОЗУ, установленного выше 16 ГБ.

Это равно 110 ГБ на сервере 128 ГБ. Причиной является то, что хранилище данных, вероятно, будет продолжать расти и в конечном итоге может захватить больше, чем вы хотите, поэтому установите правильный предел сейчас. Иначе будет забыто.

Когда ваш объем данных выходит за пределы 110 ГБ, обратите больше внимания на свободную память серверов. Если у вас постоянно есть запасные ГБ, вы можете рассмотреть возможность увеличения лимита на несколько ГБ.

Кроме этого, у вас есть только другие варианты тонкой настройки с флагами трассировки, к которым следует относиться с осторожностью, которой они заслуживают. Тестируйте, тестируйте и тестируйте еще.

Три кандидата, о которых я могу подумать, имеют смысл:

• TF834 - Распределение больших страниц
• TF2301 - Расширения моделирования процессора запросов (обычно хорошо для OLAP, потенциально проблематично для OLTP )
• TF4199 - изменения в оптимизаторе запросов

Как уже упоминалось в ответе ранее, Томас Кейсер упоминает TF834 как «Серверы SQL Server» переключаются только «быстрее». TF2301 обеспечивает оптимизацию, полезную для запросов типа DW. TF4199 требует прочтения связанного документа , поэтому