Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 производительность матвью  [new]
Тоша
Member

Откуда: Москва
Сообщений: 14
День добрый.
Проблема собственно в следующем. Есть таблица фактов. У каждого факта есть дата и некоторые атрибуты. Таблица партиционирована по дате. Есть необходимость создать для этой таблицы матвью с округлением даты до недели и матвью с округлением даты до месяца. Для решения поставленно задачи было предложен следующий алгоритм (без использования матвью). создаем таблицы необходимой структуры и далее грузим в них данные циклом по партициям с использованием exchange partition. Процедура запускается раз в неделю. Новые данные (специфика) появляются во всех партициях исходной таблицы каждый день, но 95% из них попадает в последнюю (сегодняшнюю) партицию. Этот факт не позволяет ограничить объем входных данных необходимым набором партиций - приходится читать все. И тут то и появилась идея с матвью. Реализовали. Матвью ON DEMAND REFRESH FAST. Главный упор делался на быстрое обновление, т.к. именно выбор новых свежих записей был трудоемок. Созданы логи все как положенно. А теперь самое интересное - производительность.
22 мар 06, 10:52    [2475122]     Ответить | Цитировать Сообщить модератору
 производительность матвью -часть 2  [new]
Тоша
Member

Откуда: Москва
Сообщений: 14
...
22 мар 06, 10:53    [2475127]     Ответить | Цитировать Сообщить модератору
 производительность матвью - часть 3  [new]
Тоша
Member

Откуда: Москва
Сообщений: 14
Итак объем данных в каждой партиции исходной таблицы 50 млн. Ширина таблицы ~300 полей. Размер строки ~700 байт.
Для тестирования использовалась уменьшенная в 10 раз копия данных, т.е. 500 000 записей в дневной партиции или 3.5 млн в неделю. Эти данные скриптом обрабатывались за 6-7 минут. Эти же данные обрабатывались с использованием механизмов матвью REFRESH COMPLETE за 6-7 минут. Эти же данные обрабатывались с использованием механизмов матвью REFRESH FAST за 01:40 (час сорок).
Вопрос - почему???
Было предположение, что механизм матвью с REFRESH FAST делает UPDATE итоговой таблицы, но опыт показал, что ее очистка не влияет на время работы. Повторное обновление (без дозагругок в исходную таблицу) как и положено отрабытавает мгновенно - матвью лог то пустой. Может ли это быть связанно с ведение матвью лога или еще с чем либо.
Помогите разобраться. Заранее спасибо.
22 мар 06, 11:04    [2475205]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
Колобок
Member

Откуда:
Сообщений: 122
Нужно смотреть, что оно там делает во время FAST REFRESH.
Возможно, индексов на вьюхе нехватает.
Ещё было замечено на 9.2.0.6 что оно скрипты обновления генерит по-дурацки, подставляет всякие хинты типа HASH_SJ, когда без хинтов всё летает. Я пытался делать outlines, чтоб убрать этот HASH_SJ. Немного помогло, но оно там обновляет с помощью MERGE, а на MERGE оутлайн сделать нельзя.
Вобщем, криво оно там как-то всё сделано.
22 мар 06, 11:58    [2475573]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
Тоша
Member

Откуда: Москва
Сообщений: 14
Индексов нет и быть не может. при таких объемах любой индекс тормозит страшно загрузки.
Дурацкий вопрос - как посмотреть скрипты обновления?
22 мар 06, 14:06    [2476457]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
zipfer
Member

Откуда: Moscow
Сообщений: 106
Тоша
Индексов нет и быть не может. при таких объемах любой индекс тормозит страшно загрузки.
Дурацкий вопрос - как посмотреть скрипты обновления?


В смысле? Посмотреть таки, шо делает dbms_mview.refresh?

М.б. в SQLPlus стоит сделать:

alter session set events '10046 trace name context forever, level 12';
exec dbms_mview.refresh('...');
alter session set events '10046 trace name context off';
Там все будет расписано.
И кстати, мат вью создано как nologging?
22 мар 06, 14:48    [2476707]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
Тоша
Member

Откуда: Москва
Сообщений: 14
Матвью создано на основе пребилт-таблицы. Обе таблицы (источник и матвью) имеют NOLOGGING - это естественно для таких объемов данных.

Всетаки непонятно почему REFRESH FAST получается так кординально медленнее чем REFRESH COMPLETE.

Работаем на Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
22 мар 06, 15:07    [2476840]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
zipfer
Member

