IBM Tivoli Storage Manager, Version 7.1

Testing the upgrade process for a server

Test the upgrade to ensure a smooth upgrade process. The larger and more complex your environment, the more important testing the upgrade is. Testing can help to plan for the amount of time that the server is unavailable because of the upgrade.

About this task

The original server and the V7.1 server cannot both be installed on a system at the same time. To evaluate the V7.1 server, you can install the program on a new system.

To test with a copy of production data, or to test the upgrade process, you can use the upgrade utilities to create a test server. Follow the normal upgrade procedure, but consider these tips:

Minimizing impact to your production server
To avoid affecting your original production server, you must install the V7.1 server on a different system. Different versions of the server cannot be run on a system at the same time.

The DSMUPGRD utility must be installed on the system that has your original server, or a copy of your original server. The utility package installs by default in a different location than a normal server, so it can be installed without affecting your production server.

Important: When you run the DSMUPGRD PREPAREDB utility, the utility upgrades the database version to a V5.5 fix pack level. If you do not want the database on your production server to be upgraded to the V5.5 fix pack level, back up the database and use the backup on another system to test the upgrade.

You can extract the production database for the test by using either media or the network. The advantage of extracting the database to media is that you can repeatedly load the test database without stopping your production server each time.

Detecting problems in the database
A PREVIEW parameter is available for the DSMSERV INSERTDB utility. When you use the PREVIEW=YES parameter, the operation includes all the steps of the process, except for the actual insertion of data into the new database.

When you preview the insertion operation, you can quickly verify that the source database is readable. You can also identify any data constraint violations before you run the actual upgrade process for your server. Investigate any data constraint violations that are discovered during the preview so that you can avoid delays when you run the actual upgrade process.

Protecting storage and stored data
Ensure that the storage devices for your production server are not available to the test server. If the test server can detect the devices that your production server uses, it might start operations such as issuing resets on tape drives or unloading tapes.

For example, if your tape drives are connected in a storage area network (SAN), you might need to change the zones in your SAN to prevent the test server from detecting the devices.

For testing, you can use one of the following methods to use a backup copy of the database. The methods are given in outline form. See the detailed procedures for instructions for each step.

Parent topic: Planning the upgrade of the server
Related tasks:
General procedures for upgrading a server to V7.1

Testing by extracting data from a separate copy of the server

Either the media method or the network method can be used to move the database.

Procedure

  1. Prepare a test system. This system is a different system than the production server, where you must install a separate copy of the V5.3, V5.4, or V5.5 server (the same version as your production server).
  2. Back up the database of the production server.
  3. Restore the database backup on the test system. Start the server to verify that the restore operation worked.
    Tip: If you are upgrading the server by using media, ensure that the device class is valid on the test system. For example, if you are using a FILE device class for the extraction step, ensure that the path for the device class is valid on the test system. The path that is in the server database for the device class must be correct. If necessary, start the server and update the path.

    If you are using a tape device class for the extraction step, ensure that the device names for the library and drives are correct.

  4. From this point, you can use the detailed procedures in one of the following sections to complete your test:

Testing by extracting data from the production server

This example process uses the media method to move the database to the test system.

About this task

You follow the steps in the procedures for Scenario 3: New system, media method, with just a few changes.

With this process, the production server is unavailable for at least the amount of time that is required to prepare and extract the database. The time is approximately as much as the time required for a full backup of the database.

Procedure

  1. Prepare for the test by backing up the database of the production server. Consider making a second copy of the database backup. For details, see Scenario 3: Preparing for the upgrade.
  2. Install the DSMUPGRD utilities on the same system as the production server. For details, see Installing the upgrade utilities on the original server.
  3. Prepare the database and extract the data from the database of the production server to media by using either the upgrade wizard or commands. For details, see:
  4. After the data is extracted from the production server, resume normal operations by restoring the database backup that you made in step 1 to the production server. You can then restart the production server.
  5. From this point, continue your test by using the detailed procedures for Scenario 3, using the test system as the new system.

Feedback