Its only parameter is the name of the refresh group.
execute DBMS_REFRESH.DESTROY(name => 'emp_group');
You may also implicitly destroy the refresh group. If you set the implicit_destroy parameter
to TRUE when you create the group with the MAKE procedure, the refresh group will be deleted
(destroyed) when its last member is removed from the group (usually via the SUBTRACT
procedure).
NOTE
For performance statistics related to materialized view refreshes, query
V$MVREFRESH.
Managing Materialized View Logs
A materialized view log is a table that maintains a record of modifications to the master table in a
materialized view. It is stored in the same database as the master table and is only used by simple
materialized views. The data in the materialized view log is used during fast refreshes. If you are
going to use fast refreshes, create the materialized view log before creating the materialized view.
To create a materialized view log, you must be able to create an AFTER ROW trigger on the
table, so you need CREATE TRIGGER and CREATE TABLE privileges. You cannot specify a name
for the materialized view log.
Because the materialized view log is a table, it has the full set of table storage clauses
available to it. The following example shows the creation of a materialized view log on a table
named EMPLOYEES:
create materialized view log on EMPLOYEES
tablespace DATA_2;
The pctfree value for the materialized view log can be set very low (even 0), since there will
not be any updates to this table! The size of the materialized view log depends on the number of
changes that will be processed during each refresh.
Pages:
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920