The second problem with the replicated data solution is that the copy of the table may not be
able to pass updates back to the master table. That is, if a read-only materialized view is used to
make a local copy of a remote table, the snapshot cannot be updated. If you are using materialized
views, you can use updatable materialized views to send changes back to the master site, or you
can use writable materialized views to support local ownership of data.
Any updates that must be processed against replicas must also be performed against the
master tables. If the table is frequently updated, then replicating the data will not improve your
performance unless you are using Oracle??™s multimaster replication options. When there is
multisite ownership of data, users can make changes in any database designated as an owner
of the data. The management of Oracle??™s multimaster replication is very involved and requires
creating a database environment (with database links and so on) specifically designed to support
multidirectional replication of data. See the Oracle replication documentation for details on
implementing a multimaster environment.
The performance of the refreshes generally won??™t concern your users. What may concern them
is the validity and timeliness of the data. If the remote tables are frequently modified and are of
considerable size, you are almost forced to use simple materialized views with materialized view
logs to keep the data current.
Pages:
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936