Kiedy w przeszłości musiałem przyjrzeć się problemom z buforowaniem planu/nadmierną rekompilacją zapytań, postępowałem zgodnie ze wskazówkami zawartymi w dokumencie firmy Microsoft 'Planowanie buforowania w SQL Server 2008' i zdecydowanie sugerowałbym przeczytanie tego, ponieważ obejmuje buforowanie planu, ponowne wykorzystanie planu zapytań, przyczyny ponownych kompilacji, identyfikowanie rekompilacji i inne powiązane tematy.
Mając to na uwadze, SQL Server Profiler (powinien znajdować się pod Microsoft SQL Server 2008 -> Performance Tools, jeśli zainstalowałeś go jako część instalacji narzędzi klienta) ujawnia trzy zdarzenia bezpośrednio związane z kompilacją zapytań, które mogą być dla Ciebie pomocne:
- Kursor
- CursorRekompilacja
- Wydajność
- Showplan XML do kompilacji zapytań
- Procedura przechowywana
- SP:Rekompilacja
Używasz procedur przechowywanych, więc prawdopodobnie musisz się martwić tylko o SP:Rekompilacja wydarzenie. To zdarzenie zostanie wywołane za każdym razem, gdy procedura składowana, wyzwalacz lub funkcja zdefiniowana przez użytkownika zostaną ponownie skompilowane. Kolumna TextData wyświetli tekst instrukcji tsql, która spowodowała ponowną kompilację instrukcji, a kolumna EventSubClass wyświetli kod wskazujący przyczynę ponownej kompilacji.
Kody EventSubClass dla SP:Recompile w SQL 2008
- 1 =Zmieniono schemat
- 2 =Zmieniono statystyki
- 3 =Ponowna kompilacja DNR
- 4 =Ustaw opcję zmienioną
- 5 =Zmieniono tabelę temp.
- 6 =Zmieniono zdalny zestaw wierszy
- 7 =Zmieniono przeglądanie uprawnień
- 8 =Zmieniono środowisko powiadamiania o zapytaniach
- 9 =Zmieniono widok MPI
- 10 =Zmieniono opcje kursora
- 11 =Z opcją ponownej kompilacji
Jeśli monitorujesz następujące 5 zdarzeń, będziesz w stanie zobaczyć, które procedury składowane i instrukcje są wywoływane na serwerze SQL, a które wyzwalają ponowną kompilację:
- Procedury sklepowe
- SP:Rozpoczęcie
- SP:Rozpoczęcie Stmt
- SP:Rekompilacja
- SP:Zakończono
- Wydajność
- Statystyki automatyczne
Zwykle konfiguruję również śledzenie Profiler, aby przechwycić wszystkie kolumny dla tych zdarzeń. Powiedziałbym, że skonfiguruj śledzenie z tymi 5 zdarzeniami, uruchom śledzenie przez 30 do 60 sekund, a następnie zatrzymaj je, a następnie powinieneś mieć dobry obraz tego, co powoduje ponowną kompilację.
Jeśli jest zbyt dużo szumu, możesz rozpocząć dodawanie filtrów kolumn do właściwości śledzenia, aby odfiltrować zdarzenia wejścia/wyjścia. Na przykład, jeśli zauważysz, że większość twoich rekompilacji ma miejsce tylko w jednej bazie danych, skonfiguruj filtr kolumn na kolumnie databaseID lub databaseName, aby tylko zapytania uruchamiane w tej bazie danych były uwzględniane w śledzeniu.
Następnie zacznij szukać wzorców, w których zapytania są ponownie kompilowane, i użyj oficjalnej księgi firmy Microsoft jako przewodnika, dlaczego mogą one wywołać ponowną kompilację.
