Когато ми се е налагало да разглеждам проблеми с кеширане на планове/прекомерно прекомпилиране на заявки в миналото, следвах указанията, предоставени в бялата книга на Microsoft "Кеширане на план в SQL Server 2008" и силно бих препоръчал да прочетете това, тъй като обхваща кеширане на планове, повторно използване на план за заявки, причини за повторни компилации, идентифициране на повторни компилации и други свързани теми.
С това казано, SQL Server Profiler (трябва да се намира под Microsoft SQL Server 2008 -> Инструменти за производителност, ако сте го инсталирали като част от инсталацията на вашите клиентски инструменти) разкрива три събития, пряко свързани с компилирането на заявка, които могат да ви бъдат полезни:
- Курсор
- Прекомпилиране на курсора
- Ефективност
- Showplan XML за компилиране на заявка
- Съхранена процедура
- SP:Прекомпилиране
Използвате съхранени процедури, така че вероятно трябва да се тревожите само за SP:Прекомпилиране събитие. Това събитие ще се задейства всеки път, когато съхранена процедура, тригер или дефинирана от потребителя функция е била повторно компилирана. Колоната TextData ще покаже текста на оператора tsql, който е причинил повторното компилиране на израза, а колоната EventSubClass ще покаже код, който показва причината за повторното компилиране.
Кодове на EventSubClass за SP:Прекомпилиране в SQL 2008
- 1 =Схемата е променена
- 2 =Статистическите данни са променени
- 3 =Прекомпилиране на DNR
- 4 =Променена опция за настройка
- 5 =Временната таблица е променена
- 6 =Променен набор от отдалечени редове
- 7 =За Променени трайни прегледи
- 8 =Средата за известяване на заявка е променена
- 9 =MPI изгледът е променен
- 10 =Опциите на курсора са променени
- 11 =С опция за прекомпилиране
Ако наблюдавате следните 5 събития, ще можете да видите кои съхранени процедури и изрази се извикват на SQL Server и кои задействат повторни компилации:
- Процедури на магазина
- SP:Стартиране
- SP:StmtStarting
- SP:Прекомпилиране
- SP:Завършено
- Ефективност
- Автоматична статистика
Също така обикновено настройвам проследяването на Profiler да улавя всички колони за тези събития. Бих казал, че настройте проследяване с тези 5 събития, стартирайте проследяване за 30 до 60 секунди и след това го поставете на пауза и тогава трябва да имате добра моментна снимка на това, което причинява повторното компилиране.
Ако има твърде много шум, можете да започнете да добавяте филтри за колони към свойствата на трасирането, за да филтрирате събития за влизане/изключване. Например, ако установите, че повечето от вашите прекомпилирания се случват само веднъж в базата данни, настройте филтър на колони в колоната databaseID или databaseName, така че във вашето проследяване да бъдат включени само заявки, изпълнявани срещу тази база данни.
След това започнете да търсите модели, по които заявките се прекомпилират, и използвайте бялата книга от Microsoft като ръководство защо те може да задействат прекомпилирането.
