| |
 |
|
Oracle Tips by Burleson Consulting
|
Tuning with Oracle
Replication
Oracle replication was first introduced as a method to allow Oracle
tables to reside on widely separated servers. Replication was a
godsend for companies that needed to have synchronized databases
across the globe. Of course, it is still far faster to process a
table on a local host than it is to process a remote table across
the Net8 distributed communication lines.
Several factors influence the decision about replicating Oracle
tables. The foremost considerations are the size of the replicated
table and the volatility of the tables, as shown in Figure 5-4.
Large, highly active tables with many updates, deletes, and inserts
will require a lot of system resources to replicate and keep
synchronized with the master table. Smaller, less active tables
would be ideal candidates for replication, since the creation and
maintenance of the replicated table would not consume a high amount
of system resources.
Oracle’s advanced replication facility is relatively mature, and
Oracle now supports multimaster replication whereby many sites can
accept new rows and propagate them to the other snapshots.
From a performance perspective, we need to be concerned about how
often the snapshots are refreshed. We can refresh the replicated
table in full, we can re-create the snapshot at will, we can choose
periodic refreshes of the snapshot, and we can use database triggers
to propagate changes from a master table to the snapshot table.
Although the choice of technique depends upon the individual
application, some general rules apply.
 |
For more details and scripts, see my new book "
Oracle
Tuning: The Definitive Reference", over 900 pages
of BC's favorite tuning tips & scripts.
You can buy it direct from the publisher for 30%-off and get
instant access to the code depot. |
|
