One of the decisions you face when you are planning the deployment of the Rational CLM solution is the selection of the database vendor you will use. Although most of the times the decision is based on your organization’s corporate solution , and this deployment decision remains stable in time; there may be circumstances in which you want to change the database vendor you use for your CLM deployment.
Rational CLM provides a series of commands, part of the Repository Tools (“repotools”) utilities, that allow you to export a CLM application database to an intermediate “tar” file format and to import that “tar” file intermediate format to a destination database. The following Info Center entry describes the details of this set of operations, which main steps are summarized in the following diagram (click to enlarge):
The “Export DB” operation in the diagram is performed by a “repotools-<jts/ccm/qm>-export toFile=<file>.tar” and the “Import DB” one is performed by running a “repotools-<jts/ccm/qm>-import fromFile=<file>.tar”. Note that there is no repootols command for the RM application as it shares the database with the JTS.
Although the InfoCenter just talks about migrating from Derby to one of the supported major database vendors solutions, the information is still valid and the operations are the same if you need to migrate between these major vendors.
But what happens with your data warehouse? This component exists with an independent database from version 3.0.1, and currently there is no support for operations that can move the data warehouse between databases; as you can see in the following technote called Migrating the RTC Data Warehouse to a different database vendor. As the technote explains, the possibility you have is to recreate the data warehouse in the new location. To do so, you can create a new database for the warehouse in the vendor software to use, and follow the instructions outlined in Configuring or changing the data warehouse after you have configured the Jazz Team Server . After this configuration, a rebuild process will run for a complete load of the data warehouse, and different tasks will run on each of your CLM applications collecting data and storing it into the data warehouse.
The recreation of the data warehouse has two drawbacks: (1) this operation is time consuming, depending on the amount of data in your applications’ databases that it will have to process; and (2) not all information can be recreated, some is lost in the way. Based on the information from the technote and some other gathered (thanks to the CLM reporting team), here are the main information loss points you have to consider:
- All information in the Star Schema will be lost: this will impact RQM reports. RTC and Rational Reporting for Development Intelligence (RRDI), out-of-the-box reports won’t be impacted. Although you will loose some information that is usually needed when building RRDI custom reports.
- All historical information for RQM and RRC will be lost.
- For RTC: work items history and build results (the ones you have not deleted), will be recreated. SCM historical data will be also recreated, but the historical information regarding stream changes won’t.
- You will loose RTC repository sizing metrics and services counter information.
- From the information that you will get recreated, it will be from the past two years, which is the older data that the ETL rebuild process can manage (i.e. you won’t get historical data for work items older than two years recreated).
This is it for how you can migrate CLM applications’ databases, and how to manage the data warehouse movement when you need to. Stay tuned to the work item Support moving data warehouse between DB vendors, and even for small deployments (the ones not to play with in your laptop), try to plan your databases layout in advance.