Flaga śledzenia 4199 - Włączyć globalnie?

To może należeć do kategorii opinii, ale jestem ciekawy, czy ludzie używają flagi śledzenia 4199 jako parametru uruchamiania dla SQL Server. Dla tych, którzy go używali, w jakich okolicznościach wystąpiła regresja zapytań?

Z całą pewnością wydaje się to potencjalną korzyścią dla wydajności. Rozważam włączenie go na całym świecie w naszym środowisku nieprodukcyjnym i pozostawienie go na kilka miesięcy, aby rozwiązać wszelkie problemy.

Czy poprawki w 4199 są domyślnie wprowadzane do optymalizatora w 2014 (lub 2016)? Chociaż rozumiem, że nie należy wprowadzać nieoczekiwanych zmian w planie, dziwne wydaje się ukrywanie tych wszystkich poprawek między wersjami.

Używamy 2008, 2008 R2 i głównie 2012.

Osobiście, ilekroć buduję nowy serwer dla nowego projektu, zawsze włączam TF4199 globalnie. To samo dotyczy uaktualnienia istniejących instancji do nowszych wersji.

TF umożliwia nowe poprawki, które mogłyby wpłynąć na zachowanie aplikacji, ale w przypadku nowych projektów ryzyko regresji nie stanowi problemu. W przypadku instancji uaktualnionych z poprzednich wersji różnice między starą i nową wersją są same w sobie problemem i i tak trzeba się spodziewać regresji planu, więc wolę walczyć z tym z włączoną TF4199.

Jeśli chodzi o istniejące bazy danych, jest tylko jeden sposób, aby się dowiedzieć: przetestuj. Możesz przechwycić obciążenie istniejącej konfiguracji i odtworzyć go po włączeniu flagi. Narzędzia RML mogą pomóc zautomatyzować proces, jak opisano w tej odpowiedzi .

Oczywiście flaga wpływa na całą instancję, więc będziesz musiał przetestować wszystkie znajdujące się tam bazy danych.

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.

Chciałem podzielić się swoim doświadczeniem z flagą śledzenia 4199.

Właśnie skończyłem diagnozowanie problemu z wydajnością w systemie klienta z programem SQL Server 2012 z dodatkiem SP3. Klient przeniósł bazę danych raportowania z produkcyjnego serwera OLTP na nowy serwer. Celem klienta było wyeliminowanie konkurencji o zasoby dzięki zapytaniom OLTP. Niestety klient powiedział, że nowy serwer raportowania działa bardzo wolno.

Przykładowe zapytanie uruchomione w systemie OLTP zakończone w 1,6 sekundy. Plan zapytań przeprowadził wyszukiwanie indeksu w tabeli wierszy ~ 200 milionów, która była częścią widoku.

Na nowym serwerze to samo zapytanie zostało zakończone w ciągu 10 minut i 44 sekund. Przeprowadził skanowanie indeksu na tej samej ~ 200 milionowej tabeli wierszy.

Dane serwera raportującego były kopią danych OLTP, więc nie wyglądało na to, by była to różnica w danych.

Byłem zaskoczony, dopóki nie przypomniałem sobie, że nasze oprogramowanie (które obsługuje ich system OLTP) włączyło niektóre flagi śledzenia podczas uruchamiania. Przypomniałem sobie, że jednym z nich, 4199, była poprawka optymalizatora zapytań.

Testowałem włączenie flagi śledzenia 4199 na nowym serwerze raportowania klienta, a zapytanie raportowania zakończyło się w 0,6 sekundy. (Wow!) Wyłączyłem flagę śledzenia, a zapytanie powróciło do ukończenia za 10 min 44 sekund. Włączono flagę: z powrotem do 0,6 sekundy. Najwyraźniej włączenie flagi śledzenia umożliwiło optymalizatorowi użycie wyszukiwania indeksu w widoku tabeli 200 milionów wierszy.

W tym przypadku optymalizacje zapytań włączone przez flagę śledzenia 4199 zrobiły ogromną różnicę. Twoje doświadczenia mogą się różnić. Jednak na podstawie tego doświadczenia zdecydowanie mi się wydaje.