Materialized view, oracle mechanics

Тема попереднього поста про BEGIN_OUTLINE_DATA виникла під час перевірки дійсно нового і, не побоюся цього слова, революційного фікса:

зазначеного Леонідом Борчуков при обговоренні неоднозначних результатів оптимізації запитів створення / повного оновлення матеріалізованих уявлень в версіях Oracle 11.2

1) в попередньому пості забув згадати про Temporary Undo - вкрай корисну можливість перемикати запис undo для тимчасових таблиць з системного undo табличного пр-ва у тимчасове, що дозволяє:

  • знизити загальний необхідний розмір undo
  • як наслідок - зменшити генерований обсяг redo
  • допускає DML на тимчасових таблицях фізичного Стенбі, де Temporary Undo включений за замовчуванням

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

При виконанні процедури повного неатомарного поновлення матеріалізованого уявлення:

рекурсивно виконується спостережуваний в V $ SESSION і V $ OPEN_CURSOR запит типу V $ OPEN_CURSOR.CURSOR_TYPE = 'OPEN-RECURSIVE':

Добре відомо, що плани рекурсивних запитів повного оновлення (а також плани CTAS створення CREATE MATERIALIZED VIEW) мають особливості, наприклад Рекурсивні запити для materialized view з використанням db link

Про особливості паралельного виконання запитів DML, виконуваних при кумулятивному (non-atomic) ресурсоємних оновленні materialized view значного обсягу (> 300 млн рядків), побудованого з відносно невеликих вихідних таблиць, розміщених на віддаленій бд (dblink)

Навігація по публікаціям

Схожі статті