If you wait to have the materialized view populated, the view will not be
populated with data until the package DBMS_MVIEW.REFRESH is automatically executed, and
your users must wait for the view to populate before any data is returned, thus causing a one-time
performance degradation. If a standard view already exists and you want to convert it to a
materialized view, you can use the prebuilt keyword option.
You must decide how much stale data is tolerable in terms of your company??™s needs. You can
base your decision on how frequently the data changes in the table on which the materialized
view is based. If your management does not have to have up-to-the-minute information on which
to base decisions, you might only need to refresh your materialized view once an hour or once a
day. If it is critical for the data to be absolutely accurate at all times, you may need to perform fast
refreshes every five minutes throughout the day and night.
There are four forms of refresh when specifying a refresh method during materialized view
creation: refresh complete, refresh fast, refresh force, and never refresh. In a fast refresh,
materialized view logs are used to track the data changes that have occurred within the table
since the last refresh. Only changed information is populated back to the materialized view, on
a periodic basis, based on the refresh criteria you have established. The materialized view log
is maintained in the same database and schema as the master table for the materialized view.
Pages:
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903