powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Materialized view fast refresh - странное поведение в 12c
6 сообщений из 6, страница 1 из 1
Materialized view fast refresh - странное поведение в 12c
    #39677106
upsarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет,

Столкнулся со странным поведением - при fast refresh на materialized view база за кулисами проверяет все m.view logs, даже те, которые не участвуют в refresh. Даже те, на которых нет никакого m.view.

Есть две таблицы:
1) table1 - на ней построена m.view mv_table1 с прицелом на fast refresh
2) table2 - для неё просто создаём m.view log

Изначально fast refresh для table1 работает быстро.
Но если в другой сессии запустить изменение большого объема данных в table2 в одной транзакции, то это влияет на fast refresh table1 - основное время уходит на сканирование m.view log для table2
Код: sql
1.
select 1 from "SCOTT"."MLOG$_TABLE2" where rownum=1



версия базыOracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
PL/SQL Release 12.1.0.2.0 - Production
"CORE 12.1.0.2.0 Production"
TNS for Linux: Version 12.1.0.2.0 - Production
NLSRTL Version 12.1.0.2.0 - Production


1. Сессия 1. Создаем таблицы, m.view logs, m.view
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
drop materialized view mv_table1;
drop table table1 purge;
drop table table2 purge;

create table table1(
  a integer primary key,
  b date,
  c varchar2(16)
);

create table table2(
  a integer primary key,
  b date,
  c varchar2(16)
);

create materialized view log on table1
with rowid, sequence, commit scn ( b, c ) including new values;

create materialized view log on table2
with rowid, sequence, commit scn ( b, c ) including new values;

create materialized view mv_table1 (b, c, cnt)
refresh fast on demand
as 
select b, c, count(*) cnt
from   table1 
group by b, c;



2. Сессия 1. Проверяем скорость fast refresh mv_table1 :
Код: plsql
1.
2.
3.
4.
5.
6.
SQL> set timing on
SQL> exec dbms_mview.refresh('MV_TABLE1','F');
 
PL/SQL procedure successfully completed
 
Executed in 0,25 seconds



3. Сессия 2. Загружаем большой объем новых записей в table2 , 3 млн, не комитим
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
insert into table2(a,b,c)
with get_data(a,b,c,i) as (
  select 1 a,trunc(sysdate) b,to_char(sysdate,'yyyy-mm-dd')||'-'||1 c, 2 i from dual
  union all
  select i, trunc(sysdate)+mod(i,10000),to_char(sysdate+mod(i,10000),'yyyy-mm-dd')||'-'||mod(i,10000), i + 1
  from   get_data
  where  i<= 3000000
)
select a,b,c
from   get_data;



4. Сессия 1. Проверяем скорость работы fast refresh для mv_table1
Код: plsql
1.
2.
3.
4.
5.
6.
SQL> set timing on
SQL> exec dbms_mview.refresh('MV_TABLE1','F');
 
PL/SQL procedure successfully completed
 
Executed in 5,367 seconds



В v$session видно, что основное время уходит на запрос по m.view log для table2
Код: sql
1.
select 1 from "SCOTT"."MLOG$_TABLE2" where rownum=1



Попробовал поискать баги (коих не мало для m.views), ничего толкового не нашел. Разве что пропатчил вот это (не помогло):
Bug 22568177 - FAST MATERIALIZED VIEW REFRESH SLOWER IN 12C THAN 11.2.0.3 (Doc ID 22568177.8)

Вопрос.
Кто-нибудь сталкивался с подобным ? Чем лечится ? Какие костыли можно попробовать ?
...
Рейтинг: 0 / 0
Materialized view fast refresh - странное поведение в 12c
    #39677176
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
upsarinВ v$session видно, что основное время уходит на запрос по m.view log для table2
Код: sql
1.
select 1 from "SCOTT"."MLOG$_TABLE2" where rownum=1


А как это видно?

Я бы таки больше грешил на чтение UNDOupsarin3. Сессия 2. Загружаем большой объем новых записей в table2 , 3 млн, не комитим

В общем-то, запустив трассировку 10046, можно будет не гадать
...
Рейтинг: 0 / 0
Materialized view fast refresh - странное поведение в 12c
    #39677196
upsarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вячеслав Любомудров,

Для надежности снял trace для
Код: plsql
1.
SQL> exec dbms_mview.refresh('MV_TABLE1','F');


В нём чтение по ВСЕМ m.view logs, которые есть в БД, включая другие схемы.

Вопрос в том, почему бд читает не относящиеся к текущему обновлению m.view logs и как это можно обойти.

Чтение MLOG$_TABLE2 из трассировки:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
SQL ID: 89s2c53j480vz Plan Hash: 1479141652

select 1
from
 "SCOTT"."MLOG$_TABLE2" where rownum=1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          4          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      5.88       5.89          0    3058867          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      5.88       5.89          0    3058871          0           0

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  COUNT STOPKEY (cr=3058867 pr=0 pw=0 time=5891187 us)
         0          0          0   TABLE ACCESS FULL MLOG$_TABLE2 (cr=3058867 pr=0 pw=0 time=5891181 us cost=7990 size=0 card=1)
...
Рейтинг: 0 / 0
Materialized view fast refresh - странное поведение в 12c
    #39677236
fuck_this_shit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
upsarin,

Если дампануть callstack на этом sql_id, то там заслуживает внимания:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
----- Call Stack Trace -----
calling              call     entry
location             type     point
-------------------- -------- --------------------
...
kkzlgxcmtscn()+2451  CALL???  kprball()

kkzlpurxcmt()+131    CALL???  kkzlgxcmtscn()

kkzl_purge_logs()+8  CALL???  kkzlpurxcmt()
66
kkzflbwu()+1879      CALL???  kkzl_purge_logs()+9
                              4
...



Что намекает на commit scn based mat view logs.
upsarinDo you have ideas for workaround ?
Использовать timestamp based mat view logs.
...
Рейтинг: 0 / 0
Materialized view fast refresh - странное поведение в 12c
    #39677266
upsarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fuck_this_shitupsarinDo you have ideas for workaround ?
Использовать timestamp based mat view logs.
Да, timestamp based работает по-другому, читает только нужный mat.view log, спасибо за наводку.
Как считаете, описанное поведение с commit scn баг ?
...
Рейтинг: 0 / 0
Materialized view fast refresh - странное поведение в 12c
    #39677270
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
upsarinповедение с commit scn баг ?
Вероятно, что-то из разряда "на коленке" прикрученного housekeeping.
...
Рейтинг: 0 / 0
6 сообщений из 6, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Materialized view fast refresh - странное поведение в 12c
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]