Самоналагоджувальна база даних: керовані програми та налаштування 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.

Малюнок 1. Ручна настройка SQL

Для допомоги адміністратора бази даних (АБД) і прикладного розробнику, які зіткнулися з цією проблемою, кілька компаній, що випускають програмне забезпечення, розробили інструменти діагностики та моніторингу, які намагаються знайти вузькі місця роботи системи бази даних і запропонувати дії для їх усунення. Деякі з цих інструментів роблять, в більшості випадків, дуже хорошу роботу. Але, як правило, це інструменти не інтегровані з системним компонентом, на який вони націлені. Наприклад, оптимізатор запитів – це компонент системи, відповідальний за плани виконання SQL-пропозицій. На самому ж справі, оптимізатор запитів – це "чорний ящик" (black box) для цих інструментів, і тому вони повинні інтерпретувати інформацію поза базою даних, щоб здійснити настроювання. Як наслідок, результати їх налаштування менш надійні і обмежені в області дії. Крім того, недолік інтеграції призводить до того, що зовнішні інструменти завжди відстають від останніх оновлень і поліпшень оптимізатора запитів.

У Oracle 10g більша увага приділяється створенню самоврядних систем баз даних. Для здійснення автоматичної настройки і моніторингу також як і в системі, що працює на вимогу (on-demand), була введена опція, названа AWR (Automatic Workload Repository – автоматичний репоіторій навантаження). AWR кожні 30 хвилин (за замовчуванням) переглядає дані продуктивності системи та постійно (за замовчуванням протягом 7 днів) зберігає їх, як історію системної робочого навантаження. Наприклад, серед інших функції AWR ідентифікує головні SQL-пропозиції, які інтенсивно витрачають ресурси: використання процесора, читання буферів, фізичні операції з дисками, виклики синтаксичного аналізу (parse calls), використання пам'яті, що розділяється і т.д. у кожному інтервалі часу. Інша керуюча опція ADDM (Automatic Database Diagnostics Monitor – автоматичний монітор діагностики) була введена для автоматизації завдання безперервного контролю дій системи, ідентифікації високого рівня споживання системних ресурсів, і вузькі місця роботи. У плані SQL-налаштування ADDM визначає наіболнее навантажені (high load) SQL-пропозиції. Була додана ще одна опції управління, яка автоматизує збір статистичних даних у поточному інтервалі. Опція Automatic Statistic Collection доступна за замовчуванням для недавно створених баз даних Oracle 10g.

У Oracle 10g процес SQL-налаштування був автоматизований шляхом введення нової керівної опції Automatic SQL Tuning. Вона однаково добре призначена для роботи з додатками, як з OLTP, так і Data Warehouse. Automatic SQL Tuning базується на нещодавно доданої автоматичної можливості налаштування оптимізатора запитів, званої Automatic Tuning Optimizer. Automatic SQL Tuning доступна за допомогою порадника (advisor), названого SQL Tuning Advisor. SQL Tuning Advisor бере одне або кілька SQL-пропозицій і продукує добре налаштовані плани, грунтуючись на рекомендаціях з налаштування. SQL-пропозиції могли бути ідентифіковані за допомогою ADDM, AWR або вручну. Ручний процес може містити, наприклад, тестування набору SQL-пропозицій, які повинні бути ще використані, для вимірювання індивідуальної продуктивності та ідентифікації тих пропозицій, які мають недостатню продуктивність. Для забезпечення цього в Oracle 10g ми ввели новий об'єкт налаштування, названий SQL Tuning Set (STS). Малюнок 2 дає високорівневе уявлення про те, як Automatic SQL Tuning працює в Oracle 10g.

Малюнок 2. Автоматична настройка SQL

Інша частина статті організована таким чином. По-перше, ми пояснимо, як працює Automatic SQL Tuning, Потім детально розглянемо Automatic Tuning Optimizer. Далі, ми опишемо SQL Tuning Set, який дозволяє користувачеві створювати і настроювати вибрані обсяги робіт SQL. Потім ми введемо поняття первинного інтерфейсу Automatic SQL Tuning, використовую для цього Enterprise Manager і ілюструючи це прикладами. Ми наведемо опис пакету DBMS_SQLTUNE, Який групує процедури SQL-установки, що використовуються для SQL Tuning Advisor API, а також для управління SQL Tuning Set і SQL Profiles. На закінчення статті ми підіб'ємо підсумок, виконавши порівняння налаштувань в Oracle9i і Oracle 10g.

