Znaleziono zapytania bez dobrego planu wystarczającego

Mam bazę danych SQL Server 2012. Zauważyłem wartość Reason for early termination of statement optimizationniektórych zapytań i wszystkie dały Good Enough Plan Found. Teraz moje pytania to:

1. Jakie są wszystkie możliwe rodzaje „Przyczyny wcześniejszego zakończenia optymalizacji wyciągu”. Szukałem tego w msdn, ale nie otrzymałem pełnej listy wartości.

2. Czy istnieje zdarzenie DMV lub rozszerzone, aby wyświetlić listę wszystkich zapytań, dla których optymalizacja została zakończona z powodów innych niż Znaleziono dobry plan wystarczający? Odniosłem się do następujących dwóch artykułów, w których nie wymieniono pełnej listy możliwości. [Poza tym dają mi inne wyniki w mojej bazie danych].

   • Znajdowanie: Limit czasu kompilacji zapytania
   • Identyfikacja planów zapytań, które nie są wystarczająco dobre

• Przekroczono limit pamięci

  Optymalizator był zmuszony przestać szukać lepszych alternatywnych planów z powodu presji pamięci. Powód powinien zostać zbadany i poprawiony, a następnie ponowna próba kompilacji zapytania. Zwrócony plan może nie być tym, który wybrałby optymalizator, gdyby nie istniał stan niskiej pamięci.

• Koniec czasu

  Ten powód jest bardzo źle rozumiany .

  Optymalizator zapytań ma na celu szybkie znalezienie rozsądnego planu . Nie przeprowadza wyczerpującego wyszukiwania w celu znalezienia najlepszego możliwego planu. Z założenia unika się poświęcania więcej czasu na optymalizację niż to konieczne. Jedną z tych funkcji, która zapewnia, że ​​jest to „limit czasu” (nie jest miarą czasu).

  Optymalizator sam określa „budżet eksploracyjny” na podstawie złożoności logicznego zapytania, szacunków liczności i szacowanego kosztu najtańszego planu znalezionego do tej pory (jeśli taki istnieje). Bardziej złożone zapytania o większej liczności mają wyższy budżet.

  Jeśli ten budżet zostanie przekroczony podczas jednej z faz wyszukiwania, faza kończy się. Jest to część projektu i normalnej pracy optymalizatora. Otrzymuj zapytania, które wymagają większego wysiłku optymalizacyjnego; te, które nie, nie.

  Pomyśl o „Time Out” jako „Good Enough Plan Found”.

• Znaleziono wystarczający plan

  Oznacza to dokładnie to samo, co pusty powód. Jest to po prostu historyczne dziwactwo, że plany o koszcie poniżej 0,909090 ... (1 / 1.1) są oznaczone w ten sposób. Nic nie zatrzymuje się wcześnie lub nie jest inaczej obsługiwane lub różni się w kodzie optymalizatora, gdy pojawia się ten powód.

Oprócz przekroczonego limitu pamięci, żaden z „powodów wcześniejszego zakończenia” nie znaczy wiele (jeśli w ogóle cokolwiek) dla dostrajania zapytań lub analizy wydajności. Generalnie je ignoruję.

Rada

Celowanie w dostosowywanie zapytań w oparciu o rzeczywiste wskaźniki wydajności (czas, zużycie procesora / pamięci, ... cokolwiek jest ważne w kontekście). Jeśli zapytanie jest zbyt wolne w stosunku do zamierzonego celu, poświęć czas na przyspieszenie. Zmierz rzeczywistą wydajność, porównaj ją z linią bazową i historią oraz ukierunkuj wysiłek strojenia na ważne wariancje.

Przechowuj gwarantowane czyste dane w odpowiednim schemacie relacyjnym, z przydatnymi statystykami i indeksami oraz dobrze napisanymi zapytaniami przyjaznymi dla optymalizatora.

Jeśli przejdziesz do http://schemas.microsoft.com/sqlserver/2004/07/showplan/showplanxml.xsd (który jest linkiem, który zobaczysz, jeśli otworzysz plan wykonania jako xml), zobaczysz trzy wymienione powody, które są:

• Koniec czasu
• MemoryLimitExceeded
• GoodEnoughPlanFound

Artykuły, o których wspomniałeś, wydają się odpowiednie do znalezienia tych wydarzeń, czy masz konkretny problem? Jedyną rzeczą do zapamiętania jest to, że te DMV nie przechwytują wszystkich poleceń SQL, które kiedykolwiek były uruchamiane na serwerze i resetują się po ponownym uruchomieniu serwera. Możesz złapać showplan xml za pomocą Extended Events i zapytać o to, ale wydaje mi się to przesadą.

Nie martwiłbym się też zbytnio o GoodEnoughPlanFound, wygląda na to, że optymalizator dobrze sobie radzi (szybko znajduje dobry plan).

HTH