For example, if you have three materialized views that use the materialized view log and one of
them has not been refreshed for a very long time, you would use a num value of 1.
The following listing shows an example of the PURGE_LOG procedure. In this example,
the EMPLOYEES table??™s materialized view log will be purged of the entries required by the least
recently used materialized view:
execute DBMS_MVIEW.PURGE_LOG
(master => 'EMPLOYEES',
num => 1,
flag => 'DELETE');
To further support maintenance efforts, Oracle provides two materialized view??“specific
options for the truncate command; if you want to truncate the master table without losing its
materialized view log entries, you can use the truncate command with options like the following:
truncate table EMPLOYEES preserve materialized view log;
If the EMPLOYEES table??™s materialized views are based on primary key values (the default
behavior), the materialized view log values will still be valid following an export/import of the
EMPLOYEES table. However, if the EMPLOYEES table??™s materialized views are based on ROWID
values, the materialized view log would be invalid following an export/import of the base table
(since different ROWIDs will most likely be assigned during the import). In that case, you should
truncate the materialized view log when you truncate the base table, as in this example:
truncate table EMPLOYEES purge materialized view log;
What Kind of Refreshes Can Be Performed?
To see what kind of refresh and rewrite capabilities are possible for your materialized views, you
can query the MV_CAPABILITIES_TABLE table.
Pages:
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922