Oracle 11g Materialized View зависает

Я пытаюсь создать материализованное представление в Oracle, используя предварительно созданное представление.

  create materialized view bfb_rpt_sch01.mvw_base_sales
  as select * from bfb_rpt_sch01.vw_base_sales;

Эта команда не будет выполняться и зависнет. Я подумал, что, возможно, это как-то связано с неправильным написанием представления. Поэтому я выполнил следующий запрос к представлению.

  select count(*) from bfb_rpt_sch01.vw_base_sales

Этот запрос выполняется около 6 минут и возвращает 2,7 миллиона. Это говорит мне, что проблема не в представлении, но я могу ошибаться.


view freeze performance oracle materialized
person michael cantin    schedule 10.09.2013    source источник
comment
Дайте определение зависанию. Вы уверены, что оператор CREATE не просто требует больше времени, чем вы надеялись, чтобы полностью материализовать результат? Копирование данных, создание UNDO и REDO и т. д. может быть не быстрым. Во многих случаях COUNT(*) довольно легко оптимизировать, поскольку все, что нужно сделать Oracle, — это просмотреть индекс по первичному ключу, и поскольку Oracle не нужно делать такие вещи, как вычислительные функции, которые применяются к проекции.   -  person Justin Cave    schedule 11.09.2013
comment
Ну, в настоящее время у нас 35 минут в подсчете. Возможно, есть другой способ проверить, что он создает материализованное представление? Кроме того, представление на самом деле представляет собой 6 подзапросов, которые объединяются вместе. Я не верю, что индекс используется, когда он подсчитывает количество строк, но я могу ошибаться. Первоначальная причина, по которой я создаю это представление, заключается в том, что я могу создать индекс для MVW, чтобы ускорить мои запросы.   -  person michael cantin    schedule 11.09.2013
comment
Вы видите время синхронизации сеанса в базе данных? Как выглядят ожидания? Это в первую очередь связано с вводом-выводом? Сколько данных представляют 2,7 миллиона строк в МБ/ГБ? Сколько времени потребуется, если вы SELECT * FROM view_name извлечете все 2,7 миллиона строк на свой локальный компьютер? Каковы планы запросов для оператора CREATE по сравнению с SELECT? Это то, что вы собираетесь регулярно обновлять? Или вы будете постепенно обновляться (в этом случае более длительная начальная загрузка может быть вполне приемлемой)?   -  person Justin Cave    schedule 11.09.2013
comment
Так что я чувствую, что мой план объяснения использует только один подзапрос в представлении, но, тем не менее, я разместил некоторые статистические данные ниже. Я не совсем уверен, на что смотреть здесь. Сеанс логических чтений 250777 последовательный получает 224273 без работы - последовательное чтение получает 223965 физических чтений 222506 непротиворечивый получает прямое 222273 физических чтения прямое 222273 блок БД получает 26504 блок БД получает прямое 26082 физическое чтение запросов ввода-вывода 13982 общее количество запросов ввода-вывода на физическое чтение 13982 Количество выданных операций ввода-вывода на чтение 13965 Эффективное время ввода-вывода 13082444 запросов ввода-вывода на физическую запись 816 общее количество запросов ввода-вывода на физическую запись 816   -  person michael cantin    schedule 11.09.2013
comment
Кроме того, весь экспортированный файл имеет размер 252 725 КБ. На это ушло около 13 минут. План объяснения показывает, что обычно используется полное сканирование таблицы почти для всех объединений. Я не уверен, что этой информации достаточно для вас, просто дайте мне знать, если я что-то упустил.   -  person michael cantin    schedule 11.09.2013

Ответы (1)


arrow_upward
1
arrow_downward

Мне удалось выяснить свою проблему. Мой (CREATE MATERIALIZED VIEW AS) использовал объяснение, отличное от моего (CREATE TABLE AS). Если бы мой код содержал следующую строку кода, он работал бы совершенно нормально как (CREATE TABLE AS), но продолжал бы зависать в течение 48+ часов, прежде чем произошел сбой при использовании (CREATE MATERIALIZED VIEW AS).

WHERE a.column_name NOT IN (SELECT b.column_name FROM B) --culprit

Я изменил код, используя следующее, и теперь он работает нормально.

WHERE NOT EXISTS (SELECT NULL FROM B WHERE a.column_name = b.column_name) --works

Я не уверен, почему это происходит, возможно, ошибка? Я недостаточно знаю об ORACLE, чтобы позвонить.

person michael cantin    schedule 13.09.2013
comment
Часть оптимизатора запросов отключается во время создания mview (не знаю почему, но вы найдете информацию об этом на сайте поддержки Oracle). Такой же трюк помог мне однажды, иногда помогает убедиться, что столбец, выбранный в not in (select ...), помечен not null. - person Mat; 13.09.2013