Управління SQL-планами в Oracle Database 11g, Інші СУБД, Бази даних, статті

ЗАУВАЖЕННЯ



Цей документ призначається для того, щоб окреслити загальне бачення тенденцій розвитку наших продуктів. Він пропонується тільки в інформаційних цілях і не може бути включений ні в якій контракт. Документ не є зобов’язанням надати будь-які матеріали, коди або функціональні можливості, і на нього не можна покладатися при прийнятті рішень про закупівлі. Розробка, випуск і вибір часу появи будь-яких опцій або функціональних можливостей, описаних для продуктів Oracle, повністю залишаються у винятковому розпорядженні Oracle.


Зміст


Введення
Продуктивність будь-якого додатку бази даних у великій мірі спирається на виконання ним запитів. Хоча оптимізатор Oracle ідеально підходить для оцінки найкращого можливого плану без будь-якого втручання користувача, план виконання SQL-оператора може несподівано змінитися по безлічі причин, включаючи повторний збір статистики оптимізатора, зміна параметрів оптимізатора або визначень схеми та / або метаданих. Неможливість гарантувати, що всі зміни плану завжди будуть в кращу сторону, привела деяких замовників до того, щоб закріпити свої плани виконання (збережені плани) або блокувати статистику оптимізатора. Однак, якщо діяти таким чином, ми позбавляємо себе можливості коли-небудь використовувати в своїх інтересах нові функціональні можливості оптимізатора або шляху доступу, які могли б підвищити продуктивність SQL-операторів. Зберігати поточні плани виконання, незалежно від змін середовища, і дозволяти зміни, що ведуть тільки на краще, – це було б остаточним рішенням.
Oracle Database 11g є першою базою даних на ринку, яка здатна вирішити цю проблему. Механізм SQL Plan Management (SPM – управління планами виконання SQL-операторів) пропонує інфраструктуру повністю прозорого керованого перетворення планів виконання. Використовуючи SPM, оптимізатор автоматично управляє планами виконання і гарантує, що використовуються тільки відомі або прийняті плани. Коли для SQL-оператора знаходиться новий план виконання, він не використовується до тих пір, поки не буде перевірений базою даних, і не буде показано, що він має порівнянну або кращу продуктивність, ніж поточний план.


Механізм SQL PLAN MANAGEMENT

Гарантована стабільність і
контрольована еволюція плану


Механізм управління планами виконання SQL-операторів (SPM) гарантує, що зміна плану оператора ніколи не призведе до погіршення його продуктивності під час виконання. Щоб гарантувати це, використовуються тільки прийняті плани виконання; будь-яка еволюція плану згодом буде відстежено і оцінена і буде прийнята, як перевірена, тільки в тому випадку, якщо новий план призводить під час виконання до якихось змін або удосконалень. SQL Plan Management складається з трьох основних компонентів:



  1. Отримання опорного SQL-плану: Створіть опорні плани виконання SQL, що представляють прийняті (перевірені) плани виконання для всіх релевантних SQL-операторів. Опорні планів виконання SQL зберігаються в архівах планів (plan history) в базі SQL Management Base в табличному просторі SYSAUX.
  2. Вибір опорного плану виконання SQL:
    Переконайтеся, що тільки прийняті плани виконання використовуються для операторів з опорними SQL-планами і відстежуйте все нові плани виконання в архіві планів (plan history) для операторів. Архів планів виконання складається з прийнятих і пропущених планів. Неприйнятий план може бути неверифікованим (недавно знайдений, але поки неперевірений) або відхиленим (верифікований, але якого ухвалено непродуктивною).
  3. Еволюція опорного SQL-плану:
    Оцініть всі неперевірені плани виконання для даного оператора, що містяться в архіві, щоб вони отримали статус прийнятих або відхилених планів.

Рис. 0. База SQL Management, що складається з журналу операторів та архівів планів для повторюваних SQL-операторів (repeatable SQL Statements).


Отримання опорного SQL-плану