Опція Automatic SQL Tuning


Automatic SQL Tuning тісно пов'язана з оптимізатором запитів. Це дає декілька переваг:


Фактично Automatic SQL Tuning заснована на вдосконаленій версії оптимізатора запитів. Звичайний оптимізатор запитів був удосконалений в Oracle 10g для виконання додаткового аналізу перед процесом побудови плану виконання SQL-пропозиції. Ми будемо називати такий стан оптимізатора запитів, як Automatic Tuning Optimizer, Для того, щоб відрізняти цей стан від стандартного. Оптимізатор запитів (у звичайному стані) має суворі обмеження на час і системні ресурси, які він може використовувати для пошуку найкращого плану виконання заданого SQL-пропозиції. Прийнятний час оптимізації зазвичай менше секунди і не більше, ніж кілька секунд. Через це суворого вимоги оптимізатор може виконувати лише обмежений план пошуку, використовуючи евристику тоді і тільки тоді, коли це може скоротити час на оптимізацію. Отже, оптимізатор запитів не може виконати трудомісткий аналіз і етапи перевірки перед процесом генерації плану.

Навпаки, виконання Automatic Tuning Optimizer зазвичай займає набагато більше часу, зазвичай кілька хвилин для того, щоб виконати необхідні дослідження та етапи перевірки, як частини процесу встановлення. Таким чином, Automatic Tuning Optimizer має набагато більш високу ймовірність згенерувати добре налагоджений план. Automatic Tuning Optimizer використовує динамічний відбір і часткове виконання (тобто, виконання фрагментів SQL-пропозицій), для перевірки власної оцінки вартості, вибірковості й кардинального числа (cardinality). Він також використовує передісторію виконання SQL-пропозицій для визначення оптимальних параметрів налаштування (Наприклад, режиму оптимізатора).

Функціональні можливості Automatic Tuning Optimizer реалізуються за допомогою порадника SQL Tuning Advisor. SQL Tuning Advisor приймає SQL-пропозиція і передає його разом з іншими вхідними параметрами в Automatic Tuning Optimizer. Потім Automatic Tuning Optimizer виконує чотири типи аналізу в процесі генерації плану.

Функціональні можливості Automatic Tuning Optimizer доступні через порадника, названого SQL Tuning Advisor. SQL Tuning Advisor приймає SQL-пропозиція і передає його разом з іншими вхідними параметрами в Automatic Tuning Optimizer. Потім Automatic Tuning Optimizer виконує чотири типи аналізу в процесі генерації плану.


  1. Statistics Analysis (Статистичний Аналіз): Automatic Tuning Optimizer перевіряє кожен об'єкт запиту на пропущені або застарілі дані статистики і дає рекомендації для збору відповідної (relevant) статистики. Він також збирає допоміжну інформацію для постачання відсутньою або виправлення застарілої статистики у випадку, якщо не виконані рекомендації.
  2. SQL Profiling (Профілірваніе SQL): Automatic Tuning Optimizer перевіряє власні оцінки і збирає допоміжну інформацію, щоб видалити помилкові оцінки. Він також збирає допоміжну інформацію у формі самоопределяемой параметрів налаштування оптимізатора (наприклад, за першими рядками, а не по всіх рядках – first rows vs. all rows), заснованих на минулій історії виконання SQL-пропозицій. Він формує SQL Profile, використовуючи допоміжну інформацію, і дає рекомендації для його створення. Коли SQL Profile вже створено, він задіює оптимізатор запитів (у звичайному стані) для генерації добре налагодженого плану.
  3. Access Path Analysis (Аналіз шляхів доступу): Automatic Tuning Optimizer виявляє, які нові індекси можуть бути використані для поліпшення доступу до кожної таблиці в запиті і потім робить відповідні рекомендації для їх створення.
  4. SQL Structure Analysis (Аналіз SQL-структури): у цьому випадку Automatic Tuning Optimizer намагається ідентифікувати SQL-пропозиції, плани яких визначаються як невдалі, і радить, як їх реструктуризувати. Пропозиції щодо змін SQL-коду можуть ставитися як до синтаксису, так і до семантикою.

