|
|
|
Materialized view fast refresh - странное поведение в 12c
|
|||
|---|---|---|---|
|
#18+
Всем привет, Столкнулся со странным поведением - при 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. версия базы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. 2. Сессия 1. Проверяем скорость fast refresh mv_table1 : Код: plsql 1. 2. 3. 4. 5. 6. 3. Сессия 2. Загружаем большой объем новых записей в table2 , 3 млн, не комитим Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 4. Сессия 1. Проверяем скорость работы fast refresh для mv_table1 Код: plsql 1. 2. 3. 4. 5. 6. В v$session видно, что основное время уходит на запрос по m.view log для table2 Код: sql 1. Попробовал поискать баги (коих не мало для m.views), ничего толкового не нашел. Разве что пропатчил вот это (не помогло): Bug 22568177 - FAST MATERIALIZED VIEW REFRESH SLOWER IN 12C THAN 11.2.0.3 (Doc ID 22568177.8) Вопрос. Кто-нибудь сталкивался с подобным ? Чем лечится ? Какие костыли можно попробовать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 21:05 |
|
||
|
Materialized view fast refresh - странное поведение в 12c
|
|||
|---|---|---|---|
|
#18+
upsarinВ v$session видно, что основное время уходит на запрос по m.view log для table2 Код: sql 1. А как это видно? Я бы таки больше грешил на чтение UNDOupsarin3. Сессия 2. Загружаем большой объем новых записей в table2 , 3 млн, не комитим В общем-то, запустив трассировку 10046, можно будет не гадать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2018, 01:56 |
|
||
|
Materialized view fast refresh - странное поведение в 12c
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудров, Для надежности снял trace для Код: plsql 1. В нём чтение по ВСЕМ 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2018, 08:54 |
|
||
|
Materialized view fast refresh - странное поведение в 12c
|
|||
|---|---|---|---|
|
#18+
upsarin, Если дампануть callstack на этом sql_id, то там заслуживает внимания: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Что намекает на commit scn based mat view logs. upsarinDo you have ideas for workaround ? Использовать timestamp based mat view logs. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2018, 14:03 |
|
||
|
Materialized view fast refresh - странное поведение в 12c
|
|||
|---|---|---|---|
|
#18+
fuck_this_shitupsarinDo you have ideas for workaround ? Использовать timestamp based mat view logs. Да, timestamp based работает по-другому, читает только нужный mat.view log, спасибо за наводку. Как считаете, описанное поведение с commit scn баг ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2018, 18:59 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39677176&tid=1883703]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
776ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 1102ms |

| 0 / 0 |