Откуда: Moscow
Сообщений: 106
Тоша
Матвью создано на основе пребилт-таблицы. Обе таблицы (источник и матвью) имеют NOLOGGING - это естественно для таких объемов данных.

Всетаки непонятно почему REFRESH FAST получается так кординально медленнее чем REFRESH COMPLETE.

Работаем на Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production


SELECT refresh_method FROM user_mviews WHERE mview_name = 'Ваше вью'
Вы вообще-то уверены что у Вас fast refresh?
22 мар 06, 15:30    [2476938]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
arhey
Member

Откуда: Санкт-Петербург. Россия... :)
Сообщений: 221
Имхо.

Не совсем понятно почему вы ожидаете чего-либо иного.
Fast Refresh при отсутствии индексов сделает куда больше FTS,
чем один Complete refresh.

Почему вы думаете, что внутренние алгоритмы обновления мат. вида,
будут отличаться от случая изменения некоторого количества строк в огромной таблице.

С индексами будет быстрее. Без индексов так, как получается у вас.
22 мар 06, 16:26    [2477289]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью - часть 3  [new]
HX
Member

Откуда: Moscow
Сообщений: 2454
Тоша
Итак объем данных в каждой партиции исходной таблицы 50 млн. Ширина таблицы ~300 полей. Размер строки ~700 байт.
Для тестирования использовалась уменьшенная в 10 раз копия данных, т.е. 500 000 записей в дневной партиции или 3.5 млн в неделю. Эти данные скриптом обрабатывались за 6-7 минут. Эти же данные обрабатывались с использованием механизмов матвью REFRESH COMPLETE за 6-7 минут. Эти же данные обрабатывались с использованием механизмов матвью REFRESH FAST за 01:40 (час сорок).
Вопрос - почему???
Было предположение, что механизм матвью с REFRESH FAST делает UPDATE итоговой таблицы, но опыт показал, что ее очистка не влияет на время работы. Повторное обновление (без дозагругок в исходную таблицу) как и положено отрабытавает мгновенно - матвью лог то пустой. Может ли это быть связанно с ведение матвью лога или еще с чем либо.
Помогите разобраться. Заранее спасибо.

см.
2.3 System Performance Impact on Refreshes


MATERIALIZED VIEW REFRESH: Locking, Performance, Monitoring
22 мар 06, 16:35    [2477334]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
Тоша
Member

Откуда: Москва
Сообщений: 14
автор
Не совсем понятно почему вы ожидаете чего-либо иного.
Fast Refresh при отсутствии индексов сделает куда больше FTS,
чем один Complete refresh.


Вариант матвью реализовывался специально для того, чтобы не перечитывать 2-3 тарабайтную исходную таблицу, а довольствоваться матвью логом, в котором содержатся все необходимые для пересчета данные. ROWID, SEQUENCE, INCLUDING NEW VALUES для лога были указаны.

автор
см.
2.3 System Performance Impact on Refreshes


Спасибо всем за ответы.
23 мар 06, 10:30    [2479652]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
Колобок
Member

Откуда:
Сообщений: 122
Тоша
Вариант матвью реализовывался специально для того, чтобы не перечитывать 2-3 тарабайтную исходную таблицу, а довольствоваться матвью логом, в котором содержатся все необходимые для пересчета данные. ROWID, SEQUENCE, INCLUDING NEW VALUES для лога были указаны.

Индекс нужен для того, чтобы найти в матвьюхе те строки, которые нужно обновить.
23 мар 06, 14:18    [2481389]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
Тоша
Member

Откуда: Москва
Сообщений: 14
Колобок
Индекс нужен для того, чтобы найти в матвьюхе те строки, которые нужно обновить

Вот все и встало на свои места. Индекса нет, но и данных в таблице нет. Время большое. Видимо придется изобретать свой велосипед, пожертвовать местом, уникальностью, делать дополнительные группировки при использовании. Наверное по другому не получится. А жаль. :-(
23 мар 06, 14:49    [2481613]     Ответить | Цитировать Сообщить модератору
 Re: производительность матвью  [new]
Колобок
Member

Откуда:
Сообщений: 122
Тоша
Видимо придется изобретать свой велосипед, пожертвовать местом, уникальностью, делать дополнительные группировки при использовании. Наверное по другому не получится. А жаль. :-(

Видишь, сколько всего нужно делать... А ты хотел, чтобы Оракл это всё быстро делал.

Кстати, промониторь таки выполняемые запросы. Даже если всё-равно откажешся, то полезно для общего образования.
23 мар 06, 16:36    [2482548]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить