You can combine configurations to suit your business needs. The following sections describe these typical configurations, including some variations of each:
Data distribution and data consolidation are easier to set up and maintain than the other configurations.
In data distribution configurations, a primary data source resides on a source server (see Figure 1). Changes made to the data source are replicated to one or more target tables that reside anywhere in a distributed network. The target tables are read-only; therefore, you don't need to set up conflict detection because no update conflicts occur during replication. Applications can use the target tables, which are local copies, so that they don't overload the network or central server. This configuration is useful if you need to share data among several sites but you don't want to reduce the performance of your applications.
|
In data consolidation configurations, a central data server is used as a repository for data from many data sources (see Figure 2). Therefore, this configuration consists of many source tables or views and one target table with multiple subset views. Changes made to each data source are replicated to the central data server, which is read-only.
Restriction: If you consolidate data from more than one server into a CCD target table, you must not use that CCD target table as a replication source for other target tables. The original servers use separate log sequences that cannot be distinguished in further replication.
Data consolidation configurations are useful for maintaining a local decision support system (DSS) so that you can analyze data without competing for production database resources. To ensure that there are no update conflicts, you must design the replication environment so that there is only one source for each data item. If each source updates a unique set of rows, you will never encounter update conflicts.
 |
In update-anywhere configurations, a replication source has target tables that are read/write copies. Changes made to a target table are applied to the source table, which maintains the most up-to-date data. The changes to the source table are then applied to all of its target tables. Because updates can originate from either the source or target table, an update conflict might occur when the data is replicated. If you want to use this type of replication configuration, you must decide how to handle conflicts in your environment. Your options range from ignoring conflicts and rejecting any conflicting updates, to designing your application so that a conflict can never occur. By rejecting conflicting updates, you risk losing some information. If possible, try to design your system to prevent all possible conflicts (see Figure 3). Figure 4 shows a configuration that requires conflict detection.
Figure 3. Update-anywhere replication without the risk of conflicts
 |
Figure 4. Update-anywhere replication with risk of conflicts
 |
In occasionally connected configurations, you have the flexibility to connect to and transfer data to and from a primary source on demand. These types of configurations allow users to connect to the primary data source only long enough to synchronize their local database, and they don't require a continuous connection for replication administration (see Figure 5). DB2 Universal Database Satellite Edition and DB2 DataPropagator for Microsoft Jet support centralized administration of occasionally connected systems, but the Mobile client for DB2 replication does not.
Occasionally connected configurations are well-suited for synchronizing data on laptop computers or at computers in home offices because these configurations minimize the frequency and duration of communication-line connections, and reduce telecommunication costs. This type of configuration also works well for replicating data to onsite computers that are not constantly connected to the network (for example, if employees are in the office only 3 days a week).
Figure 5. Occasionally connected configuration
 |