Group batches are associated with an application version, and you use these batches to set up and maintain the database definition and data on the satellites that are running a particular version of an end-user application. For information about the different types of batches that are associated with an application version, see Types of Group Batches.
Even though the satellites in the group may execute the batch steps at different times, each satellite of the group will execute the same set of batch steps, and will execute them in the same order. This ensures the consistency of the satellites that belong to the group. It also simplifies the management of large numbers of satellites. You know that the satellites are similar because they have all executed the same set of steps in the same order. If the satellites started out similar before executing the batches of an application version, they will remain similar after they have all executed the batches. For more information, see Application Versions.
Three types of group batches can be executed by satellites when they synchronize: setup, update, and cleanup. You will typically use the setup batch to set up the database definition for the satellite, the update batch to maintain the data on the satellite, and the cleanup batch to perform cleanup activities on the satellite. Using group batches allows you to maintain consistency among the satellites of a group without having to maintain each satellite separately. Only one of each type of group batch can be associated with an application version.
When the satellite synchronizes for the first time, it executes, in order, the batch steps of the setup batch to configure itself, the batch steps of the update batch to populate its tables, and the batch steps of the cleanup batch to perform any cleanup activities. After a satellite synchronizes for the first time, it will execute any new batch steps that are appended to the setup batch to modify its database definition (if required). The satellite then executes all the batch steps of the update batch to maintain its data. Finally, the satellite will execute any batch steps that are appended to the cleanup batch.
Details about the different types of group batches are as follows:
The steps in an update batch are considered to be idempotent, in the sense that they can be repeatedly executed without changing the current state or database definition of the satellite to a different state with each invocation of the step. For example, a table can be replicated multiple times without resulting in a change in the replication configuration. In contrast, the batch step in the setup batch that originally created the table would be executed only once.
A typical cleanup batch is one that contains a batch step that updates the database statistics.
Depending on your requirements, you may not need to create all three types of group batches. For example, you may decide to use a different mechanism to set up the database definition than the setup batch. If a specific type of batch does not exist when a satellite synchronizes, that batch type is bypassed.
You can create group batches from the Edit Application Version window. You can also create unassigned batches from the Create Batch window, then assign them as group batches when you edit the application version. For more information about these windows, refer to the online help for the Satellite Administration Center.
At some point in time, you will need to deploy a new version of the end-user application. Typically, a new version of an end-user application will require a different database definition than the previous version. Consequently, the batches and the associated scripts used to maintain the new database definition will be different.
If you have a large number of satellites in a group, you will probably want to stage the deployment of a new version of the end-user application within that group. That is, you will want to keep most satellites of the group at one version of the end-user application, and use a subset of the group satellites to determine whether the new version of the application meets your business requirements. To stage the deployment, however, you may have to support more than one set of batches for a group of satellites. You will have one set of batches for each version of the end-user application that is used by the group. That is, you will have one set for the original version, and one set for the new version to be deployed. The satellite administration environment supports this requirement through the implementation of application versions.
Each collection of setup, update, and cleanup batches that maintains the database definition and data for the end-user application is associated with an application version. For every version of the end-user application that is used in a group, you require a different application version, and its associated batches. Every group, therefore, must have at least one application version.
When you create an application version on the DB2 control server, you supply a unique identifier for the application version. After the application version is created, you edit it to associate a setup, update and cleanup batch with it.
A satellite will run a particular application to fulfill a specific business requirement. The version of the application on the satellite is identified by the application version that is set on the satellite. You usually set the application version on the satellite using DB2 interfaces during the installation of the end-user application. When you set the value on the satellite for the end-user application, use the same identifier that you used on the DB2 control server. For more information about setting the application version on the satellite, see Setting the Application Version.
When a satellite synchronizes, it uploads its application version to the DB2 control server. The DB2 control server uses this information, in conjunction with the group that the satellite belongs to, to determine which of the group batches the satellite will execute. The DB2 control server only allows the satellite to download and execute the group batches that correspond to the satellite's application version.
You create an application version on the DB2 control server using the Create Application Version window of the Satellite Administration Center, and the Edit Application Version window to maintain it. For more information about these windows, refer to the online help for the Satellite Administration Center. You can set the application version on the satellite system using a DB2 API or command; you can also set it during the installation of DB2 Satellite Edition on a satellite. For more information about setting the application version on the satellite, see Setting the Application Version.
Assume that you have a large group of users who will all sell life insurance using the first version of the end-user application. Because the group is large, it may not be practical to perform the deployment at one time. Because of this, you stage the deployment.
To stage the deployment, you enable satellites that have a shared characteristic, such as a common subgroup, to begin executing the group batches. As you deploy more and more satellites, scaling the environment larger and larger, you may find that the database definition and data that seemed appropriate for your application in the earlier stages of the deployment is no longer adequate. For example, you may be receiving reports that performance of the end-user application is becoming worse for many users. It may be that the amount of data that is maintained by each satellite is larger than you originally anticipated. This situation may not necessarily result in satellites returning errors and requiring fix batches, but you need to make some changes to the database definition. In this situation, adding indexes to one or more tables will improve the performance of the end-user application. Rather than creating a new application version, which is appropriate only if you are going to change the version of the application that the end users run, you would create a new level of the existing application version. You then modify this new level of the application version to change the database definition.
A new level of an application version is a copy of the setup, update and cleanup batches of the previous level of the application version. You can add one or more additional batch steps that you design to modify the database definition or data. Each level of an application version is associated with a particular number. For example, the first level is level 0, the second level is level 1, and so on. In addition, a level can be a test level for execution by test satellites, a production level for execution for production satellites, or an obsolete level that is not executed by any satellite. For more information, see States of an Application-Version Level
In the new copy of the setup and cleanup batches, you can only append new batch steps. You cannot modify the contents or the order of any existing batch steps. The next time the satellites synchronize, they will only execute the new batch steps of these two batches. All the satellites will execute the new batch steps in the same order, ensuring that the satellites remain consistent after they all execute the new batch steps. If you have new satellites that have never synchronized, they will execute all the batch steps, including the new ones. Because all the satellites in a group that have the same application version run the same setup and cleanup batch steps in the same order, they will have a similar database definition and data after they execute all the batch steps.
The new level of the update batch, however, can be modified in any way that you require. Unlike the situation that applies to setup and cleanup batches, a satellite executes all the batch steps of the update batch each time that it synchronizes. By definition, the update batch is idempotent. That is, a satellite can execute the update batch repeatedly without changing its current state or database definition.
The way that an application interfaces with its data does not change within a version of an application. Once you have set up the underlying database definition to support the end-user application, it is unlikely that you will want to substantially modify it. Rather, you will want extend the database definition in small ways to address intermittent problems such as performance. For this reason, the setup and cleanup batches can only be appended to. Although the database definition sets the structure of the data, with a fixed number of tables and columns, the data content is subject to continual updates. One of the primary uses of the update batch is to replicate data between the satellite and one or more replication sources. You can change the replication operation in any way to ensure that satellites have the data that they require. For this reason, the update batch in a new level is fully modifiable.
In the situation described above, in which the performance of the application is impacted because of an increase in the amount of data managed by each satellite, you would add a new batch step to the setup batch to create indexes. All satellites in the group that have the same application version will execute the new batch step to create the index when they next synchronize. Differences exist, however, in the number of setup batch steps that the satellite will execute when it next synchronizes, depending on when the satellite was rolled out:
The levels of an application version allow you to maintain and manage the changes to the database definition and data within an application version. Because the Satellite Administration Center maintains a history of the different levels of the application version, you can track the changes that have occurred over the life time of the application version.
Levels simplify the administration of groups because they allow you to test database definition changes on test satellites, without affecting your production satellites. Levels also allow you to maintain the hundreds (or thousands) of production satellites that belong to a group. Each level in a application version has one of the following states: test, production, or obsolete. When you create the first level for an application version, that level, and the batches associated with it, are in the test state. These test batches set up and maintain the database definition and data for the test satellites. You can modify these test batches until you are satisfied with the results that they produce on the test satellites. Then, you promote the test level to production.
When you promote the level to production, the batches associated with this level can be executed by the production satellites. You will probably not want to enable all the satellites of the group to begin executing the production batches at the same time. Instead, consider rolling out subsets of the group satellites to execute the production batches. You can deploy subsets of the satellites according to a characteristic that the subset shares, such as a subgroup. When you enable these satellites, they will download and execute the production batches the first time that they synchronize. Over time, you will enable all the group satellites to execute the production batches.
When the production satellites are executing the batches of the production level, you may find it necessary to modify the database definition or data generated by the production batches to address a problem. For example, assume that your users are calling in, saying that performance of the end-user application is becoming worse over time. You determine that adding indexes to a table will improve the performance of the application. To fix the problem, you create a new test level from the existing production level. You then append a batch step to the setup batch to create the indexes. Because the new level is in the test state, only the test satellites will be able to execute the new batch step of the test setup batch. When you are satisfied with the results that the test batch generates on the test satellites (that is, the performance of the application is again satisfactory), you promote the test level to the production level. The next time that they synchronize, the production satellites will download the new batch step and create the indexes.
The levels, and the associated states, represent the life cycle of the application version and its associated batches. Additional details about states are as follows:
By default, the first level of an application version is created in the test state. This level is level 0. When level 0 is created, all the batches and batch steps that you add to it are in the test state. When level 0 is in the test state, you can modify all of its batches and batch steps. This includes the reordering or deletion of batch steps, and the deletion of the batches.
If a new test level was created from a production level, the setup and cleanup batches can contain a mixture of production and appended test batch steps:
When you are satisfied with the results of a test level, you can promote it to production, so that the batches within it can be executed by production satellites. For more information, see Promoting a Test Level to a Production Level.
To ensure consistency among the satellites that execute them, production batches cannot be modified or deleted, nor can the batch steps within them. When a test level is promoted to production, all the batches associated with it are set to the production state.
You cannot directly create a production level of an application version. A production level is always a test level that was promoted to production. In this way, you can always use your test satellites to test and tune changes to batches. This helps to isolate testing from the production environment. You must always explicitly promote a test level to production before the production satellites can execute the new or changed batches.
You can only have one production level of an application version. If you have an existing production level and promote a test level to production, the existing production level becomes obsolete. The existing production level is obsoleted because the database definition or the data that it sets up and maintains is no longer adequate to support the end-user application.
If you find that one or more batches of a production level no longer meet all of your requirements, you can create a new test level from it. For more information, see Creating a Test Level from a Production Level.
There can be many obsolete levels. If you want to be able to track the changes to an application version, you should keep them.
The levels of an application version support a test/production/obsolete development model, which can be used in conjunction with the procedure that you use to implement your end-user application. For more information, see Application Version Life Cycle.
The following table is an overview of an application version, the available
batch types, and the states at which a level can be:
| Application Version | |||
|---|---|---|---|
| Batches | Levels | ||
|
At most, one of the following types of batches can be associated with any level of an application version:
| Test State | Production State | Obsolete State |
| The batches of a test level can only be executed by test
satellites.
When a level is created, the level and the batches that it contains are always in the test state. The batch steps, however, may be a mixture of test and production batch steps. This enables you to validate the changes to the batches before making them available to the production satellites. An application version can contain only one test level. | The batches of the production level can only be executed by production
satellites.
The batches and batch steps of a production level cannot be modified in any way. This guarantees consistency among your production satellites. An application version can contain only one production level. | The batches of an obsolete level cannot be executed by any
satellite. This occurs because obsolete batches are no longer adequate
to support the end-user application.
You can have multiple obsolete levels of an application version. If you keep the obsolete levels, you can use them to track the changes that have occurred to the database configuration and data that support the end-user application. | |
Like levels, the application version also has a state. You can use the application version details view to determine the state of an application version. This view is available from the Satellite Administration Center. The state is displayed in the State column. The state of the application version is set as follows:
| Note: | The application version can also be in the Production Normal state if no production satellites are executing the batches associated with this application version. |
The discussion that follows describes the test/production/obsolete development model, and how this model applies to the levels of an application version through the life cycle of the application version.
When you create the first level of a new application version, that new
level is identified as level 0 and is created in the test state. In the
example that follows, there are two batches: configure, which
sets up the database definition, including data replication; and
replicate, which maintains the data used by the end-user
application:
| Application Version | ||||
|---|---|---|---|---|
| Level | State | Setup Batch | Update Batch | Cleanup Batch |
| 0 | Test | configure | replicate |
|
You use your test satellites to fully test the batches associated with this
level of the application version. When you are satisfied with the
results on your test satellites, you promote this level to production.
(If you are not satisfied with the results, you can continue modifying the
batches until they produce the results that you want. You can also
delete level 0, create level 0 again, and create new batches for level
0). When level 0 is promoted, your production satellites can execute
the batches of this level. Level 0, which was at the test state, then
moves to the production state, as follows:
| Application Version | ||||
|---|---|---|---|---|
| Level | State | Setup Batch | Update Batch | Cleanup Batch |
| 0 | Production | configure | replicate |
|
Assume that you are in full production, and identify a performance
problem. To address this problem, you decide to add an index to one of
the replicated tables. You want to test this database definition change
on your test satellites before making it available to your production
satellites. To do this, start by creating a test level of your existing
production level. This new level is in the test state and is a copy of
your existing production level. Then, edit level 1 and append a new
batch step to the configure batch to create the index:
| Application Version | ||||
|---|---|---|---|---|
| Level | State | Setup Batch | Update Batch | Cleanup Batch |
| 0 | Production | configure | replicate |
|
| 1 | Test | configure (with batch step added to create index) | replicate |
|
Again, you use your test satellites to fully test the changes associated
with the new test level, level 1. Because all members of your test
satellites already executed all the batch steps associated with level 0 when
it was in the test state, the test satellites will only execute the new batch
step in the configure batch to create the index when they next
synchronize. (They will also execute the entire replicate
batch.) When you are satisfied with the results of the index creation,
promote level 1 to production. Then your production satellites can
execute the batches of this level. Level 0 is no longer adequate to
support the end-user application. Because only database definition can
be in use in the production environment, level 0 is obsoleted:
| Application Version | ||||
|---|---|---|---|---|
| Level | State | Setup Batch | Update Batch | Cleanup Batch |
| 0 | Obsolete | configure | replicate |
|
| 1 | Production | configure (with batch step added to create index) | replicate |
|
When they next synchronize, the production satellites that have previously synchronized execute only the create index batch step of the configure batch. Satellites that are synchronizing for the first time execute all the batch steps of the configure batch, including the create index batch step. To maintain the end-user application data, all satellites run the replicate batch after they execute the configure batch.
Again, time passes. Although your tables are indexed, you begin to
receive reports that the performance of the end-user application is slowly
becoming worse. You decide that you need to perform data reorganization
on the tables on the satellite to reduce data fragmentation. Again, you
need to create a test level from your production level. You decide to
add a cleanup batch to contain the batch step that reorganizes the
data. In this way, the data is reorganized after it is updated by the
replicate batch:
| Application Version | ||||
|---|---|---|---|---|
| Level | State | Setup Batch | Update Batch | Cleanup Batch |
| 0 | Obsolete | configure | replicate |
|
| 1 | Production | configure (with batch step added to create index) | replicate |
|
| 2 | Test | configure (with batch step added to create index) | replicate | reorganize |
Again, you test level 2 with your test satellites. When you are
satisfied with results, you promote level 2 to production. Level 1 is
automatically obsoleted:
| Application Version | ||||
|---|---|---|---|---|
| Level | State | Setup Batch | Update Batch | Cleanup Batch |
| 0 | Obsolete | configure | replicate |
|
| 1 | Obsolete | configure (with batch step added to create index) | replicate |
|
| 2 | Production | configure (with batch step added to create index) | replicate | reorganize |
Assuming no new satellites join the group, all satellites bypass executing the configure batch, because they have already executed all of its steps. The satellites start by executing the replicate batch to maintain the data for the end-user application. When the satellites complete executing the replicate batch, they run the reorganize batch to reorganize the table data. Each satellite only executes the batch step in the reorganize batch once.
When you create a new test level, the update batch steps that were copied from the production level of the update batch are changed to the test state. In this way, you can modify the steps and their order in the batch, as required. Because the update batch is, by definition, idempotent, it should not modify the state or database definition of the satellite. For example:
In these examples, the changes are implemented by minor changes to existing batch steps in the update batch.
Continuing the example that started in Application Version Life Cycle, assume that you now want to back up one mission-critical
table on your production satellites each time that these satellites
synchronize. Assume that you want a snapshot of the data of this table
before the data is refreshed. You would create a test level from level
2, the current production level. Because you want the backup image to
contain a snapshot of the data before it is refreshed, you would add the
backup tablespace batch step before the batch steps that update the
data:
| Application Version | ||||
|---|---|---|---|---|
| Level | State | Setup Batch | Update Batch | Cleanup Batch |
| 0 | Obsolete | configure | replicate |
|
| 1 | Obsolete | configure (with batch step added to create index) | replicate |
|
| 2 | Production | configure (with batch step added to create index) | replicate | reorganize |
| 3 | Test | configure (with batch step added to create index) | replicate (backup tablespace followed by data replication) | reorganize |
When you are satisfied with the results, you would promote level 3 to production. Level 2 would be automatically rendered obsolete.
When you create a level in an application version, it is created in the test state. By definition, only test satellites can execute the batches of a test level. After you are satisfied that the batches in the test level produce the results that you want, you will want the production satellites to execute them. To do this, you must promote the level to production. To promote a test level, use the Edit Application Version notebook. For more information, refer to the help for the Satellite Administration Center.
If you already have a production level and you promote the test level, the existing production level will be moved to the obsolete state. This occurs because the previous production level is no longer adequate to support the end-user application. Because the test level is a copy of the batches and batch steps of the previous production level, no batch steps are lost from the previous production level. This means that the first time any new production satellites synchronize, they will run the same production batch steps in the same order as satellites that were rolled out earlier. The resulting database definition and data on the new satellites will resemble that of other members of the group. In this way, consistency is maintained across the group.
As described in Application Version Life Cycle, you may find it necessary to refine or extend a setup, update, or cleanup batch that is associated with a production level. To do this, you use the Edit Application Version notebook to add a test level from a production level. When you add a test level, all the batches and batch steps of the production level are copied to the test level. Existing batch steps in the setup and cleanup batches cannot be modified or reordered. Instead, you can only append test batch steps to these batches. You can modify the update batch in any way that you require.
In the case of the setup and cleanup batches, the test satellites will execute only the appended test batch steps. For the update batch, the test satellites will execute all the batch steps, regardless of whether the batch is changed. To modify the batches in a test level, use the Change Level notebook. For more information, refer to the online help for the Satellite Administration Center.
When you obsolete a production level, the batches associated with it can no longer be executed by any satellites. All the batch steps in the batches become obsolete. There are two ways in which you can obsolete a production level:
Batches are ordered sets of batch steps. Batch steps, when in group batches, can be test, production, or obsolete batch steps, depending on the state of the associated level. Each batch step contains a script, as well as other information, which the satellites use to set up and maintain the database definition and data for the end-user application that runs on the satellites.
The type of the batch step controls whether that batch step is executed by test or production satellites, and whether the batch step is modifiable. The relationships between the state of a level and the state of batch steps are as follows:
Because all the batch steps are in the test state, you can modify or reorder them until you obtain the database definition and data that you require. If required, you can also delete a batch and replace it with a different batch. This characteristic of being completely modifiable only occurs with batches and batch steps associated with level 0 when it is in the test state.
The copied production batch steps in the test level of the setup and cleanup batches cannot be modified, meaning that the changes to the database definition and data on the test satellites can only result from the new batch steps. The original batch steps are locked so that, if unexpected problems occur during the test phase, it will be much easier to identify and repair the problems that can occur. Changes cannot result from changes to the original batch steps, or from an interaction between changes in the original batch steps and the new batch steps.
You can modify the test batch steps until they provide the results that you want on your test satellites: you can even remove these steps. Because the test of the batch is isolated from the production satellites, normal production is not affected.
The batch steps that were copied from the update batch of the production level are marked as test batch steps in the new level of the update batch. You can modify these batch steps in any way that you require. For more information, see Update Batch in a Test Level.
Ordinarily, only production satellites can execute production batch steps, and only test satellites can execute test batch steps. An exception occurs if a new test satellite is introduced to the group. In this situation, the new test satellite has not yet executed any batches. When this satellite first synchronizes, it will execute all the batch steps in the batches of a test level, both production and test steps. In addition, you can configure a test satellite to execute all the batch steps of a test batch, including any production batch steps in it.
As a summary, a production level consists of group batches, the steps of which are in the production state, and are only executed by the production satellites of the group. Given sufficient time, all the satellites of the group will contact the DB2 control server to synchronize, download the batch steps that they have to execute, and execute the associated scripts. Consequently, all the group satellites begin at a consistent state, and end at a consistent state. If you find that you require modifications to the database definition or data, you can create a new level of the application version. The new level will be in test state. You can then modify the setup, update and cleanup batches, as required, to make the modifications.
As previously described, when an update batch is copied to a new level, all the batch steps in the new level of the update batch are set to the test state. The new level of the update batch contains no production batch steps. As a result, you can modify the batch steps of an update batch in any way that you require. You can change batch steps, reorder them, add new ones, and delete existing ones. When a test satellite synchronizes, it runs all the batch steps that are in the test state. By definition, the batch steps of the update batch are idempotent, and satellites always execute all the batch steps of the update batch when they synchronize.
A test satellite executes the batch steps of a setup or cleanup batch differently than how it executes the batch steps of an update batch. When you create a test level of an application version from a production level, all the batch steps in the setup and cleanup batches are copied, but they remain at the production state. You cannot modify these production batch steps in any way, nor can you reorder or delete them. You can only append new test batch steps. Because the appended batch steps are in the test state, you can modify, reorder, or delete them.
The next time the test satellites synchronize, the DB2 control server will recognize that the test satellites have not executed the new test batch steps. The test satellites will only download and execute those test batch steps that they have not previously executed. A test satellite will not download and execute any of the production batch steps, unless that test satellite has not already executed the full set of production batch steps. This situation can occur with a new test satellite.
Typically you will want to verify the changes that the test batch steps implement on a small number of test satellites before promoting the associated test level to production. If changes are required, you can modify, reorder, and add or delete the test batch steps, and test them again. Because you can test repeatedly, you can refine the test batch steps until you are satisfied with the results that they generate on the test satellites. This process occurs without any impact to the production satellites.
When you are satisfied with the results generated by the test steps, you promote the test level to production. The next time a production satellite synchronizes, it will download and execute the new batch steps in the setup and cleanup batches, and all of the batch steps in the update batch, whether they are changed or not. At this point, one cycle of the test-production cycle of batch step development has been completed.
The interrelationship between the state of a batch step (test or production), and the sequence of its execution within a group batch, is pivotal to the test-production cycle of batch step development. The following example shows a single cycle of the test-production cycle. This example illustrates the development of a setup batch step.
| Setup Batch of Production Level 0 | ||||
|---|---|---|---|---|
| Batch Step | Script | Batch Step State | Success Code Set | Execution Target |
| 1 | Replication control server setup | Production | Replication success code set | Replication control server |
| 2 | Replication source setup | Production | Replication success code set | Replication source |
| 3 | Replication target setup | Production | Replication success code set | Local satellite database |
Over time, the replicated tables on the satellites have more and more rows added to them. You begin to receive complaints that the end-user application is not performing as well as it did when it was first implemented. You realize that if one of the replicated tables had another index, the application would perform better. But, if you add another index, you should also adjust the heap size on the satellites to account for the new index.
| Setup Batch of Test Level 1 | ||||
|---|---|---|---|---|
| Batch Step | Script | Batch Step State | Success Code Set | Execution Target |
| 1 | Replication control server setup | Production | Replication success code set | Replication control server |
| 2 | Replication source setup | Production | Replication success code set | Replication source |
| 3 | Replication target setup | Production | Replication success code set | Local satellite database |
| 4 | Create index on replicated table | Test | Create index success code set | Local satellite database |
| 5 | Heap size alterations | Test | Database manager success code set | Local satellite database manager |
Two steps (4, 5) are added in sequence, immediately following the three pre-existing production batch steps. Because the new batch level is in the test state, only test satellites can download and execute the new batch steps in it. Production satellites will continue to execute the production-level setup batch, if required. During the testing of these new batch steps, you can modify the test batch steps as necessary to prepare them for production.
Because the test satellites already executed steps 1 through 3 of the setup batch when it was in the test state, they will begin executing the new test-level setup batch at step 4 (satellites only execute the steps of a setup batch once, and in the sequence that they appear in the batch). If you find that the results of the new batch steps are not satisfactory:
For more information about fixing a satellite, see Identifying and Fixing a Failed Satellite.
| Setup Batch of Production Level 1 | ||||
|---|---|---|---|---|
| Batch Step | Script | Batch Step State | Success Code Set | Execution Target |
| 1 | Replication control server setup | Production | Replication success code set | Replication control server |
| 2 | Replication source setup | Production | Replication success code set | Replication source |
| 3 | Replication target setup | Production | Replication success code set | Local satellite database |
| 4 | Create index on replicated table | Production | Create index success code set | Local satellite database |
| 5 | Heap size alterations | Production | Database manager success code sets | Local satellite database manager |
[ Top of Page ]