If you encounter an error while deploying replication artifacts.
You have to undo the actions performed within the deployment of a single business measures model to undo the changes.
All deployments are done in several stages, the following are the typical
scenario:
- DDL deployment
- Deploy state.ddl.
- Deploy runtime.ddl.
- Deploy datamart.ddl.
- Data movement services deployment
- Deploy State_to_Runtime_setup_source.
- Deploy State_to_Runtime_setup_target.
- Deploy Runtime_to_historical_setup_source.
- Deploy Runtime_to_Historical_setup_target.
You must identify at what point the failure has occurred to determine
how to take action. For example, if the state.ddl fails, then it is simply
a matter of rolling back the transaction to get back to the original state.
However, if the datamart.dll fails, then rolling back the datamart.ddl will
only get the system back to the point after the runtime.ddl executed successfully.
Failures in the middle of the data movement services deployment are the most
difficult to recover from, however it is not impossible. First deployments
are the easiest to recover from, deployments of new models are next, and finally
deployments of change models represents the hardest recovery paths.
To recover from the replication scripts deployment errors, you go through
the following stages: identifying, backing up, restoring or removing, and
redeploying:
Identifying- Identify the errors that occurred and determine whether IBM® Support should
be called.
- Identify the business measures model being
deployed when the error occurred.
- Identify the Schema Generator tables being created or altered when the
error occurred.
- Identify the Schema Generator artifacts being created or altered when
the error occurred.
- Identify the last valid version of the business measures model in the Repository database.
- Identify, if a change management deployment, the location of the artifacts
which were deployed for previous versions of the model. This will give the
database structures, there descriptions and relationships to each other. This
may be important in case data needs to be backed up and later restored.
- Identify the location of the current artifacts and deployment log files.
These will be important for problem determination and potentially to provide
to IBM Support.
- Identify, if a change management deployment, whether there is data that
exists in any of the CCD tables that has not been processed yet. You can use
the WBIRMADM.RMMETADATA table (available on the Runtime and Historical
databases) to determine the associated CCD tables (TGT_RM_APP_STG_TAB_NAME)
with the business measures model project name
(OM_NAME) that was being deployed. Any rows that are marked with an I or
a U may not have been processed and should be backed up. The column SERVICE_NAME contains
the location of the CCD table and the target table, the name after the word to indicates
this. You should keep track of the relationship to the TGT_TAB_NAME in
case you decide to completely Remove all the artifacts and generate a completely
new set. This is because Schema Generator may not generate the same names
for the CCD tables and you will need to restore this data into the new CCD
tables after deployment is successful.
Restoring or removing - Determine if it is easier to restore the previous database or to remove
artifacts manually.
- Restoring Restoring from a backed up version may be a good choice
when no other business measures models exist,
or when other business measures models have
had no activity. Restore the previous database set, and for each database,
rebind any applications that need to be rebound, and reregister all the Java-based
stored procedures and user-defined functions.
Note: - For more information about database backup and restore, refer to the Data
Recovery section in the DB2® documentation.
- For completed deployed models, the WBIRMADM.RMMETADATA table provides
information on what not to remove. However, while deployments, in order to
determine some of the artifacts and relationships, it may be necessary to
examine the deployment logs to determine what can be removed safely.
- Removing
- Replication: Historical database and Runtime database
- Stop all Capture servers associated with that business measures model.
(The Capture servers run on the Runtime and State databases.)
- Stop all Apply Servers associated with the business measures model.
- Remove all ETL stored procedures for the business measures model.
- Remove all ETL staging tables that are used for the business measures model.
- Remove all ETL control information from the WBIRMADM.RMCONTROL table in
the corresponding target database for that business measures model.
- Remove all ETL pruning stored procedures and triggers that are used for
the business measures model.
- Remove all tables listed in the WBIRMADM.RMMETADATA table column TGT_RM_APP_STG_TAB_NAME that
have the suffix _BKUP and _M and also have a corresponding SERVICE_NAME of Runtime_to_Historical for
Historical and State_to_Runtime for Runtime for that business measures model.
Leave the table listed in TGT_RM_APP_STG_TAB_NAME as this will be removed
in a later step.
- Using the DB2 Replication
Center, Remove all Apply subscription set members serving that business measures model.
- If the Apply subscription set is empty, remove the subscription set.
- If the Apply server has no subscription sets, remove the Apply server.
- Remove all metadata entries associated with the business measures model from
the WBIRMADM.RMMETADATA table. You will also need to remove the same entries
from the WBIRMADM.RMMETADATA table in the Runtime database if processing
the Historical database and for the State database if processing the Runtime
database. You must only remove the rows for the business measures model and
that are in the Runtime_to_Historical service name when processing
the Historical database and the State_to_Runtime for the Runtime database.
- Replication: Runtime database and State database
- Stop all Capture servers serving the business measures model.
- Remove all the triggers associated with the Capture CD tables that are
associated with the business measures model.
- Remove pruning control information from the WBIRMADM.RMPRUNECTRL table
for pruning triggers that are used for the business measures model.
- Using the DB2 Replication
Center, Remove all of the subscriptions for all of the tables associated with
the business measures model.
- Remove all metadata entries associated with the business measures model from
the WBIRMADM.RMMETADATA table.
- Database schema: Generally, an error during schema generation is rolled
back before the altered model is deployed. The current set of replication
artifacts is not affected.
Redeploying
When you have removed all the artifacts supporting a business measures model,
you can run the Schema Generator again with the Ignore Older Deployments option
selected. If the generated schema succeeds, do not deploy the Database Definition
Language (DDL) scripts; deploy the replication scripts again.