SQL Server - принудительно БД в памяти?

У нас есть мощный 64-битный сервер Windows 2008 x 4 (4 х 4 ядра, 32 ГБ ОЗУ), работающий под управлением SQL Server 2005. У нас есть небольшая (6 ГБ), но очень важная база данных, доступ к которой несколько замедлен до тех пор, пока страницы не будут кэшированы в памяти (использование очень много случайных операций ввода-вывода, поэтому шансы очень низкие, данная страница находится в памяти и конечных пользователей пожаловаться на начальную медлительность). Диски достаточно быстрые (локальный 15K SAS), но я полагаю, что приложение написано несколько неуклюже (это решение COTS), поэтому мне интересно, есть ли способ «принудительного» размещения базы данных в памяти в SQL Server 2005 (2008 не поддерживается вендором, так что нам пока не стоит переходить на это), чтобы избежать первоначального блюза, заполняющего кеш?

Мой текущий метод состоит в том, что я запускаю SELECT * из каждой таблицы в скрипте, чтобы получить страницы данных в памяти, но некоторые объекты (индексы, полнотекстовый поиск и т. Д.) Не кэшируются этим методом (и модифицирую скрипт для опроса индексов и написать соответствующие пункты WHERE для кэширования - это комплекс кипения океана).

Нет, к сожалению, нет способа заставить базу данных войти в кеш. Ваш метод грубой силы, вероятно, самый простой. Возможно, вам удастся приблизиться, используя сценарии дефрагментации индекса с очень низким пороговым значением, например, сказать «пересобрать индекс, если он фрагментирован на 1%», например так:

http://sqlserverpedia.com/wiki/Index_Maintenance

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

Хорошо - я не могу комментировать ответ Брента (пока, так как у меня недостаточно повторений) - но если вы собираетесь идти по пути дефрагментации, не обязательно перестраивать индекс - так как это создаст новые индексы, возможно, увеличение базы данных, если недостаточно свободного места, и гарантия того, что ваша следующая резервная копия журнала будет иметь размер не менее размера ваших индексов, а в вашем журнале может быть также много записей журнала (в зависимости от модели восстановления). Если вы собираетесь выполнить маршрут дефрагментации, выполните команду ALTER INDEX ... REORGANIZE, которая не требует свободного места (ну, одна страница размером 8 КБ), но будет считывать листовой уровень в память и работать только с фрагментированным страницы. Уровни, не связанные с листом, должны поступать быстро после некоторых запросов и (в зависимости от разветвления) должны содержать намного меньше данных, чем уровень листа.

Почему объекты базы данных сначала удаляются из кэша? Вы перезапускаете службы SQL или отключаете базу данных? Или они вытесняются кэшированием из других баз данных?

С Уважением,

SCM.

Если база данных настолько мала, подумайте над тем, чтобы поместить ее на SSD?

У меня было несколько сценариев, когда обновление статистики с помощью FULLSCAN по ключевым таблицам принудительно помещало данные в кэш и делало мои последующие DML-файлы вокруг этих таблиц намного быстрее. И это не было результатом устаревшей статистики, поскольку это не привело к изменениям в планах выполнения.

Почему бы вам не установить второй экземпляр SQL Server только с этой базой данных и установить минимальный объем памяти для этого экземпляра равным 6 ГБ?

Это гарантирует, что ваши другие базы данных никогда не украдут память из вашей «маленькой, но очень важной» базы данных.

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

Я бы использовал профилировщик, чтобы проверить ваш sql. Сравните «логическое» чтение с «физическим» чтением. SQL-сервер является интеллектуальным и использует оперативную память, необходимую ему для наиболее эффективных результатов.

Также убедитесь, что ваши автостаты обновлены.

Без дополнительной информации о типе запроса и размерах таблицы БД это звучит немного странно.