Moje poszukiwania na ten temat mnie tu przywiodły, dlatego chciałbym po prostu podzielić się moimi ostatnimi doświadczeniami na ten temat.
Korzystałem z SQL 2014, więc pomyślałem, że nie będę musiał martwić się o około 4199 trochę ... ale to po prostu nieprawda ...
Jak zdiagnozować, jeśli potrzebujesz 4199
Jeśli wydaje się, że zapytanie działa nieprawidłowo , szczególnie gdy uważasz, że nie powinno, spróbuj dodać następujące na końcu, aby sprawdzić, czy rozwiązuje wszystkie problemy, ponieważ może być konieczne 4199 („Włącz wszystkie poprawki Optymalizatora zapytań”). )
SELECT SomeColumn
FROM SomeTable
OPTION(QUERYTRACEON 4199)
W mojej sytuacji miałem 10 najlepszych klauzul wysadzających zapytania, które działały bez zarzutu, co sprawiło, że pomyślałem, że dzieje się coś podejrzanego i że 4199 może pomóc.
Około 4199
Wszelkie poprawki błędów / poprawek optymalizatora zapytań SQL Server, które są tworzone po wydaniu nowej wersji głównej, zostają ukryte i zablokowane. Dzieje się tak na wypadek, gdyby rzeczywiście mogły zaszkodzić innym, idealnie zoptymalizowanym teoretycznie programom. Tak więc instaluj aktualizacje tak, jak możesz, rzeczywiste zmiany optymalizatora zapytań nie są domyślnie włączone. Dlatego po dokonaniu pojedynczej poprawki lub rozszerzenia 4199 staje się koniecznością, jeśli chcesz z niej skorzystać. Ponieważ pojawia się wiele poprawek, w końcu przekonasz się, że jedna z nich dotyczy ciebie. Te poprawki są zwykle powiązane z ich własnymi flagami śledzenia, ale 4199 jest używany jako główny „Włącz każdą poprawkę”.
Jeśli wiesz, jakich poprawek potrzebujesz, możesz włączyć ich posiłek na kawałek zamiast korzystać z 4199. Jeśli chcesz włączyć wszystkie poprawki, użyj 4199.
Ok, więc chcesz 4199 na całym świecie ...
Wystarczy utworzyć zadanie agenta SQL, które będzie uruchamiane każdego ranka z następującym wierszem, aby włączyć flagę śledzenia globalnie. Zapewnia to, że jeśli ktoś je wyłączy itp., Że zostanie ponownie włączony. Ten krok zadania ma dość prosty SQL:
DBCC TRACEON (4199, -1);
Gdzie -1 określa część globalną w DBCC TRACEON. Aby uzyskać więcej informacji zobacz:
https://msdn.microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396
„Rekompilacja” planów zapytań
Podczas mojej ostatniej próby musiałem włączyć 4199 globalnie, a następnie usunąć istniejące plany zapytań w pamięci podręcznej :
sp_recompile 'dbo.SomeTable'
https://msdn.microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396
Gdzie podczas ponownej kompilacji procedura przechowywana znajduje wszelkie plany zapytań dotyczące obiektu bazy danych (takie jak tabela) i usuwa te plany zapytań, co wymaga następnej próby uruchomienia podobnego zapytania w celu ich skompilowania.
Tak więc w moim przypadku 4199 nie pozwolił na utworzenie złych planów zapytań, ale musiałem również usunąć te, które były nadal buforowane przez sp_recompile. Wybierz dowolną tabelę ze znanego zapytania, którego dotyczy problem, i powinieneś spróbować ponownie spróbować tego zapytania, zakładając, że włączyłeś 4199 globalnie i wyczyściłeś zbędny buforowany plan zapytań.
W podsumowaniu 4199
Gdy korzystasz z indeksów, inteligentna optymalizacja planu zapytań staje się ważna dla faktycznego inteligentnego korzystania z tych indeksów, a przy założeniu, że z czasem zostanie opublikowana poprawka w procesie optymalizacji zapytań, na ogół jesteś w bezpiecznej wodzie, aby uruchomić 4199 globalnie, pod warunkiem, że zdajesz sobie sprawę, że niektóre nowe poprawki mogą nie działać tak dobrze z wysoce zoptymalizowaną bazą danych, która była tak zoptymalizowana w poprzednim środowisku przed tą poprawką. Ale co robi 4199? Po prostu włącza wszystkie poprawki.