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
Post a Comment