Отримайте плани “на льоту” або виконайте
масову завантаження SPM планами з кеша
курсора, набору настройки SQL або
імпортуйте плани з іншої системи.


Для того щоб зміг заробити SPM, спочатку потрібно заповнити SQL Management Base поточними вартісними планами виконання, які стануть опорними планами виконання для кожного SQL-оператора. Є два різні способи заповнення SQL Management Base:


Automatic plan capture can be switched on by setting the init.ora parameter OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES to TRUE   (the default value is false) . With automatic plan capture enabled, the SPM repository will be automatically populated for any repeatable SQL statement. To identify repeatable SQL statements, the optimizer will log the identity (SQL Signature) of each SQL statement into a statement log the first time it is compiled. If the SQL statement is processed again (executed or compiled) the presence of its identity in the statement

Автоматичне отримання планів виконання – “на льоту”

Включення автоматичного отримання планів проводиться установкою параметра OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES на TRUE (Значення за замовчуванням – FALSE) в файлі init.ora. При цьому репозиторій SPM буде заповнюватися автоматично для будь-якого повторюваного SQL-оператора. Для визначення повторюваного SQL-оператора оптимізатор при першій компіляції реєструє ідентифікаційний параметр (сигнатуру SQL) кожного SQL-оператора в журналі операторів. Якщо SQL-оператор обробляється знову (виконується або компілюється), то наявність його ідентифікаційного параметра в журналі операторів вкаже на те, що подібний оператор є повторюваним. Для оператора буде створений архів SQL-планів виконання, в який вкладається інформація, використовувана оптимізатором для відтворення планів виконання, а саме: текст оператора SQL, ієрархічна структура, змінні зв’язування і середу компіляції. Поточний вартісної план додається як першої опорної SQL-план виконання, і цей план відзначається як прийнятий. Використовуються тільки прийняті плани; якщо через деякий час для цього SQL-оператора буде знайдений новий план, то він буде доданий до архіву планів виконання і відзначений, як підлягає перевірці. Він відзначається як прийнятий тільки в тому випадку, якщо його продуктивність буде краще, ніж продуктивність плану, обраного з поточного опорного.


Рис. 1. База SQL Management, що складається з журналу операторів та архівів планів виконання для повторюваних операторів.

Операція масової завантаження

Плани виконання в операціях масової завантаження особливо корисні, коли проводиться оновлення бази даних з попередньою версією до Oracle Database 11g, або при розгортанні нової програми. Операція масової завантаження може бути виконана разом з автоматичним отриманням плану або замість нього. Плани виконання, які були завантажені з допомогою операції масової завантаження, автоматично приймаються для створення нових опорних планів виконання SQL або для додавання до існуючих планів. Для масової завантаження в SQL Management Base можуть бути використані три різні методики:



  1. Заповнення планів виконання для даного набору SQL-налаштувань (STS – SQL Tuning Set)
  2. Використання планів виконання, що є в даний час в кеші курсора
  3. Розпакування існуючих опорних планів виконання SQL з проміжної таблиці

З набору налаштувань SQL (STS)
Можна отримати плани (критичної) робочого навантаження SQL для набору налаштувань SQL (STS), а потім завантажити їх в SQL Management Base, як опорні SQL-плани, використовуючи для цього процедуру PL / SQL DBMS_SPM. LOAD_ PLANS_ FROM_ SQLSET, або через Oracle Enterprise Manager (EM). При наступному виконанні цих операторів будуть використані опорні плани виконання SQL.
Масова завантаження планів виконання з STS – це чудовий спосіб гарантувати, що після оновлення частини бази даних не відбудеться ніяких змін плану. Все, що потрібно – це виконати наступні чотири кроки:



  1. Створіть у Oracle Database 10gR2 STS, що включає план виконання для кожного з SQL-операторів.
  2. Завантажте STS в проміжну таблицю і експортуйте його в плоский файл.
  3. Імпортуйте проміжну таблицю з плоского файлу в Oracle Database 11g і вивантажите STS.
  4. Використовуйте EM або DBMS_SPM.LOAD_PLANS_FROM_SQLSET, щоб завантажити плани виконання в SQL Management Base.


