Знайдені запити без гарного достатнього плану

У мене є база даних SQL Server 2012. Я помітив значення Reason for early termination of statement optimizationдля деяких запитів і все дав Good Enough Plan Found. Тепер мої запитання:

1. Назвіть усі можливі типи "Причини дострокового припинення оптимізації операторів". Я шукав це в msdn, але не отримав повного списку значень.

2. Чи є DMV або розширена подія, щоб перелічити всі запити, щодо яких оптимізація була припинена через причини, відмінні від знайденого Хорошого плану достатньої кількості? Я згадував наступні дві статті, в яких не вказаний повний перелік можливостей. [Крім того, вони дають мені різний результат у моїй базі даних].

   • Пошук: Час очікування компіляції запитів
   • Визначення недостатньо хороших планів запитів

• Ліміт пам’яті перевищено

  Оптимізатор був змушений перестати шукати кращі альтернативи плану через тиск в пам'яті. Причину цього слід дослідити та виправити, а потім спробувати скласти запит заново. План, що повертається, цілком може бути не тим, який вибрав би оптимізатор, якби не було низького стану пам'яті.

• Час вийшов

  Ця причина багато не зрозуміла .

  Оптимізатор запитів має на меті швидко знайти розумний план . Він не здійснює вичерпного пошуку, щоб знайти найкращий можливий план. Конструюючи, це дозволяє уникнути більше часу на оптимізацію, ніж потрібно. Однією з таких особливостей, яка допомагає забезпечити це, є «час очікування» (а не показник часу).

  Оптимізатор встановлює собі "бюджет на дослідження", виходячи зі складності логічного запиту, оцінок кардинальності та орієнтовної вартості найдешевшого плану, знайденого на даний момент (якщо такий є). Складніші запити з більш високою кардинальністю отримують більший бюджет.

  Якщо цей бюджет перевищено протягом однієї з його фаз пошуку, фаза закінчується. Це частина конструкції та нормальної роботи оптимізатора. Отримати запити, яким потрібно більше зусиль оптимізатора; ті, що ні, не роблять.

  Подумайте про "Тайм-аут" як "Знайдений хороший план".

• Хороший достатній план знайдено

  Це означає точно так само, як і пуста причина. Це просто історична химерність, що плани із вартістю нижче 0,909090 ... (1 / 1,1) позначаються таким чином. Ніщо не зупиняється рано чи іншим чином спеціально обробляється чи відрізняється в коді оптимізатора, коли з'являється ця причина.

Крім перевищення ліміту пам’яті, жодна з «причин дострокового припинення» не означає багато (якщо взагалі щось є) для настройки запитів або аналізу продуктивності. Я взагалі їх ігнорую.

Поради

Націлюйте зусилля на налаштування запитів на основі реальних показників продуктивності (минулий час, використання процесора / пам'яті, ... що важливо в контексті). Якщо запит занадто повільний за призначенням, витрачайте час на його швидше. Виміряйте фактичну ефективність, порівнюйте її з базовою лінією та історією та орієнтуйте зусилля на налаштування важливих варіацій.

Зберігайте дані з гарантовано-чистим вмістом у правильній реляційній схемі з корисною статистикою та покажчиками та добре написаними запитами, оптимізаторами.

Якщо ви перейдете на сторінку http://schemas.microsoft.com/sqlserver/2004/07/showplan/showplanxml.xsd (це посилання, яке ви побачите, якщо ви відкриєте план виконання як xml), ви побачите Перелічено три причини, які є:

• Час вийшов
• MemoryLimitExceedsed
• GoodEnoughPlanFound

Статті, які ви згадуєте, здаються нормальними для пошуку цих подій, у вас є певна проблема? Єдине, що потрібно пам’ятати, це те, що ці DMV не захоплюють усі команди SQL, що коли-небудь запускаються на сервері, і скидаються під час перезавантаження сервера. Ви можете захопити showplan xml із розширеними подіями та запитами, але це здається мені надмірним.

Я б не переживав надто про GoodEnoughPlanFound, схоже, оптимізатор робить свою роботу (швидко знайти хороший план).

HTH