When you build the model office, it becomes the model of the test and production satellites that you later deploy for a specific group. Although the model office does not have to be installed on the same hardware that you intend to use with the other satellites of the group, the model office should match its group satellites on several characteristics:
When you install DB2 Satellite Edition on the model office, you should install the same components that you intend to install on the other satellites of the group. This shared characteristic is important when you use the model office as the model for deploying production satellites. See The Production-Deployment Phase for more information.
The model office should have a DB2 instance with the same database manager configuration values, and a DB2 database with the same name and database configuration values that you intend to use on your production satellites. The model office should also have the same connection information (node, database and DCS directory information) as the other satellites. The connection information should include:
The replication setup on the model office should include the replication subscription information for data that is replicated with corporate databases. Typically, the subscriptions define the tables on the satellite as replicas, meaning that the replication process is the update-anywhere process.
You should test the replication definitions. That is, you should test both the initial data that is loaded onto the model office from the corporate databases, and the actual replication process. You can perform the test by updating the corporate and satellite databases (if you are using replica tables). If the test is successful, the two databases will be synchronized when the Capture and Apply programs execute. To test the model office, you may have to set up a subscription for a test sales person who is assigned fictitious customer accounts in the corporate databases. You can use the update batch to initiate the replication process on the model office.
You build the model office to represent the initial version of an end-user application during the development and acceptance-testing phase. As described in Development and Acceptance-Testing Phase, the model office should match the group satellites on several characteristics:
The model office should be at this state before you begin the production-deployment phase. The sections that follow describe how to set up the model office so that you can use it as the model for the production-deployment phase.
Perform the following steps to install and set up the model office.
When you install the model office, you can provide values for:
You can also set the application version when you install DB2 Satellite Edition. It may, however, be better to set the application version when installing the end-user application.
When you install DB2 Satellite Edition, you can use the options that are available to create a database, enable it as a replication source, and make it recoverable. You can use these options if the installation application that you use to install the end-user application does not create a database.
You can perform the installation either interactively, or by using a response file. See Chapter 15, Installing DB2 Satellite Edition and Chapter 16, DB2 Satellite Edition Distributed Installation for more information about the different methods of installing DB2 Satellite Edition.
| Note: | If you are using update-anywhere replication, the target tables on the satellite are created by the SQL script that creates replication subscriptions. |
If you have not installed and set up the DB2 control server to support synchronization, follow the steps in Setting up the DB2 Control Server.
The last steps in Setting up the DB2 Control Server instruct you to create a group and test satellites. The group that you create should be the group you intend to use for your production deployment. When you use the Create Satellite window to add the model office to the group, provide a name for the model office that conforms to the conventions that you intend to use for your model offices. You can use the Description field, and possibly the Subgroup field, to provide additional identification about the model office. When you complete your acceptance testing, you will use this model office to support the production-deployment and post-deployment phases for the application version in the group. You should set up the model office as a test satellite.
When you have set up the DB2 control server, you are ready to perform a synchronization test from the model office.
See Running a Test Synchronization for information about running a synchronization test. If problems occur, see Synchronization Test Problems for information about how to recover from them.
You must create the application version and its associated group batches before the model office can execute these batches. See Creating and Testing Group Batches for more information. The batches that you create will be at the test level so that you can modify them to obtain the results that you want.
If you intend to use data replication with this group, enable the model office to replicate data against a test subset of the data that will be replicated from the corporate data source. To perform this task, and you have not yet set up replication for the application version and generalized its subscriptions, follow the instructions in Chapter 7, DB2 Data Replication to complete these tasks. Generalizing the replication subscriptions add batch steps to the setup and update batches to enable replication on the satellites in the group. When you have completed testing the replication setup by synchronizing one or more test satellites, your should perform a final test of the replication setup by using the model office. See Testing Group Batches on the Model Office for more information.
When the group batches are created, you can synchronize the model office. You can use the db2sync command, or the application that you use for synchronization. When the model office synchronizes, it downloads and executes its group batches for its application version, then uploads the results of the execution to the DB2 control server.
Check the results. You should answer the following questions:
If the update batch contains batch steps for data replication, and this is the first time that the model office has replicated, data is extracted from the source tables and loaded into the target tables. On subsequent replications, only changes to data on either the model office or the corporate data source is exchanged.
You should verify that the correct data is loaded on the model office. You can perform this task by running queries against the data tables, and by running the end-user application. If the data that is downloaded from the corporate data source is not correct, verify that the replication source and subscription definitions are appropriate. Modify the replication definitions as required. To reload the data, cold start the Capture program on the model office. The cold start forces the data from the corporate data source to be reloaded the next time that the model office synchronizes.
You must completely test the database definition and data that are created on the model office by the group batches. See Checking the Results of the Synchronization Session for more information. You to may have to modify the group batches more than once before they produce the correct results.
When you complete the development and acceptance-testing phase, the setup of the model office should match what you intend to deploy on your production satellites. The next task is to use the setup on the model office as the model for performing a mass deployment during the production-deployment stage, as described in The Production-Deployment Phase.
[ Top of Page ]