Рис. 2. Масова завантаження SMB для оновлення (апгрейда) бази даних з використанням STS.


Відразу після створення опорних планів виконання SQL вони почнуть використовуватися, гарантуючи, що при переході від 10gR2 до 11gR1 не відбудеться ніяких змін плану. Якщо оптимізатор в базі даних Oracle 11g придумає інший план виконання, то цей план буде додано до архіву планів і буде відзначений, як підлягає перевірці. Він буде відзначений як прийнятий тільки в тому випадку, якщо його продуктивність буде настільки ж хороша, як у поточного опорного SQL-плану (для 10gR2), або краще.

З кешу курсора

Є можливість завантажити плани операторів в SQL Management Base безпосередньо з кешу курсора. Застосовуючи фільтр на ім’я модуля, схемою або SQL_ID, можна ідентифікувати SQL-оператор або набір з SQL-операторів, дані про які потрібно зібрати. Для завантаження планів може бути використана процедура PL / SQL DBMS_SPM. LOAD_ PLANS_ FROM_ CURSOR_ CACHE. Або жеето можна зробити через Oracle Enterprise Manager. При наступному виконанні цих операторів будуть використовуватися їх опорні SQL-плани.
Завантаження планів безпосередньо з кешу курсора може бути надзвичайно корисною, якщо прикладні SQL-пропозиції були налаштовані вручну із застосуванням підказок. Так як дуже малоймовірно, що входять до складу програми SQL-оператори можуть бути змінені шляхом включення в них підказок, захоплення налаштованого плану як опорного послужить гарантією того, що прикладні SQL-оператори будуть використовувати цей план і в майбутньому.

Розпакування опорних планів з проміжної таблиці

Розгортання нового модуля програми означає введення в базу даних абсолютно нових SQL-операторів. З Oracle Database 11g будь вендор програмного забезпечення від третіх фірм може почати постачання свого прикладного програмного забезпечення поряд з відповідними опорними планами виконання SQL для нововведених SQL-операторів. Це є гарантією, що для всіх SQL-операторів, які є частиною опорного плану виконання SQL, спочатку використовуються плани, про які відомо, що вони давали хорошу продуктивність в стандартній тестової конфігурації. Альтернативно, якщо додаток було розроблено власними силами або проходило тестування всередині фірми, правильні плани можуть бути експортовані з тестової системи та імпортовані в промислову версію за допомогою наступних кроків:



  1. У початковій системі створіть проміжну таблицю, використовуючи процедуру DBMS_SPM.CREATE_STGTAB_BASELINE
  2. Упакуйте опорні плани виконання SQL, які ви хочете експортувати з бази управління SQL в проміжну таблицю, використовуючи для цього функцію DBMS_SPM.PACK_STGTAB_BASELINE.
  3. Експортуйте проміжну таблицю в плоский файл, використовуючи команду експорту або технологію Data Pump.
  4. Передайте отриманий плоский файл в цільову систему.
  5. Імпортуйте проміжну таблицю з плоского файлу, використовуючи команду імпорту або технологію Data Pump.
  6. Розпакуйте опорні плани виконання SQL з проміжної таблиці в базу даних управління SQL в цільовій системі, використовуючи функцію DBMS_SPM.UNPACK_STGTAB_BASELINE.


Рис. 3. Імпорт опорних планів виконання SQL з тестової системи при реалізації нової програми


Вибір опорного плану виконання SQL

При роботі з SPM для виконання будуть вибрані тільки
відомі або перевірені плани


При кожній компіляції SQL-оператора для побудови плану виконання з найкращою вартістю оптимізатор спочатку використовує традиційний метод пошуку по вартості. Якщо параметр ініціалізації OPTIMIZER_USE_PLAN_BASELINES , Встановлено на TRUE (Значення за замовчуванням), то перед тим, як буде виконаний вартісної план, оптимізатор спробує знайти відповідний план в опорному плані виконання SQL-оператора. Ці дії виконуються як операція в оперативній пам’яті, так що в роботу будь-якої програми не вноситься ніяких вимірних накладних витрат. Якщо відповідність знайдено, оптимізатор продовжить роботу з цим планом. В іншому випадку, якщо не буде знайдено ніякого відповідності, то недавно згенерований план буде додано до архіву виконання планів, він повинен бути перевірений, перш ніж його можна буде прийняти, як опорний план виконання. Замість виконання нещодавно згенерованого плану оптимізатор буде оцінювати кожен з прийнятих планів для SQL-оператора і вибирати з них план з найнижчою вартістю виконання (зауважте, що в опорному плані може налічуватися більше одного перевіреного / прийнятого плану для даного оператора). Однак, якщо будь-яка зміна в системі (наприклад, видалення індексу) призведе до ситуації, коли всі прийняті плани стануть невідтворюваних, то оптимізатор буде використовувати недавно згенерований вартісної план.


Рисунок 4. Як за допомогою SPM вибирається план виконання
 

Також можна вплинути на вибір плану оптимізатором, коли він його вибирає. Плани можуть бути відзначені, як фіксовані (fixed SQL plan baselines). Фіксовані опорні плани виконання SQL вказують оптимізатору, що бажані. Якщо оптимізатор буде оцінювати опорні плани і один з планів виявиться фіксованим, то оптимізатор буде оцінювати тільки цей фіксований план і зупиниться на ньому, якщо тільки він є відтворюваним. Якщо фіксований план (и) буде невідтворюваних, то оптимізатор повернеться до оцінки залишилися опорних планів виконання SQL і вибере план з найменшою вартістю. Відзначте, що оцінка вартості плану набагато нижче, ніж вартість повного розбору. Оптимізатор не досліджує всі можливі методи доступу, а тільки один певний шлях доступу.


Еволюція опорного плану виконання SQL

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

Коли оптимізатор знаходить для SQL-оператора новий план виконання, цей план додається до архіву, як ще неприйнятий план, який повинен бути перевірений, перш ніж він зможе стати прийнятим планом. Можна розвинути план виконання SQL-оператора, використовуючи Oracle Enterprise Manager або виконуючи в командному рядку функцію DBMS_SPM. EVOLVE_SQL_PLAN_BASELINE. При використанні будь-якого з цих методів є три вибору:



  1. Прийняти план тільки в тому випадку, якщо він виконується краще, ніж існуючий опорний план виконання SQL
  2. Прийняти план, не роблячи перевірки продуктивності
  3. Запустити порівняння продуктивності і згенерувати звіт, не розвиваючи нового плану.

Перший варіант веде до оцінки нового плану, щоб побачити, чи працює він краще, ніж обраний план. Якщо це так, то новий план буде додано до опорного плану, як прийнятий, а якщо ні, то новий план залишиться в архіві планів, як пропущений план, але його атрибут LAST_VERIFIED буде оновлено – в нього буде занесена поточна відмітка дати / часу. Функція повертає форматований текстовий звіт, в якому містяться дії, виконані функцією, і дається паралельний показ статистики продуктивності нового і первісного планів.
Якщо вибирається варіант 2, то новий план буде додано до опорного плану виконання SQL як прийнятий план без перевірки його продуктивності. Звіт також буде згенерований.
За варіанту 3 виконується оцінка нового плану, щоб побачити, чи виконується він краще, ніж обраний план, але навіть якщо це так, новий план не буде прийнятий автоматично. Після оцінки буде всього лише згенерований звіт.

Використання та управління базою SQL MANAGEMENT BASE

Параметри ініціалізації

Для управління SPM у файлі init.ora є два параметри:

optimizer_capture_sql_plan_baselines – Управляє автоматичним отриманням нових опорних планів виконання для повторюваних SQL-операторів. В 11gR1 цей параметр за замовчуванням встановлений на FALSE.

optimizer_use_sql_plan_baselines – Управляє використанням опорних SQL-планів. Коли він активований, оптимізатор шукає в опорних SQL-планах плани для SQL-оператора, що підлягає компіляції. Якщо які-небудь плани знайдені, то оптимізатор оцінює кожен план і вибере той, у якого буде найнижча вартість. В 11gR1 за умовчанням цей параметр встановлений на TRUE.

Управління споживанням дискової пам’яті в SQL Management Base

Журнал операторів, архіви планів і опорні плани SQL зберігаються в SQL Management Base. База SQL Management Base – це частина словника бази даних, що зберігається в табличному просторі SYSAUX. За замовчуванням максимальний розмір відведеного для SQL Management Base дискового простору не повинен перевищувати 10% розміру табличного простору SYSAUX. Однак, використовуючи для цього процедуру PL / SQL DBMS_SPM.CONFIGURE, можна замінити це граничне значення будь-яким значенням в діапазоні від 1% до 50%. Щотижня виконується фоновий процес вимірює загальний обсяг простору, зайнятого SQL Management Base, і коли раніше певна межа перевищується, цей процес генерує попередження в журналі попереджень (alert log).

Крім того, є запланована до щотижневого виконання завдання чистки, керуюча дисковим простором, використовуваним SPM в SQL Management Base. Завдання автоматично виконується під час технологічного вікна і видаляє будь-які плани, які не використовувалися протягом більш ніж 53 тижнів. Тим самим досягається гарантія, що будь-які SQL-оператори, що виконуються хоча б один раз на рік, залишаться доступними. Змінити період збереження невикористовуваних планів можна, використовуючи DBMS_SPM.CONFIGURE або Enterprise Manager. Нове значення може знаходитися в діапазоні від 5 до 523 тижнів (трохи більше 10 років).

Оскільки SQL Management Base повністю зберігається всередині табличного простору SYSAUX, SPM не застосовується, якщо це табличне простір недоступно.


Рис. 5. Зміна установки тривалості використання плану в EM


Моніторинг SQL PLAN MANAGEMENT

Для ведення моніторингу SPM використовуйте EM DBControl
або нове словникове представлення DBA_SQL_PLAN_BASELINES.


Для ведення моніторингу функціональності SPM в Oracle Database 11g було введено кілька нових екранів управління підприємством і уявлень АБД.
Enterprise Manager

Всі аспекти управління та моніторингу опорних SQL-планів можуть бути виконані через Enterprise Manager Database Control.

Початок роботи

Щоб потрапити на сторінку опорного плану виконання SQL:


  1. Зверніться до домашньої сторінці бази даних в Enterprise Manager.
  2. У верхній частині сторінки клікніть по кнопці Server, щоб відобразити сторінку сервера.
  3. У розділі оптимізатора запитів клікніть по кнопці SQL Plan Control.
  4. З’явиться сторінка SQL Plan Control. Див інтерактивну довідку для отримання інформації про цю сторінку.
  5. У верхній частині сторінки клікніть по кнопці SQL Plan Baseline, щоб відобразити підсторінку опорних планів SQL.


Рис. 6. Домашня сторінка опорного плану в Oracle Enterprise Manager DB Control

З основної сторінки можна управляти параметрами init.ora, планувати завдання із завантаження або еволюції, а також змінювати деякі атрибути існуючих опорних планів SQL.
Зміна значень параметрів init. ora
У лівій верхній стороні основної сторінки опорного плану є розділ установок, в якому перераховуються параметри, контролюючі SQL Plan Management. Досить побіжного погляду на цей розділ, щоб зрозуміти, включений чи ні автоматичне отримання опорних планів, а також зрозуміти, використовується чи ні опорний план SQL. Для зміни значення параметра init.ora:



  1. Клацніть по значенню параметра
  2. Відкриється сторінка параметра ініціалізації. У спадному меню виберіть значення, яке ви хочете привласнити параметру
  3. Клацніть по OK