Кожен тип аналізу детально розглянуто в наступному розділі "Automatic Tuning Optimizer".

Результати (outputs), згенеровані Automatic Tuning Optimizer, Передаються користувачеві через SQL Tuning Advisor у вигляді ради (advice). Рада складається з однієї або декількох рекомендацій, кожна з яких постачається поясненням і оцінкою вигоди при здійсненні. Користувачеві надається можливість прийняття ради, і, таким чином, налаштування відповідного SQL-пропозиції завершується.

Automatic Tuning Optimizer разом з SQL Tuning Advisor становлять компонент Automatic SQL Tuning сервера Oracle. Архітектура Automatic SQL Tuning, як показано на малюнку 3, ілюструє функціональні відносини між Automatic Tuning Optimizer і SQL Tuning Advisor.

Automatic SQL Tuning є частиною просуває Oracle стратегії переходу на керовану за порадами модель адміністрування баз даних. Модель припускає, що для критичних функцій управління базою даних сервер бази даних повинен дати корисну пораду користувачам про те, як краще користуватися ними. Механізм самої бази даних тепер зроблено більш інтелектуальним, щоб користувачі Oracle для управління своїми базами даних найбільш оптимальним способом більше не покладалися на сторонні інструменти та рішення.

Малюнок 3. Архітектура опції Automatic SQL Tuning

Оптимізатор автоматичної настройки – Automatic Tuning Optimizer


Важливо звернути увагу на те, що Automatic Tuning Optimizer – це оптимізатор запитів, який працює в автоматичному режимі спеціальним налаштування. Тому Automatic Tuning Optimizer виконує ті ж функції, що і звичайний оптимізатор запитів, але з додатковими можливостями і функціональністю. Ця додаткова функціональність включає в себе етапи перевірки правильності власних внутрішніх оцінок, а також підтримки зовнішньої інформації (наприклад, статистичні дані). Сюди ж включаються етапи дослідження для знаходження нових шляхів доступу, істотно підвищують продуктивність, і аналіз можливості проведення змін до SQL-пропозиції для ефективної обробки даних.

SQL Tuning Advisor переводить оптимізатор в режим автоматичної настройки, щоб отримати пораду для SQL-пропозиції. Така рада може складатися з різних рекомендацій від Automatic Tuning Optimizer, Що стосуються статистики, плану запитів, шляхів доступу (наприклад, індексів) та SQL-конструкцій. На додаток до сгенерованими рекомендаціям він може зібрати певну інформацію для власного використання SQL-пропозицією. Це – допоміжна інформація, яка буде використовуватися разом із статистикою бази даних. Automatic Tuning Optimizer використовує кілька типів аналізу: статистичний аналіз, SQL-профілювання (profiling), аналіз шляху доступу та аналіз SQL-структури. Кожен з цих аналізів може дати окрему рекомендацію для SQL-пропозиції.

Статистичний Аналіз


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

Як тільки запис фактично використовуваної статистики закінчена, Automatic Tuning Optimizer продовжує перевіряти, чи є в наявності статистичні дані, асоційовані з об'єктами запиту (тобто, таблиця, індекс або матеріалізоване уявлення). Якщо статистика доступна, то перевіряється її точність (тобто, свіжість і актуальність). Щоб перевірити точність статистики, він буде брати дані з відповідного об'єкта запиту, і використовувати вибраний результат для перевірки точності.

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

Зауважимо, що аналіз статистики має два види висновку:


  1. рекомендації для аналізу об'єктів, для яких або не знайдена статистика, або знайдена, але застаріла, і
  2. Допоміжна інформація для відшкодування опущеною або коригування застарілої статистики.

Це гарна ідея для здійснення рекомендацій Analyze і повторного запуску Automatic SQL Advisor. Допоміжна інформація використовується у випадку, якщо рекомендації Analyze не були здійснені. Допоміжна інформація зберігається в SQL Profile, який описаний у наступному розділі.

Пофілірованіе SQL-пропозицій – SQL Profiling


Основний етап перевірки під час SQL-профілювання – це перевірка оптимізатором запитів власних оцінок вартості, вибірковості й кардинального числа (cardinality). Існує безліч факторів, які можуть викликати великі помилки в оцінках і надихнути оптимізатор на генерацію неоптимального (sub-optimal) плану. Ось деякі з них:


