Assume that an application that generates reports needs information that exists in the DEPARTMENT table of the SAMPLE database. Instead of using the data directly from the source table, you want to copy the changes to a target table that can be read only by the report-generating application. For ease of administration, you want to keep the target table on the same machine as the source server.
You require a simple data distribution configuration, with changes from one replication source being replicated to a single read-only copy. This section describes the design and planning issues that you need to consider before you perform any replication tasks.
You already know that the replication source is the userID.DEPARTMENT table in the SAMPLE database. Before you set up your environment, you must decide what you want to replicate from that table. You decide to make all columns available for replication; and you want to save before-image values for each of them.
| Tip: | You might want to always include before-image values when you define a replication source. Therefore, if you later change to an update-anywhere configuration, you won't have to redefine your replication source. |
You decide that you want your replication target to be the COPYDB database, which you created using DB2 for Windows NT earlier in this chapter. Currently there is no target table in that database; you want the Control Center to create the target table according to your specifications.
Using existing target tables: When you use the Control Center, the target table is created if it doesn't exist. That is the preferred method of generating a target table because it ensures correct mapping to the replication source. You can use existing target tables if they were created by any DB2 product.
Assume that you want the target table in COPYDB to contain the following columns of information:
Because the columns in the target table simply reflect the data from the source table, and there is to be only one record in the target table for each record in the source table, you can use a user copy type of target table.
For the purpose of this exercise, you decide to store the target table
and the replication control tables in the default table space,
USERSPACE1.
| Logical server | Table space | Contents |
| Source server: userid.SAMPLE | USERSPACE1 | Source replication control tables, including the CD table |
| Control server: userid.COPYDB | USERSPACE1 | Replication control tables and the target table |
Typically you will want to put the UOW table and the CD tables (and CCD tables if you are using them) in their own table spaces, with table or table space locking. You can put all other replication control tables together in one table space with row-level locking.
For scheduling replication, assume that you want DB2 replication to check for any changes from the source table every minute and replicate them to the target table. Although a report-generating application doesn't require that kind of turnaround, you want to test the replication environment that you set up to make sure that everything is working correctly.
Also, after each replication cycle, you want to delete any records from the Apply audit trail table that are older than one week (seven days). This pruning will prevent the table from growing too large.
You won't need to set constraints because you have a read-only target. Constraints are needed only when applications are updating a target table. In this scenario, the updates are committed at the replication source, and they must satisfy the constraints defined on that system. There is no reason for you to re-evaluate the same constraints at the target.