Самоналагоджувальна база даних: керовані програми та налаштування SQL. Частина 1, Інтеграція додатків і даних, Бази даних, статті


Введення


За минуле десятиліття було виявлено дві чіткі тенденції:


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

Одна з важливих частин налаштування роботи систем баз даних Oracle – Це налаштування SQL-пропозицій. Налаштування SQL включає в себе три основних етапи:


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

Ці три етапи повторюються до тих пір, поки система не досягне задовільного рівня, або до тих пір, поки не залишиться пропозицій для настройки. Експерти – АБД або розробники додатків, які мають глибокі знання в області додатків і систем баз даних, зазвичай виробляють саме таку настройку.

Коригувальні дії можуть включати один або декілька наступних кроків:


  1. Накопичувати і оновлювати статистичні дані, які використовуються оптимізатором запитів для побудови планів виконання. Наприклад, створення гістограми в стовпці, що містить асиметричні (skewed) дані.
  2. Змінити значення деякого параметра конфігурації, який буде впливати на побудову плану виконань оптимізатором запитів. Наприклад, застосувати значення optimizer_mode до first_rows_10.
  3. Переписати SQL-пропозиція для використання у відповідній SQL конструкції. Наприклад, коли можливо, замінити оператор UNION на UNION-ALL.
  4. Створити або видалити структуру доступу до даних таблиці. Наприклад, створити індекс або матеріалізоване уявлення.
  5. Додати вказівки оптимізатора в пропозицію. Наприклад, використовувати покажчик (hint) INDEX в таблиці для зміни full table scan (повне сканування таблиці) на index range scan (сканування індексного діапазону).

Процес ручного налаштування SQL ставить перед розробником кілька завдань. По-перше, він вимагає висококваліфікованої експертної оцінки в декількох складних областях: оптимізація запитів, розробка доступу, SQL-проектування (design). По-друге, це трудомісткий процес, тому як кожна пропозиція унікально і вимагає індивідуального рішення, і, крім того, число пропозицій може бути дуже велике, наприклад, більше тисячі. По-третє, потрібні глибокі знання структури схеми (тобто, визначення уявлень, індексів, розмірів таблиць, і т.д.) і моделі використовуваних даних додатків. Нарешті, SQL настройка є безперервним процесом, тому що обсяг SQL-роботи весь час змінюється, наприклад, коли використовується модуль нового додатку. Далі, зміни в структурі доступу до даних (наприклад, коли створюється або віддаляється індекс або матеріалізоване уявлення), дуже ймовірно внесуть зміни в плани виконання, змушуючи розробника додатків почати все заново. Рисунок 1 ілюструє ручний процес налаштування SQL.

Рисунок 4. Створення і використання SQL Profile

Аналіз шляху доступу


Automatic Tuning Optimizer надає поради та по індексах. Ефективне індексування – це добре відома методика налаштування, яка може значно поліпшити виконання SQL-пропозицій, виключивши повний перегляд даних. Будь-які індексні рекомендації, згенеровані Automatic Tuning Optimizer, є специфічними для заданого настроюваного SQL-пропозиції. За рахунок цього забезпечується швидке знаходження проблеми, пов’язані з конкретним SQL-пропозицією.

Оскільки Automatic Tuning Optimizer не виробляє аналіз, як його рекомендації впливають на робоче навантаження SQL-пропозиції, він рекомендує напускати Access Advisor на SQL-пропозиція, щоб представити його навантаженість. Access Advisor накопичує всі поради, поставлені по навантаженості кожного SQL-пропозиції і об’єднує їх в глобальні рекомендації по повній навантаженості.

Аналіз SQL-структури


Часто SQL-пропозиція може бути занадто ресурсоємним тільки тому, що воно погано написано. Це зазвичай трапляється, коли існують різні (але не обов’язково семантично еквівалентні) способи написання пропозиції для досягнення того ж самого результату. Наприклад, SQL-пропозиція може давати той же результат, коли його оператор UNION замінюється на UNION-ALL. Той же самий результат можливий, якщо для виключення породження подвійних рядків, усунення дублювання робиться за допомогою надлишкового оператора UNION. В цьому випадку його краще замінити на UNION-ALL, що усуне з плану виконань витратний етап усунення дублювання. Інший приклад – це використання підзапиту NOT IN в той час, як підзапит NOT EXIST продукував би той же результат набагато ефективніше.

З’ясування того, яка з цих альтернативних форм написання є найбільш ефективною – це жахлива завдання для розробника програм, так як вона вимагає глибоких знань як в області властивостей даних (Наприклад, немає порожніх значень в стовпці), так і в області розуміння семантики (тобто, смислового значення) SQL-конструкцій.

Крім того, на стадії розробки розробники в основному зосереджені на тому, як написати SQL-речення так, щоб воно давало бажаний результат і покращувало продуктивність. Іноді проста помилка може змусити SQL-пропозиція виконуватися дуже погано. Хороший тому приклад – це невідповідність типу стовпця і значення його предиката, що по суті виключає використання індексів, навіть якщо вони існують і доступні.

Automatic Tuning Optimizer виконує аналіз SQL-структури, щоб виявити погано написані SQL-пропозиції, і рекомендує піддати результат користувальницької повірці на предмет знаходження альтернативних способів написання SQL-пропозиції для поліпшення його продуктивності. Для допомоги в написанні правильних SQL-пропозицій і з метою профілактики розробники можуть запускати SQL Tuning Advisor в режимі Limited.

В процесі побудови плану при аналізі SQL-структури Automatic Tuning Optimizer генерує великі анотації та діагностики і пов’язує їх з планом виконання. Анотації містять рішення, зроблені оптимізатором, і призводять підстави таких рішень. Використовуючи ці підстави, асоційовані з дорогими операторами плану виконання, Automatic Tuning Optimizer дає рекомендації або про те, як переписати SQL-пропозицію, або про те, як змінити схему, для поліпшення продуктивності.

Існують різні підстави, пов’язані зі структурою SQL-пропозиції, які можуть викликати погане виконання. Частина з них-синтаксичні, частина – семантичні, а деякі просто є проблемами розробки. Ми згрупували ці підстави за трьома категоріями:


  1. Semantic-Based Constructs: Конструкція типу підзапит NOT IN, коли замінюється відповідним, але не є семантичним еквівалентом підзапиту NOT EXISTS, може привести до істотного підвищення продуктивності. Однак така заміна можлива, тільки якщо в пов’язаних (join) стовпцях об’єднання не присутні NULL-значення, гарантуючи, таким чином, один і той же результат при використанні будь-якого з цих операторів. Інший приклад – заміна UNION на UNION-ALL, якщо немає ймовірності отримання дубльованих рядків у результаті.
  2. Syntax-based Constructs: Багато хто з них пов’язані з тим, як предикати визначені в SQL-реченні. Наприклад, якщо предикат, такий як col =: bnd використовується з col і: bnd, що мають різні типи, то такий предикат не може бути використаний як наїзник (driver) індексу. Точно так же предикат, що залучає функцію або вираз (наприклад, func (col) =: bnd, col +1 =: bnd), не може бути використаний як наїзник індексу, якщо немає функціонального індексу на вираз або на саме функцію.
  3. Design Issue: Випадкове використання, наприклад, декартового твору (Cartesian product) є звичайною проблемою, що зустрічається в тому випадку, коли одна з таблиць не з’єднана ні до якої іншої таблиці в SQL-реченні. Це може статися, якщо в запиті бере участь велика кількість таблиць.

Частина II

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


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

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

Ваш отзыв

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

*

*