Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Материализованные вью  [new]
asdljkfa
Guest
Подскажите пожалуйста.
1) Можно ли использовать в мат вью вложенные запросы?
2)Какие могут быть проблемы если я строю мат вью на большой таблице на основании той ее части котороя неизменна (например таблица договоров вью по старым договорам) но при этом в эту же таблицу идет интенсивная вставка и изменения (по новым договорам которые не попадают во вью) (пусть договора разделяются по дате во вью выьираются прошлогодние).
15 дек 09, 10:38    [8067354]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
asdljkfa
1) Можно ли использовать в мат вью вложенные запросы?

Если память не изменяет, можно, но при этом нельзя будет добиться fast refresh.
asdljkfa
2)Какие могут быть проблемы если я строю мат вью на большой таблице на основании той ее части котороя неизменна (например таблица договоров вью по старым договорам) но при этом в эту же таблицу идет интенсивная вставка и изменения (по новым договорам которые не попадают во вью) (пусть договора разделяются по дате во вью выьираются прошлогодние).

Partition-change tracking поможет.

На тему fast refreshable mviews рекомендую почитать Rob Van Wijk.
15 дек 09, 13:19    [8068687]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
lkdfsl;gk
Guest
на 9i вложеные подзапросы не получилось пишет что нельзя
И еще вопрос что значит обновление по требованию это когда и что для этого нужно сделать что бы обновить такое вью или это значит что его прото нужно вручную пересоздавать.
Подскажите пожалуйста?
15 дек 09, 14:25    [8069211]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
lkdfsl;gk
по требованию это когда == вручную пересоздавать
15 дек 09, 14:30    [8069260]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Alexey181
Member

Откуда: default city
Сообщений: 907
lkdfsl;gk
на 9i вложеные подзапросы не получилось пишет что нельзя
И еще вопрос что значит обновление по требованию это когда и что для этого нужно сделать что бы обновить такое вью или это значит что его прото нужно вручную пересоздавать.
Подскажите пожалуйста?

конструкция REFRESH ON COMMIT заставляет сервер Oracle обеспечивать синхронизацию между
представлением и исходными данными — при изменении исходных данных изменяется
и представление
конструкция REFRESH ON DEMAND.
Это означает, что для учета изменений в исходных данных это представление надо обновлять вручную:
dbms_mview
15 дек 09, 14:36    [8069320]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
fdnjh
Guest
orawish
lkdfsl;gk
по требованию это когда == вручную пересоздавать


Это не так. Если указать start with ... next ..., то мат. представление будет обновляться по расписанию. Например:

create materialized view my_mat_view
build immediate
refresh force
start with trunc(sysdate) next trunc(sysdate) + 1 as
select 1 from dual;

Данное мат. представление будет обновляться автоматически каждые сутки. Использование dbms_mview в данном случае не требуется.
17 дек 09, 12:31    [8079830]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Материализованные вью  [new]
Ildjarn
Member

Откуда: Mordor
Сообщений: 50
Hello !

Есть проблема при обновлении вьюх. Сами вьюхи fast refreshable , и с помощью dbms_mview обновляются как бы. Но в процедуре REFRESH есть параметр parallelism, отвечающий за распараллеливание. Так вот, при задании этого параметра, скажем, равным 10 вьюхи так же продолжают обновляться в один поток. Железо системы позволяет распараллеливать операции, настройки инстанции тоже. Во всяком случае параллельные запросы с хинтом работают как надо.
В чём может быть трабла с обновлением вьюх ?
11 апр 13, 15:09    [14167570]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Изя Кацман
Member

Откуда: Великий Эксперимент
Сообщений: 2019
Ildjarn
В чём может быть трабла с обновлением вьюх ?

Как ты определяешь, что у тебя эта трабла есть? (Конкретно, не типа)
11 апр 13, 16:40    [14168346]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Ildjarn
Member

Откуда: Mordor
Сообщений: 50
Изя Кацман
Ildjarn
В чём может быть трабла с обновлением вьюх ?

Как ты определяешь, что у тебя эта трабла есть? (Конкретно, не типа)


Ну, сначала тупо несколько раз замерил и сравнил время от начала до конца рефреша на малоактивной БД.
Также мониторил сессии в Toad, где не наблюдал активных параллельных сессий. Сделал трейс процесса, но не нашёл там в планах никаких параллельных SQL операций касательно обновления...
11 апр 13, 17:40    [14168773]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Изя Кацман
Member

Откуда: Великий Эксперимент
Сообщений: 2019
Ildjarn
Изя Кацман
пропущено...

Как ты определяешь, что у тебя эта трабла есть? (Конкретно, не типа)


Ну, сначала тупо несколько раз замерил и сравнил время от начала до конца рефреша на малоактивной БД.
Также мониторил сессии в Toad, где не наблюдал активных параллельных сессий. Сделал трейс процесса, но не нашёл там в планах никаких параллельных SQL операций касательно обновления...

==
Секретарша: Босс! Я пересчитала этот отчет 20 раз...
Босс: Какая же вы трудолюбивая!
Секретарша: Да, но я получила 20 разных результатов!
==


Замерил тупо, как секретарша из етого анекдота? :)
Как и чем мерил?
Чем отличался твой первый раз от других разов?
Замерь не тупо

Какой SELECT делал твой ТОАД, чтобы смотреть параллельные сессии?
Какие именно планы ты смотрел? Покажи.
11 апр 13, 18:29    [14169052]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Ildjarn
Member

Откуда: Mordor
Сообщений: 50
Изя Кацман,

Какая разница как я мерил? Обычный elapsed time, который в трейсах.
Планы в момент работы рефреша наблюдал в просмотрщике сессий в Toad и в Enterprise Manager.
Запросы к v$session и v$process не запускал, уже привык пользоваться тулзами.
Сама мат. вьюха без агрегатов, просто join :

CREATE MATERIALIZED VIEW PACK_LINKTOINTCLAS_MV (PROWID,LIROWID,NID,PID)
TABLESPACE  TBS
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
WITH PRIMARY KEY
ENABLE QUERY REWRITE
AS 
SELECT  pack.rowid, li.rowid, 
       col1, col2, col3....  coln
  FROM pack, linkpacktointclassifier li
 WHERE pack.packid = li.packid;


Пишу :
BEGIN   
          DBMS_MVIEW.REFRESH ('PACK_LINKTOINTCLAS_MV', 'f', parallelism  => 10);
END;


Так вот, Oracle сначала удаляет записи из мат. вьюхи, а потом вставляет. Но всё это происходит серийно.
Сами SQL, которые генерирует Oracle при рефреше, очень мудрёные, с обилием непонятных колонок, подсказок. Что толку их тут приводить?
Вот план вставки записей во вьюху из трейс-файла:
Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  LOAD TABLE CONVENTIONAL  (cr=132115 pr=102291 pw=0 time=34972734 us)
      4773       4773       4773   NESTED LOOPS  (cr=132045 pr=102291 pw=0 time=34958253 us)
      4773       4773       4773    NESTED LOOPS  (cr=127272 pr=102291 pw=0 time=34942778 us cost=963336 size=29902076 card=421156)
      4773       4773       4773     VIEW  (cr=122076 pr=102291 pw=0 time=34919377 us cost=121024 size=16003928 card=421156)
      4773       4773       4773      HASH JOIN RIGHT SEMI (cr=122076 pr=102291 pw=0 time=34917842 us cost=121024 size=9686588 card=421156)
      5437       5437       5437       VIEW  VW_NSO_1 (cr=17355 pr=0 pw=0 time=75295 us cost=17341 size=12 card=1)
      5437       5437       5437        FILTER  (cr=17355 pr=0 pw=0 time=72776 us)
      5437       5437       5437         HASH JOIN  (cr=17355 pr=0 pw=0 time=71452 us cost=17341 size=168 card=1)
      3329       3329       3329          TABLE ACCESS FULL SNAP_XCMT$ (cr=2020 pr=0 pw=0 time=9109 us cost=2015 size=26 card=1)
      5437       5437       5437          TABLE ACCESS FULL MLOG$_LINKPACKTOINTCLASSIF (cr=15335 pr=0 pw=0 time=55130 us cost=15325 size=142 card=1)
  42508610   42508610   42508610       TABLE ACCESS FULL LINKPACKTOINTCLASSIFIER (cr=104721 pr=102291 pw=0 time=14986537 us cost=103683 size=463271699 card=42115609)
      4773       4773       4773     INDEX UNIQUE SCAN PACK_PK (cr=5196 pr=0 pw=0 time=20305 us cost=1 size=0 card=1)(object id 97326)
      4773       4773       4773    TABLE ACCESS BY INDEX ROWID PACK (cr=4773 pr=0 pw=0 time=12265 us cost=2 size=33 card=1)
11 апр 13, 23:12    [14170103]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
DВА
Member

Откуда:
Сообщений: 5439
автор
-- PARALLELISM
-- Max degree of parallelism for pushing deferred RPCs. This value
-- is considered only if PUSH_DEFERRED_RPC is true.
-- 0 = (old algorithm) serial propagation
-- 1 = (new algorithm) parallel propagation with only 1 slave
-- n = (new algorithm) parallel propagation with n slaves
12 апр 13, 07:11    [14170656]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Ildjarn
Member

Откуда: Mordor
Сообщений: 50
DВА, спасибо, учту.

Откуда дровишки? Что-то в официальной документации такого я не находил.
12 апр 13, 09:06    [14170814]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Ildjarn,

комментарии в спецификации пакета почитай
12 апр 13, 09:33    [14170925]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
Ildjarn
Member

Откуда: Mordor
Сообщений: 50
xtender,

Фигово. Трудно что ли в доке было черкнуть эту лишнюю строчку. Только вводят народ в заблуждение.
12 апр 13, 10:24    [14171202]     Ответить | Цитировать Сообщить модератору
 Re: Материализованные вью  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Ildjarn,

вообще тема старая: https://www.sql.ru/forum/actualthread.aspx?tid=678306
12 апр 13, 10:27    [14171218]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить