Cure d; бази даних про схуднення, яку дієту вибрати

даних

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

Зверніть увагу, що мова йде про очищення, тобто про повне знищення даних, а не про архівування, що є абсолютно іншою технікою, хоча доповнює, але регулюється дуже точними правилами, які визначають абсолютно інший формат, ніж формат даних про походження, незалежний від будь-які технічні обмеження. Але повернемось до нашої улюбленої теми ОЧИСТКА дані, як ви часто бачили, бачите, як дорогі бази даних безжально зростають, не існуючи процедури чи лікування, які могли б полегшити ці дані, які з часом застаріли і до яких більше не здійснюється доступ ні в читанні, ні в письмі, а з іншого руки, які забруднюють столи, які ризикують значно погіршити ефективність. Тож невеликий засіб для схуднення не було б розкішшю повернути собі другу молодість і поважати канони краси, що заповнюють деякі журнали, хоча я сумніваюся, що база даних спричинить таке марення ... Ефект набагато менш привабливий, дарую вам ...

То до кого ми звернемось, щоб знайти це чудо-засіб, яке призведе до втрати кількох розмірів за найкоротший час? Але звичайно до чергового дієтолога, нашого дорогого DBA, який в кінцевому підсумку менше хихикає за своїм екраном.

Аналіз надмірної ваги

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

Критерій схуднення

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

Правильна дієта для схуднення

Тепер нам залишається лише застосувати лікувальне лікування відповідно до наших можливостей та наших можливостей.

Різка дієта

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

У версії Oracle 11g цю опцію вдосконалено, тому більше не потрібно створювати розділи заздалегідь, оскільки вони створюються автоматично, як тільки новий рядок повинен бути вставлений у розділ, який ще не існує.

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

  • Окремий стовпець не може становити критерій розділення, і цей стовпець повинен мати тип DATE або NUMBER
  • Розбиття інтервалів не дозволяється для таблиць, організованих в індексах IOT

Глибина інтервалу розділення може бути обмежена днем, тижнем, місяцем, кварталом…. за такими функціями: INTERVAL (NUMTODSINTERVAL (1, 'day')), INTERVAL (NUMTODSINTERVAL (7, 'day')), INTERVAL (NUMTOYMINTERVAL (1, 'month')), INTERVAL (NUMTOYMINTERVAL (3, 'month') )))… . Оскільки назва розділів генерується автоматично відповідно до внутрішніх конвенцій Oracle, рекомендується перейменовувати їх відповідно до власних стандартів.

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

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

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

  • Завантаження нових цільових секціонованих таблиць із вихідних таблиць

Класична дієта

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

Матеріалізований вигляд дозволяє створити фізичний вигляд таблиці. На відміну від стандартного подання, дані вихідного об'єкта дублюються у матеріалізованому поданні (REFRESH COMPLETE) і можуть синхронізуватися через рівні проміжки часу на дельті оновлення, що надходить до вихідного об'єкта з моменту створення матеріалізованого подання або його останньої синхронізації (REFRESH ШВИДКО).

Для того, щоб мати можливість зберігати дані матеріалізованого подання, ми спочатку побудуємо таблицю, в якій будуть зберігатися дані матеріалізованого подання. Створюючи матеріалізований вигляд, ми будемо посилатися на цю таблицю за допомогою опції ON PREBUILT TABLE. Тож ми можемо згодом зберегти цю таблицю, щоб її можна було перейменовувати у своє початкове позначення.

У нашому випадку вкрай важливо, щоб матеріалізовані подання могли бути синхронізованими, але, як завжди, Oracle накладає певну кількість обмежень, які обмежують обсяг матеріалізованих поглядів у REFRESH FAST або інкрементному режимі.

Для використання покрокового оновлення матеріалізований вигляд не повинен розглядатися як складний запит, тому він не повинен містити у своєму запиті конституції:

  • Застереження CONNECT BY
  • Оператор набору МІНУС, ІНТЕРСЕКТ, СОЮЗ ВСІХ
  • Слова або функції DISTINCT, UNIQUE, SYSDATE
  • Деякі операції UNION, коли список стовпців порядку SELECT є іншим.

Коли запит на створення матеріалізованого подання використовує підзапити, для покрокового оновлення потрібно:

  • МАТЕРІАЛІЗОВАНИЙ ЖУРНАЛ ПЕРЕГЛЯДУ повинен містити стовпці об’єднання підзапиту.
  • Підзапит повинен використовувати умову EXISTS для доступу до вкладеного запиту (IN заборонено)
  • Умова НЕ ІСНУЄ заборонено
  • Кожна таблиця може відображатися лише один раз у стані ІСНУЄ та в об'єднаннях
  • Кожна таблиця, яка бере участь у вкладених підзапитах, повинна мати первинний ключ
  • Допускаються лише екві-приєднання
  • Підзапити можуть використовувати лише логічний оператор І (АБО коли повертає 1 рядок)
  • З реченням ON PREBUILT TABLE стовпці об’єднання повинні бути присутніми в журналах матеріалізованого подання (MATERIALIZED VIEW LOG).

Див. Обмеження на матеріалізовані подання з поступовим оновленням
Щоб оптимізувати створення матеріалізованих поглядів, слід дотримуватися цих двох принципів:

  • Паралелізація команди SELECT за допомогою підказки Oracle
  • Повне оновлення матеріалізованого подання з опцією atomic_refresh, встановленою на FALSE, деактивація цієї опції дозволяє масове навантаження (DIRECT PATH), а не рядок за рядком.

Тепер із цієї моделі даних, яка обмежує наш периметр, візьмемо для прикладу створення матеріалізованого подання: EASY_DET_PRICE (червоним кольором)


Сценарій для створення матеріалізованого подання Create_View_EASY_DET_PRICE.sql повинен виглядати так:

Обробку очищення матеріалізованими поданнями слід розбити на 2 фази, оскільки ця обробка вимагає недоступності бази даних для програми через перейменування матеріалізованих подань на позначення вихідних таблиць. Кожна з цих фаз пов’язує ряд операцій, які можна виконувати паралельно.

  • ЕТАП 1


1. Створення журналів матеріалізованих подань на "вихідних" таблицях

2. Створення таблиць матеріалізованих поглядів та матеріалізованих поглядів (паралельно)

  • ЕТАП 2


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

2. Синхронізація матеріалізованих переглядів у поступовому режимі (REFRESH FAST)

3. Перейменування вихідних таблиць, індексів, обмежень

4. Перейменування матеріалізованих поглядів

5. Реконструкція покажчиків

6. Реконструкція обмежень на первинні індекси, а потім посилальні обмеження

7. Розрахунок статистики Oracle

8. Повторно відкрийте базу даних, перезапустіть слухач, перезапустіть програму

Гомеопатична дієта

Отже, для цього останнього режиму ми просто будемо використовувати команду SQL, відому всім, ВИДАЛИТИ, але перед тим, як перейти до швидкого, буде краще зберегти дані для видалення в резервній таблиці, про яку ми ніколи не знаємо завжди можливо якомога більше. Хороша ідея - створити ці таблиці резервних копій за допомогою опції ROWDEPENDENCIES, яка дозволить нам вести облік видалених даних, як вважаємо за потрібне. Я звертаюся до чудової статті на цю тему. Пор: Як знайти дату та час модифікації даних

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

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

Але давайте візьмемо наш невеликий приклад із таблицею EASY_DET_PRICE і подивимося, як це перекладається.

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

1. Створення резервних таблиць, включених у процес чи ні

2. Завантаження даних для видалення в таблицях резервного копіювання

3. Видалення даних

4. Перебудова онлайн-покажчиків

7. Розрахунок статистики Oracle

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