Для генерації хорошого плану оптимізатором запитів важливо зробити так, щоб оцінки не містили великих помилок. Отже, для Automatic Tuning Optimizer дуже важливо перевірити точність власних оцінок і видалити або, в крайньому випадку, значно зменшити помилки в них.

Іншою причиною генерації неоптимального плану є неправильні параметри налаштування оптимізатора. Наприклад, якщо користувач збирається вибрати тільки кілька рядків за раз і якщо розмір результату дуже великий, то з метою зменшення часу важливо провести оптимізацію: спочатку для кількох рядків, а вже потім для всіх. Тому для такого SQL-пропозиції важливо встановити режим оптимізатора first_rows, а не all_rows.

Протягом SQL Profiling виконуються етапи перевірки Automatic Tuning Optimizer для перевірки правильності своїх власних оцінок. Перевірка правильності складається з аналізу вибірки даних шляхом застосування до неї відповідних предикатів. Нова оцінка проводиться за результатами вибірки даних. Ця нова оцінка буде точніше, тому як розмір вибірки може бути у випадку необхідності відкоректований для гарантовано високого рівня точності. Нова оцінка порівнюється зі звичайною, і, якщо відмінності будуть досить великі, то продукується фактор корекції, щоб привести у відповідність звичайну статистику з новою. Інший метод правильності перевірки оцінки полягає у виконанні фрагмента SQL-пропозиції (Тобто, часткове виконання). Метод часткового виконання ефективніше, ніж метод вибірки, коли відповідні предикати забезпечують ефективний доступ. Automatic Tuning Optimizer вибирає відповідний оцінний метод перевірки правильності.

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

Automatic Tuning Optimizer формує SQL Profile, якщо він згенерував допоміжну інформацію протягом аналізу статистики (тобто, фактори налаштування статистики) або протягом SQL Profiling (тобто, коригувальні фактори, налаштовують установки оптимізатора). Коли SQL Profile сформований, він генерує рекомендацію для користувача по створенню SQL-профілю.

Оскільки використовувані для оцінної статистик методи вибірки даних або часткового виконання можуть бути дорогими або віднімати багато часу процесами, то SQL Profiling не виконується в режимі Limited (Обмежено). Вам слід використовувати режим Comprehensive (комплексний), щоб дозволити Automatic Tuning Optimizer згенерувати SQL Profile.

SQL Profile


SQL Profile є колекцією допоміжної інформації, яка формується протягом автоматичної настройки SQL-пропозиції. Таким чином, SQL Profile для SQL-пропозиції є тим же, ніж статистика є для таблиці або індексу. Одного разу створений SQL Profile використовується оптимізатором запитів (у звичайному режимі) разом з існуючою статистикою, для того щоб згенерувати добре налагоджений план для даного SQL-пропозиції.

Коли створюється SQL Profile, він постійно зберігається в словнику даних. Одного разу створений SQL Profile буде використовуватися кожен раз оптимізатором запиту, при компіляції (так як оптимальний) відповідного SQL-пропозиції для створення добре налагодженого плану. Для управління SQL Profile надається повний набір функцій.

На малюнку 4 показаний потік процесів створення та використання SQL Profile. Процес складається з двох окремих стадій: стадія настроювання SQL і стадія звичайної оптимізації. На стадії налаштування SQL АБД вибирає SQL-пропозиція для автоматичної настройки та запускає SQL Tuning Advisor, Використовуючи GUI інтерфейс Enterprise Manager або використовує інтерфейс командного рядка (див. розділ "DBMS_SQLTUNE Package"). SQL Tuning Advisor залучає Automatic Tuning Optimizer, Можливо, з SQL Profile в генерування рекомендацій налаштування. Якщо SQL Profile створений, то АБД може прийняти його. Коли SQL Profile створений, то він зберігається в словнику даних. Тоді на наступній стадії, коли кінцевий користувач запускає те ж саме SQL-пропозиція, оптимізатор запитів (у звичайному режимі) використовує SQL Profile для генерації добре налагодженого плану. Використання SQL Profile залишається повністю прозорим для кінцевого користувача.

Дуже важливо помітити, що створення і використання SQL Profile не вимагає внесення змін у вихідний текст програми. Це є ключем до налаштування 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>

*

*