If, for example, the EMPLOYEES and DEPARTMENTS tables are related to each other via a
primary key/foreign key relationship, then simple materialized views of these tables may contain
violations of this relationship, including foreign keys without matching primary keys. In this example,
that could mean employees in the EMPLOYEES materialized view with DEPTNO values that do
not exist in the DEPARTMENTS materialized view.
This problem has a number of potential solutions. First, time the refreshes to occur when the
master tables are not in use. Second, perform the refreshes manually (see the following section for
information on this) immediately after locking the master tables or quiescing the database. Third,
you may join the tables in the materialized view, creating a complex materialized view that will
be based on the master tables (which will be properly related to each other). Fourth, you can force
the materialized view updates to occur when transactions are committed in the primary database.
Subprocedure Description
RESET_TASK Reset a task to its initial state.
SET_DEFAULT_SQLWKLD_PARAMETER Import data into a workload from schema evidence.
SET_DEFAULT_TASK_PARAMETER Modify a default task parameter.
SET_SQLWKLD_PARAMETER Set the value of a workload parameter.
SET_TASK_PARAMETER Set the specified task parameter value.
TUNE_MVIEW Show how to decompose a materialized view
into two or more materialized views or to restate
the materialized view in a way that is more
advantageous for fast refresh and query rewrite.
Pages:
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915