SQL Server - форсувати БД в пам'яті?

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

Мій поточний метод полягає в тому, що я запускаю SELECT * з кожної таблиці в сценарії, щоб отримати сторінки даних в пам'яті, але деякі об'єкти (покажчики, повний пошук тексту тощо) не кешуються цим методом (і змінюючи сценарій для допиту індексів і написати відповідні пункти, де КЕШ керувати, - це складний режим "boil-the-ocean").

Ні, на жаль, немає способу змусити базу даних в кеш-пам'ять. Ваш метод грубої сили, мабуть, найпростіший. Можливо, ви зможете наблизитись, скориставшись сценаріями дефрагментації індексу з дуже низьким значенням порогу, як-от сказати перебудувати індекс, якщо він на 1% фрагментований, як це:

http://sqlserverpedia.com/wiki/Index_Maintenance

Це займе більше часу і вимагатиме більше записів на диск, але це матиме побічний ефект від дефрагментації ваших індексів та оновлення статистики, що в будь-якому разі є хорошою ідеєю.

Гаразд - я не можу коментувати відповідь Брента (все-таки, оскільки мені не вистачає повторень) - але якщо ви збираєтеся йти шляхом дефрагментації, не обов'язково перебудовуйте індекс - так як це створить нові індекси, можливо, збільшуючи базу даних, якщо не вистачає вільного місця, і гарантуєте, що наступне резервне копіювання журналу має розмір принаймні розміру ваших індексів, і ваш журнал може мати і тонна записів журналу (залежно від моделі відновлення). Якщо ви збираєтеся робити маршрут дефрагментації, зробіть ALTER INDEX ... РЕОРГАНІЗАЦІЯ, яка не потребує вільного місця (ну, одна сторінка 8k), але буде читати рівень аркуша в пам'яті і працюватиме лише на фрагментованому сторінок. Рівень без листя повинен надходити швидко після деяких запитів і повинен бути набагато меншим, ніж рівень листя.

Чому в кеш-пам’яті спочатку видаляються об’єкти бази даних з кешу? Ви перезапускаєте сервіси SQL або знімаєте базу даних / не в мережі? Або їх витісняють кешування з інших баз даних?

З повагою,

СКМ.

Якщо база даних невелика, подумайте про те, як поставити її на SSD?

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

Чому б вам не встановити другий екземпляр SQL Server лише з цією базою даних і не встановити мінімальну пам'ять для цього примірника в 6 Гб?

Це гарантуватиме, що ваші інші бази даних ніколи не браконьєть пам’ять із вашої «малої, але дуже важливої» бази даних.

Це також означає, що ви можете взяти інший екземпляр в автономному режимі, і ваш невеликий БД залишиться в пам'яті.

Я б скористався профілером, щоб перевірити ваш sql. Порівняйте читання "логічного" з "фізичним". SQL-сервер розумний і використовуватиме оперативну пам’ять, необхідну для найефективніших результатів.

Також переконайтесь, що ваші автоматичні оновлення оновлені.

Без більше уявлення про тип запиту та розміри таблиці db це звучить дещо дивно.