Рис. 7. Установка в EM пов’язаних з SPM параметрів файлу init.ora

Масова завантаження планів
Можна завантажити плани прямо з кешу курсора, використовуючи кнопку завантаження з правого боку над списком опорних планів SQL. Можна завантажити плани для всіх операторів в кеші курсора, або ж можна вибрати підмножина планів.



  1. Клацніть по кнопці завантаження
  2. З’явиться сторінка завантаження опорного плану SQL. Виберіть перемикач завантаження планів для “load from the cursor cache” (“завантаження з кеша курсора”)
  3. Вручну введіть один або декілька SQL_ID або клікніть по іконці з ліхтариком, щоб побачити список усіх SQL_ID і текст SQL для кожного плану в кеші курсора.
  4. Після вибору SQL_ID заповніть інформацію, пов’язану з плануванням завдання (за замовчуванням – негайна завантаження)
  5. Клацніть по OK

Рисунок 8. Масова завантаження опорних планів SQL з курсора кеша в EM


Зміна атрибутів
З основної сторінки опорного плану SQL можна змінити будь-який атрибут опорного плану. Для зміни атрибута


  1. Клацніть по кнопці-вимикача перед опорним планом
  2. Клацніть по кнопці атрибута, який ви бажаєте змінити

    • З’явиться вікно діалогу, в якому вам буде запропоновано підтвердити ваш вибір. Клацніть по OK

    Перегляд плану виконання опорного плану SQL
    Щоб переглянути фактичний план виконання для опорного плану SQL, клікніть на ім’я плану. Для розгляду планів виконання з опорних планів для даного оператора SQL клікніть по кнопці SQL Text.
    Еволюція опорного плану SQL
    Перебуваючи на основній сторінці опорного плану SQL, можна побачити, які плани прийняті, а які – ні. Якщо ви захочете прослідкувати еволюцію неприйнятого плану:


    1. Клацніть по кнопці-вимикача перед планом і виберіть розташовану над нею кнопку evolve
    2. Відкриється сторінка еволюції опорного плану SQL з трьома варіантами кнопки-вимикача:
      a. Verify Performance (перевірити продуктивність) – Якщо треба мати гарантії, що пропущений план виконується так само добре, як існуючий опорний план виконання SQL, або навіть краще за нього, виберіть YES. Якщо ви вже знаєте, що пропущений план має гарну продуктивність, і хотіли б обійти перевірку, виберіть NO.
      b.     Time Limit (Обмеження часу) – Застосовується тільки в тому випадку, якщо в поле Verify Performance вибрано Yes. РежимAuto (Авто) означає, що Oracle сама вирішить, як багато часу витрачати на підтвердження продуктивності пропущених планів. Режим Unlimited (Необмежена) означає, що процес перевірки плану буде виконуватися аж до його завершення. Specify (Визначити) означає, що потрібно встановити часовий ліміт для процесу перевірки плану.
      c. Action (Дія) – Чи хочете ви, щоб новий план був автоматично прийнятий, або ви просто хочете отримати на виході звіт про результати перевірки процесу, базуючись на якому ви зможете вирішити, приймати новий план, або немає.
    3. Клацніть по OK
    4. З’явиться основна сторінка опорного плану SQL. Ви повинні побачити, що еволюціонує завдання, перераховане в розділі завдань у правій верхній стороні сторінки. (В разі необхідності клікніть по кнопці оновлення (refresh)).


    Рис. 8. Еволюція плану


    Моніторинг SPM через подання АБД
    У поданні DBA_SQL_PLAN_BASELINES представлена ​​інформація про опорних планах SQL, які в даний момент створені для конкретних SQL-операторів.


    select sql_handle, sql_text, plan_name, origin,
    enabled, accepted, fixed, autopurge
    from dba_sqljplan_baselines;


    Цей оператор select повертає наступні рядки:


    У цьому прикладі у одного і того ж SQL-оператора є два плани, причому обидва вони були отримані автоматично. Один із планів (SYS_SQL_PLAN_4be) є опорним планом для плану виконання, оскільки він є і допустимим, і прийнятим. Інший план (SYS_SQL_PLAN_lea) – це неприйнятий план, який був поставлений в чергу для зміни або перевірки. Він був автоматично отриманий і поставлений в чергу для перевірки; значення параметра accepted для нього встановлено на NO. Жоден з планів не є фіксованим, і обидва вони підлягають автоматичної чищенні.

    Щоб перевірити деталізований план виконання для будь-якого опорного плану, можна використовувати процедуру DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE.

    Крім того, якщо вивчити подання V $ SQL, з’являється можливість перевірити, чи використовує SQL-оператор опорний план. Якщо SQ-оператор використовує опорний план SQL plan, то plan_name для плану, обраного з опорного плану SQL, буде міститися в стовпці sql_plan_baseline подання V $ SQL. Можна поєднати уявлення V $ SQL і подання DBA_SQL_PLAN_BASELINES, використовуючи наступний запит:

    Select s.sql_text, b.plan_name, b.origin, b.accepted
    From dba_sql_plan_baselines b, v$sql s
    Where s. exact_matching_signature = b.signature
    And   s.SQL_PLAN_BASELINE = b.plan_name;


    Інтеграція з автоматичною настройкою SQL
    Під час технологічних вікон Oracle Database 11g автоматично виконує SQL Tuning Advisor – частина пакета настройки та діагностики (Tuning and Diagnostic pack). Це завдання автоматичної настройки SQL націлена на SQL-оператори, що створюють високе навантаження на систему. Такі оператори визначаються за даними про продуктивність виконання, які збираються в снепшот автоматично керованого репозиторія робочого навантаження (AWR). Якщо SQL Tuning Advisor знайде кращий план виконання для SQL-оператора, він порекомендує SQL-профіль. Для деяких з цих SQL-операторів з високим навантаженням опорні SQL-плани могли бути вже створені. Якщо рекомендація для SQL-профілю, зроблена завданням автоматичної настройки SQL, буде реалізована, то план виконання, знайдений SQL Tuning Advisor, буде доданий як прийнятий опорний план SQL.

    Можна викликати SQL Tuning Advisor вручну. Для цього достатньо для даного SQL-оператора створити набір SQL Tuning Set. Якщо SQL Tuning Advisor рекомендує SQL-профіль для оператора і він реалізується вручну, то цей профіль буде додано, як прийнятий план для опорних планів виконання операторів SQL, якщо такий існує.

    ВИСНОВОК


    Нова опція Oracle Database 11g, яка називається SQL Plan Management (SPM), забезпечує керовану еволюцію планів виконання. У разі використання SPM оптимізатор автоматично управляє планами виконання і гарантує, що будуть використовуватися тільки відомі або перевірені плани. Коли для SQL-оператора знаходиться новий план, він не буде використаний, поки для нього не буде підтверджено, що його продуктивність порівнянна з продуктивністю поточного плану чи краще її.


    SQL Plan management in Oracle Database 11 g
    June 2007
    Author: Maria Colgan

    Oracle Corporation World Headquarters 500 Oracle Parkway
    Redwood Shores, CA 94065 U.S.A.

    Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com

    Copyright© 2007, Oracle. All rights reserved.
    This document is provided for information purposes only and the
    contents hereof are subject to change without notice.
    This document is not warranted to be error-free, nor subject to any
    other warranties or conditions, whether expressed orally or implied
    in law, including implied warranties and conditions of merchantability
    or fitness for a particular purpose. We specifically disclaim any
    liability with respect to this document and no contractual obligations
    are formed either directly or indirectly by this document. This document
    may not be reproduced or transmitted in any form or by any means,
    electronic or mechanical, for any purpose, without our prior written permission.
    Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
    Other names may be trademarks of their respective owners.

    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *