oracle - Materialized view refresh terrible performance degradation -


i have materialized view (it uses joins, with, partition by; query returns 42 mln rows) 2 simple indexes on it. full refresh used.

the first refresh works fine (it takes ~100 minutes) second refresh works several days , failed complete.

also dropped indexes , re-run test. works fine. here results (time , redo entries session statistics):

1) without indexes, first run time: 72 min redo: 42 mln (it close row number)

2) without indexes, second run time: 106 min redo: 84 mln (42 mln delete , 42 mln insert new)

3) 2 indexes, first run time: 99 min redo: 126 mln (42 mln rows , 42 mln each index)

4) 2 indexes, second run time: failed after 48 hours redo: 453 mln when failed (i have no idea why it's huge)

oracle version: 11g enterprise edition release 11.2.0.3.0

the issue reproduced on different instances&servers. have no server works correctly. think kind of bug can't find similar

one thing note, between versions 10 , 11 oracle changed default value of optional "atomic_refresh" parameter dbms_mview.refresh() api false true.

if atomic_refresh = true full refresh done via delete/insert. if atomic_refresh=false then, if possible, oracle refresh via truncate/insert parallel dml. faster, following caveat: if, however, refreshing more 1 mview @ time need think because atomic_refresh=trues ensures refreshes happen in single transaction, false not - may problematic.

edit: bad, change in behaviour happened between oracle 9 , 10. not 10 , 11. there side effect truncate/insert means mview contains no data on rebuild may problematic users querying it. research, figure out business needs are, , go there. drop indexes, refresh, , recreate indexes speed things up.


Comments

Popular posts from this blog

javascript - jQuery: Add class depending on URL in the best way -

caching - How to check if a url path exists in the service worker cache -

Redirect to a HTTPS version using .htaccess -