You set up replication for the satellite environment much like you set up replication for any other environment. Perform the following tasks to set up replication for the satellite environment:
You set up a separate replication environment, which is independent of the satellite environment. You set up the replication control tables, replication source or sources, and the replication subscriptions in a test environment. After testing the replication definitions, you may want to promote these definitions to a production environment. For more information, see Creating the Replication Environment.
Setting up the satellite environment entails setting up the DB2 control server, creating a group, satellites for the group, an application version, group batches, scripts, targets, success code sets, and authentications. See Chapter 5, Setting up and Testing Your Satellite Environment for the details on how to set up the satellite environment. To enable the group satellites to replicate data, you must perform one additional task, which is to generalize the replication subscriptions from the replication environment to the satellite environment. When you generalize the replication subscription, the generalize function creates batch steps which, when executed by the satellite, will define the replication subscription for that satellite for its application version. Enabling the Satellite Environment for Replication describes how to set up the satellite environment for replication.
When you create the replication environment, you set up the replication control server, and define the replication sources and subscription sets in a replication test environment. When the replication test environment is fully tested and performs to your satisfaction, you can promote this test environment to a production environment.
Create the replication control tables, define the replication sources, subscription sets and replication subscriptions using the Control Center or the DB2 DataJoiner Replication Administration (DJRA) tool.
You can install the DJRA tool on the same machine as the Control Center by going to the \sqllib\djra directory on the Control Center instance. Run the djra executable in this directory to start the DJRA installation program. Refer to the online help provided with the DJRA installation program for more information.
For information about creating the replication definitions, and about starting the DJRA tool, refer to the Replication Guide and Reference. For information about how to use the DJRA tool, refer to the online help that is provided with it. Consider the following when you decide on where to locate the replication databases:
You can use the DJRA promote functions to reverse engineer the setup of the test replication environment to move it to production databases. You must perform this step to move the replication source or sources from a test database to the production database from which the production satellites will access data.
| Note: | You can only use the DJRA tools to promote between the same type of database. That is, if you use DB2 Universal Database databases in the test replication environment, you must use DB2 Universal Database databases in the production replication environment. |
The steps that follow provide an overview of how to promote the test replication environment to production. For detailed information, refer to the online help that is available from the DJRA tool.
The target database must be a DB2 Universal Database database. Only consider using a production database on the same system as the DB2 control server if the DB2 control server serves a small number of satellites. Otherwise, use a different system. You will generalize the replication subscriptions for the satellite environment from this database.
The replication control server can be any non-satellite database. You would typically use the target production server.
Notes:
After you create the replication environment, you must set up the satellite environment, and generalize the subscription sets for it. As a basic requirement, you must have already created a group, and an application version for it. For information on creating a group, see Creating a Group. For information on creating an application version, see Creating an Application Version.
In addition, you must ensure that you have cataloged the production replication control server, and all production replication sources and targets at the DB2 control server instance. If the Control Center's JDBC server and the DB2 control server are on the same instance, see Cataloging Instances and Databases in the Control Center Instance for the procedure. If this condition is not true, you must still catalog the same objects at the Control Center, then use the Client Configuration Assistant to export the production replication control server database, and the production replication source and target databases, and import the resulting file at the DB2 control server instance using the db2cfimp command. The procedure to follow is similar to that described in Using a Client Profile to Perform Cataloging on the Model Office, except that you only select the replication-related databases on the Customize Export window.
| Note: | Typically, you will not create the replication control tables on a satellite. Instead, you will use a DB2 server that is not a satellite as the replication control server. One situation exists, however, in which you may want to consider using the satellite as the replication control server. This situation occurs when you have a very small group of satellites functioning as target servers, and one source server. Placing the replication control tables on the satellite can result in better performance by the Apply program. If you decide to use the satellite as the replication control server, however, you do not have the centralized reporting of replication information that occurs if you use a central replication control server. In addition, if a replication-related error occurs on any of the satellites of this group, you will have to perform maintenance on that satellite manually. |
You can now create a generalized replication subscription to be used in the satellite environment.
You generalize replication subscriptions to create the replication setup for the satellite environment. When you generalize, you reverse engineer the subscription definitions for the single production replication target that you defined, which creates parameterized scripts that will be used to define all of the satellites as replication targets.
The DB2 control server stores these scripts in the satellite control database, and adds test batch steps to the setup and update group batches for the application version that you specify. The scripts of these test batch steps set up the tables that are required for replication on the satellites, and specify, by use of a WHERE clause, the rows that each satellite will replicate. In addition, the DB2 control server also adds a batch step to the update batch to invoke the Capture and Apply programs through the asnsat command.
To generalize replication subscriptions, use the Generalize Replication Subscriptions window. For more information about this window, refer to the online help that is available from the Satellite Administration Center. In this window, you must specify the replication control server that contains the production subscription information for the subscription that you want to generalize, as well as the application version that corresponds to the end-user application that will be using the replicated data.
When you generalize the subscription, the replication definitions, by default, apply to all the satellites of the group. If you want, you can modify the definitions for the entire group, or you can modify the definitions for a subset of the group satellites. For more information, see Changing Replication Parameters.
If you generalize the replication subscription before creating level 0 for an application version, the DB2 control server automatically creates level 0. The DB2 control server also creates a setup batch called setup and an update batch called update for level 0. The batches are created with the test batch steps that are required for data replication.
In some situations, you may need to edit the setup batch. For example:
Notes:
If the subscription that you generalize is for a replica table, the control tables that are required for the Capture program must exist on the satellite before replication can occur. You can create these tables by executing the dpcntl.sat SQL script file on the satellite. The script contains a series of CREATE TABLE statements that must be executed on the satellite.
During installation, this command file is automatically executed if you create a database and specify that the database will be used as a replication source. If this is not the situation, you must execute the command file to create the control tables.
You can find the dpcntl.sat script in the sqllib\samples\repl directory on the satellite.
You can also invoke the dpcntl.sat script from a batch step in the setup batch. Ensure that you specify that the execution target is the operating system on the satellite. The batch step that executes the dpcntl.sat script must immediately precede the batch steps that configure replication. The dpcntl.sat script also sets the default values in the tuning parameters table. To invoke the script from a batch step, use the following script for the batch step:
db2 connect to server-name USER authorization-name USING password -tvf x:\sqllib\samples\repl\dpcntl.sat db2 connect reset
Where x is the drive on which you installed DB2 Satellite Edition.
In some situations, you may need to customize the generalized replication subscription. For example, you may want to modify the WHERE clause for one or more group satellites to have them replicate different data than other satellites in the same group. You may also want to change the replication control server for one or more of the group satellites to more evenly distribute the work load on the replication control servers.
To work with the generalized replication subscription, use the Change Replication Parameters notebook. From this notebook, you can specify the satellites for which you want to change the replication parameters. You can also use this notebook to select the WHERE clause for a specific source-target table pair, then modify the clause using the Change Subscription Definition window. You can also use the Change Replication Parameters notebook to change the replication control server for one or more group satellites. For more information about working with replication parameters, refer to the online help that is available from the Satellite Administration Center.
[ Top of Page ]