If you wish to access monitor data from a previous release when upgrading Resource Analyzer, you must migrate the previous Resource Management repository contents into the new release repository.
The migration procedure is executed in batch to migrate the repository used by Resource Analyzer from prior releases to Release 7.7 or higher.
The following conditions are required in order to migrate the Resource Management Repository.
Note: When you run the migration more than once (which is necessary if you continued monitoring in the old release after migration and want the newly monitored data to be migrated), you will get a duplicate record error message. The duplicates are ignored and the new records are added.
How to: |
For these platforms, the migration procedure is executed in a Web Console session.
Note: IBMÂ i was formerly known as i5/OS.
To start the migration job:
Note: You can also perform this task by clicking the Workspace link in the toolbar, right-clicking Workspace in the navigation pane, and selecting Migrate, General.
Note: This is only required is the old release is version 7703.
The Resource Management Migration pane opens, as shown in the following image.
The Submit Data Migration Job pane opens.
The Deferred List pane opens, displaying the list of deferred requests and to view the request name that was displayed when the deferred migration job was scheduled. Examples of request names are listed in the Deferred ID column, as seen in the following image.
The Status column shows the state of the deferred request, which can be Queued, In-progress, or Ready. To see if the status has changed to Ready, either keep refreshing the page using the refresh options located at the top of the page, or redisplay the page at a later time. Once the status is Ready, right-click the request line and select Get to review the job output.
How to: |
The migration information described below is only applicable if the server environment has been upgraded by performing the refresh option during the installation process. To refresh the server, follow the instructions in the Installation Guide for your platform.
Note: The migration process must be applied to the original server that was refreshed. If a clone server was setup and the Resource Management repository was copied to this server for the purpose of testing , the migration process will not work. There are inter-dependencies in the RA repository data based on the machine name and port number used when first configured.
The migration of a Central Relational Repository Model, as described in Configuring a Central Relational Repository Model, is not supported on a refreshed server environment. A new server environment needs to be installed and then you must follow the migration steps that are outlined in Migrating the Resource Management Repository .
Once the refresh process has completed successfully, start the server and then the Web console.
The migration is performed from the Web Console and consists of three phases:
For these platforms, the migration procedure is executed on a Web Console session.
Note: IBM i was formerly known as i5/OS.
This warning message indicates that the structure of the Resource Management repository has changed. A migration process is required in order to update the existing repository so that new data columns can be archived to the repository. If the migration process is not run, monitor data will still be collected and archived but without the new data columns.
You can:
The Resource Management Configuration Migration pane opens.
Select this option if you do not have DBA authority over the existing Resource Management repository tables. This option creates a file, rmldb.sql, which contains RDBMS specific DDL.
Click Next to display the instructions for the location of the rmldb.sql file. Give this file to the DBA for processing. You must close the browser at this point in the process. You cannot start phase 2 using the same browser session or errors will occur while attempting to access your old database.
Note: Your DBA must create the new Repository tables in the same location as the original 7.7 tables and both sets of tables have to be accessible on the same Adapter connection on the server. The new tables will have the release number appended to the name. The format will be tablename_release.
Once the repository tables have been created, return to the Web Console and click Resource Management. The warning message opens again. Close the window and right-click on the warning link in the Statistics table and then click on the Migrate Configuration entry to continue the Configuration Migration process.
Select this option if you have DBA authority over the existing Resource Management repository tables. New repository tables will be created with the _7703 suffix, and the process will continue at Phase 2.
Note: If migrating a FOCUS repository, there will be no Phase 1 drop-down menu.
Select this option if you do not want data to be copied from the old repository to the new one.
To run the migration process at a later date, right-click Resource Management in the navigation pane and select Configuration, Migrate 7700-7702 data.
Select this option to copy data from the old repository to the new one.
The Deferred Execution pane opens, as shown in the following image.
Note: Once you choose to remove the old configuration files, the option to migrate data will no longer be available.
How to: |
This option is only available when migrating data from release 76. MVS migration is not available for releases 53 and 71.
To start the migration job:
On MVS, the migration page uses data set names to locate the Resource Management files to be migrated instead of an ECADONF path value.
The following options are available:
The release number you are migrating from. The only previous release supported for MVS migration is 76x.
The server name used by Resource Management in the old release. You can find the server name in the GKESET FOCEXEC.
The dataset name that was used to save the MASTER files during configuration of the previous release.
The dataset name that was used to save the ACCESS files during the configuration of the previous release.
Select Yes if the previous releases system data should be migrated. If Yes is selected, SMCNTRL, SMPRMTRS and SMPRL data will be migrated. Only custom BRL members will be migrated. The SMKNBNAME value in SMCNTRL will not be migrated and any Govern and/or Advise values will be set to OFF. Any compiled rule files must be rebuilt after the migration is completed and new Govern and/or Advise values must be set. The default value is No.
Note: If multiple migration runs are being made, only migrate the system data once.
Select Yes if you want to have 7.6 style masters created that will allow existing custom reports to run. Some modifications to your custom reports may be required.
The earliest date of the data to be migrated. The format is MM/DD/YYYY. The default value is 1/1/1995.
The latest date of the data to be migrated. The format is MM/DD/YYYY. The default value is the current date.
WebFOCUS |