Я использую SQL Server 2008 Enterprise. Я сделаю много запросов к SQL Server. И я думаю, что сам SQL Server будет использовать некоторую внутреннюю оптимизацию, такую как предварительная выборка данных во внутренний кеш данных SQL Server или доступ к частым запросам данных из кеша перед загрузкой из физического файла подкачки для повышения производительности.
Есть ли какие-либо решения, позволяющие увидеть частоту попаданий во внутренний кеш SQL Server? Или какие-либо рекомендации по настройке кеша для повышения производительности запросов?
заранее спасибо, Джордж
Взгляните на BOL: SQL Server, объект диспетчера буферов.
В первую очередь вам следует обратить внимание на две области:
Кэш процедур это область памяти, в которой SQL хранит ваши планы запросов.
Буферный кеш это область памяти, в которой хранятся страницы данных.
Соответствующие счетчики perfmon:
Основные проблемы производительности SQL Server 2005 для приложений OLTP содержит следующее:
Узкое место ЦП, если ...
Ожидания сигнала> 25% от общего числа ожиданий. См. Sys.dm_os_wait_stats для информации о ожиданиях сигналов и общих ожиданиях. Ожидания сигналов измеряют время, проведенное в очереди для выполнения в ожидании ЦП. Ожидание высокого сигнала указывает на узкое место ЦП.
Повторное использование плана <90%. План запроса используется для выполнения запроса. Повторное использование плана желательно для рабочих нагрузок OLTP, поскольку повторное создание того же плана (для аналогичных или идентичных транзакций) является пустой тратой ресурсов ЦП. Сравните статистику SQL Server SQL: пакетных запросов / сек с компиляциями SQL / сек. Повторное использование плана вычислений следующим образом: Повторное использование плана = (Пакетные запросы - SQL-компиляции) / Пакетные запросы. Специальное исключение из правила повторного использования планов: планы с нулевой стоимостью не кэшируются (не используются повторно) в SQL 2005 SP2. Приложения, использующие планы с нулевой стоимостью, будут реже использовать повторно планы, но это не проблема производительности.
Тип параллельного ожидания cxpacket> 10% от общего числа ожиданий. Параллелизм жертвует ресурсами ЦП ради скорости выполнения. Учитывая большие объемы OLTP, параллельные запросы обычно снижают пропускную способность OLTP, и их следует избегать. См. Sys.dm_os_wait_stats для статистики ожидания.
Узкое место в памяти, если…
Постоянно низкая средняя продолжительность жизни страницы. См. Счетчик средней продолжительности жизни страницы в диспетчере буферов SQL Server объекта Perfmon (он представляет собой среднее количество секунд, в течение которых страница остается в кеше). Для OLTP средняя продолжительность жизни страницы 300 составляет 5 минут. Все, что меньше, может указывать на нехватку памяти, отсутствие индексов или очистку кеша.
Внезапное резкое падение продолжительности жизни страницы. Приложения OLTP (например, небольшие транзакции) должны иметь стабильную (или медленно увеличивающуюся) ожидаемую продолжительность жизни страницы. См. Объект Perfmon диспетчер буферов SQL Server.
Ожидающие гранты памяти. См. Счетчик отложенных грантов памяти в диспетчере памяти SQL Server объекта Perfmon. Небольшие транзакции OLTP не должны требовать большого выделения памяти.
Внезапные обрывы или постоянно низкий коэффициент попадания в кэш SQL. Приложения OLTP (например, небольшие транзакции) должны иметь высокий коэффициент попадания в кеш. Поскольку транзакции OLTP малы, не должно быть (1) значительного падения показателей попадания в кэш SQL или (2) постоянно низких показателей попадания в кеш <90%. Падение или недостаточное попадание в кеш может указывать на нехватку памяти или отсутствие индексов.