Replication Guide and Reference

Planning your replication requirements

An important step in coming up with the appropriate replication environment is determining the characteristics of your application data, who needs to access the data, and how frequently they need to access it.

You can use DB2 data replication to maintain data in more than one location and keep the various copies of it synchronized. You must determine where your source data will be coming from, whether you want all or some of the source information copied, whether you want only changes copied, and how many copies (or targets) you need. You also need to determine where the copies will be located.

Although you cannot update the source tables and target tables synchronously, you can schedule the updates to meet the needs of your applications and your replication environment. The frequency of replication depends on how much lag time is acceptable between the time that the source is updated and the time that the targets are updated. Therefore, you must decide how synchronized the copies must be with the source and with each other before you can come up with a replication model.

After you understand your application data requirements, you can design the replication model that will help you meet those requirements. There are many facts that you need to consider when you design your model. These are some of the more important decisions that you need to make:

The replication configuration

Based on your data needs, you must decide whether you need a consolidation, distribution, update-anywhere, or occasionally connected configuration. You have the flexibility to design your environment so that it uses one of these configurations or some combination of them.

Where to locate the control tables

You will get slightly better performance if you place the control tables on the same server as the Apply program instead of placing them centrally. You can have your Apply programs share a single control server so that your control information is stored centrally. A central control server is popular because it simplifies the administration of large networks, but it has two drawbacks: the Apply program must access the control information over the network and, if the control server goes down, all of the Apply processes are affected.

The type of target tables to use

The type of target table that you use depends on your replication requirements. Each type is best suited for specific situations. For example, a replica is the only type of target table that you can use for update-anywhere replication; and a row-replica is the only type of target table you can use with DataPropagator for Microsoft Jet.

Whether to use existing target tables

You can let the administration interface create the target table for you or you can use an existing table as a target. If the existing tables are DB2 tables, the data types are supported by the DB2 data replication components. If your replication environment includes non-IBM databases, some of the data types might not map directly to the source tables that you are using.

Which columns to make available for replication

You can choose to capture only the after-image column values or both the before-image column values and the after-image column values. If you will be using the targets for auditing purposes, or if you have replica target tables, you must copy both the after-image and before-image column values.

How to capture SQL operations

You might want to capture all updates as two rows in the CD table: a DELETE of the before-image column values followed by an INSERT of the after-image column values. This includes updates of columns that will be the primary key of the target, columns that will be the partitioning key of the target, or columns that are part of the WHERE clause or predicate of the subscription set. You might need to adjust the size of the CD table to accommodate this increased overhead.

The level of constraints

If you have a read-only table, you do not need to set constraints at the target. You must use referential constraints to enforce referential integrity only if you have target tables that are replica tables. The referential integrity of other types of target tables is ensured if you define your subscription sets appropriately.

Which joins to use

Joins are described in views, which in turn are defined in replication sources. For example, you might use a view to change the name of copied columns, to reference columns from related tables in the WHERE clause in your subscription predicate, to incrementally maintain copies that are inner joins of two or more tables, or to replicate information from one table when an update is made to another table.

When you are ready to plan your replication environment, see Planning for replication for detailed planning information.

[ DB2 List of Books | Search the DB2 Books ]