Друг поглед към Oracle SQL Plan Management, DB блогове и бележки

За характеристиките на работата с различни СУБД на стоков хардуер

Друг поглед към Oracle SQL Plan Management

Профилите са нова (сравнително) дума в базата данни. Профили за зареждане на файловата система, работни профили на сесии, профили на SQL заявки, ... И накрая, Baseline или Oracle SQL Plan Management е нов инструмент за работа с планове за изпълнение на заявки по време на живота на приложението, което ви позволява да управлявате избора на план за изпълнение и неговото развитие.

Техническите проблеми са обсъждани повече от веднъж и има много информация по тази тема:

По-долу е друг опит да се обясни как работи SPM с един прост пример.

Как SPM се различава фундаментално от Outline? SPM не съхранява никакъв план за изпълнение, нито някакви съвети към оптимизатора, които ще трябва да бъдат вмъкнати в заявката. В действителност това не е необходимо: средата на изпълнение може да се промени и подсказките или спират да работят, или не работят според очакванията.

SPM съхранява кода на плана за изпълнение, който бихме искали да извлечем. Тези. по същество е обективна функция. Тези. сега, в допълнение към first_rows, all_rows, е възможно да посочим кода на плана за изпълнение, който бихме искали да получим. Това работи по следния начин. Да предположим, че имаме запитване (1):

И бихме искали да получим вложен цикъл по отношение на изпълнението на тази заявка (това е само пример). Ние вземаме оригиналната заявка и добавяме необходимите съвети там (2):

Получаване на плана за изпълнение

За същата заявка можем лесно да намерим съвети за създаване на базова линия в документацията. Но какво ще стане, ако искаме да получим същия план за изпълнение за друга заявка (1)? И не можете да повлияете на кода на приложението и да вмъкнете намек директно в текста на заявката (няма време и т.н.).

С помощта на SPM това се прави доста лесно -за текста на заявката (1), посочваме плана за изпълнение на заявката (2) като цел:

Понякога това е достатъчно, но можете да видите сами: за заявка (1) този SPM не работи.

Trace 10053 помага да разберем какво не е наред. Но преди да влезем в файловете за отстраняване на грешки, нека да разгледаме предложения план за изпълнение на заявката:

Виждаме, че планът е различен от този, който очаквахме - вместо операцията Nested loop в него, Filter. Не е грешка. Разглеждаме секцията SPM в трасировка 10053:

Какво стана? Оптимизаторът на заявките определи на етапа на избор на план за изпълнение, че има SPM за дадения sql_id. Въз основа на подсказките от профила на SPM, след стъпката на изброяване се опитах да получа плана с дадения номер и не можах да го направя. Видяхме същото, когато се опитахме да извлечем плана за изпълнение на SPM с помощта на пакета DBMS_XPLAN. На този етап вече не е възможно да се каже какъв е трябвало да бъде планът за изпълнение (известен е само неговият идентификатор). Добре известно е, че за даден sql_id в текущата среда е невъзможно да се получи. Така че по подразбиране се избира планът за изпълнение с най-ниска цена.

Причините за това поведение със заявка (1) са евристиката на оптимизатора. Някои операции при определени условия никога не се разглеждат. С помощта на подсказки успяхме да принудим оптимизатора да избере една от тези операции в заявка (2), но когато се опитахме да кажем на оптимизатора за заявка (1): „Използване на план номер n“, не успяхме - план номер n изобщо не се разглежда в нормална ситуация.

Други причини, поради които SPM не може да се използва:

  1. sql_id несъответствие. Всяка промяна в текста на заявката променя нейния sql_id. Това се случва, например, ако не използвате свързващи променливи, промените реда на сортиране или добавитеколони в секцията за избор.
  2. Списъкът с обекти е променен. Например един от индексите е променен или премахнат.
  3. Типът на обекта е променен. Например колона е станала ненулева или една от променливите за свързване е променила типа си.
  4. Параметрите на оптимизатора са променени. Например, те деактивираха трансформацията групиране по разположение.

SPM е независим от статистиката и данните в таблиците (добра новина) 🙂

P.S

Въпрос 1. Какви съвети в този случай се съхраняват като XML в профила? Подсказки към оптимизатора, с които той се опитва да получи целевия план за изпълнение. Тези съвети не влияят на заявката и са необходими само за ускоряване на търсенето. Наистина, не изпълнявайте една и съща скъпа фаза на оптимизация всеки път отново.

Въпрос 2. Какво показва display_sql_plan_baseline в този случай? Планът за изпълнение, получен с помощта на тези подсказки. Случва се, както в примера по-горе, тези подсказки изобщо да не работят по предназначение. Хубавото е, че в този случай SPM няма ефект върху плана за изпълнение.