Upgrading CA Spectrum

Contents
casp941
Contents
Upgrading from Earlier Versions
This release of
supports direct upgrades from the following earlier versions:
  • 9.2.2
  • 9.2.2 H09
  • 9.2.3
  • 9.2.3 H11
  • 9.2.3 H12
  • 9.3
  • 9.3 H01
The following table summarizes the upgrade paths to
9.4:
Current Version
Upgrade Path
9.1
1. Upgrade to
9.2.0 (see
CA Spectrum 9.2.0 Installation section
.)
2. Upgrade to
9.2.2 (see
CA Spectrum 9.2.2 Installation section
.)
3. Upgrade to
9.4 (see Installing CA Spectrum.)
9.2.0
1. Upgrade to
9.2.2 (see
CA Spectrum 9.2.2 Installation section
.)
2. Upgrade to
9.4 (see Installing CA Spectrum.)
9.2.2
9.2.2 H09
9.2.3
9.2.3 H11
9.2.3 H12
9.3
9.3 H01
Upgrade directly to
9.4 (see Installing CA Spectrum.)
 
Important!
During the upgrade from
9.2.2, 9.2.2 H09, 9.2.3, 9.2.3 H11, or H12, you must specify the character set encoding that your system is currently using. The installer prompts you for this information so that it can automatically convert your SpectroSERVER, DDM, and Spectrum Report Manager databases. For more information, see Upgrade Scenarios that Require a One-Time Database Conversion.
Upgrade Scenarios that Require a One-Time Database Conversion
Some upgrade and migration scenarios require extra steps to convert data in the
SpectroSERVER
, DDM, and
databases. In most cases, however, no extra steps are required. To determine whether additional conversion steps are required for your situation, verify whether a non-default character set or locale was configured in your
deployment.
First, identify the character set encoding that your system uses to store
attribute data. If you think that the encoding setting may have been modified at some point, you can verify the encoding on the Character Set Encoding page in OneClick Administration. Or check the
$SPECROOT
/custom/common/config/tomcat-server-config.xml file. By default, the OneClick server uses the character set that is defined by the system language setting. Finally, consider whether
users have ever used a non-English character set when entering data, such as model names or annotations.
Most of the character set conversion for supported encodings is performed automatically during the upgrade. However, you must be careful to select the correct encoding in the Pre-Upgrade Character Set Encoding dialog during the installation.
If neither the default character set encoding nor the default locale (US English) has been changed, select the Default Encoding when you are prompted during the installation.
For fault-tolerant deployments, if a non-default character set encoding or a non-default locale setting was used before the upgrade, or if non-English characters were entered into the database, you must also run a script after the upgrade completes.
Not all character set encodings can be converted. Only the following encodings are supported for an upgrade:
  • ISO-8859-1 (Americas, Western Europe, Australia, and others)
  • ISO-8859-2 Eastern European (Czech, Polish, Slovak, Hungarian, and others)
  • ISO-8859-7 Greek
  • ISO-8859-8 Hebrew
  • ISO-8859-9 Turkish
If you are using an unsupported encoding, perform a fresh installation instead of an upgrade.
For more information about the upgrade and migration scenarios that require database conversion, see Installing CA Spectrum and Perform One-Time Database Conversion (Fault-Tolerant Environments).
Schema Changes in MySQL Databases for CA Spectrum 9.4
UTF-8 encoding is mandatory for the internationalization of
[assign the value for rn in your book]. As a result, during some upgrade and migration scenarios,
MySQL databases (ddmdb, mibtools, eh_integ, and netqos_integ) are converted to UTF-8. This conversion takes some time and depends on the size of these databases, actual hardware, and software environment parameters, such as the RAM, processor, the operating system. For more information about the upgrade or migration scenarios that require these schema changes, see Installing CA Spectrum.
To improve the overall efficiency of the character encoding conversion of databases during the upgrade, run the db_optimize.pl script, and then the db_maintenance.pl script to clean your DDM database. For more information about database maintenance and optimization, see Refer to Required Times for Upgrade Options for detailed information about expected upgrade times in different environments.
If you have installed the
, the schema of the reporting database is changed after the upgrade once the Tomcat web server restarts. The
installer prompts you to select one of the following methods to convert the reporting database before you start the upgrade:
  • Preserve Report Manager data
    Select this option if you want to preserve the Report Manager data. In this method, the schema of the reporting database is changed. All of the existing reporting database is converted to UTF-8 and stored using InnoDB. The Report Manager database conversion time depends on the size of the existing reporting database, hardware, and software parameters.
    is unavailable until the conversion finishes. After the conversion, all new reporting data is stored using InnoDB and in the UTF-8 encoding.
  • Remove all Report Manager data
    Select this option if you want to delete all of your existing Report Manager data for a faster conversion. In this method, only the schema of the reporting database is changed. In this case, the conversion is faster as there is no existing data to be converted to the new schema.
    is unavailable until the conversion finishes. After the conversion, reporting data is stored using InnoDB and UTF-8.
  • Remove only Report Manager event data
    Select this option if you want to delete only the Report Manager event data for a time efficient conversion. In this method, apart from the schema change, all of the existing reporting database except the event data, is converted to UTF-8 and stored using the InnoDB. The event data is large. By deleting this data, you can reduce the overall size of the Report Manager data.
    is unavailable until the conversion finishes. After the conversion, all new reporting data is stored using InnoDB and UTF-8.
After you upgrade by clearing only the Report Manager event data, you may find some events that occurred before the time of upgrade. This situation occurs if the last event synchronization time from Archive Manager to Report Manager was a time before the upgrade. As a result, although the event data was cleared before the upgrade, the event synchronization after the upgrade causes the events to flow through to the reporting database starting from the last event synchronization time instead of the upgrade time.
Required Times for Upgrade Options
We performed tests on specific databases to derive approximate upgrade times for various scenarios. We performed all tests on a server with 4 GB of RAM and two CPUs (2.26 GHZ) on the Windows 2008 Server platform. If an encoding conversion is required, the process can take more time than indicated here. The following table provides example results to help you determine the preferable upgrade option for your environment.
The results are for your information only. They are environment-specific and might not apply to all databases of the same size. In addition to the one-time database character set conversion, other factors, such as system specifications, platform, the number of database entries, and the degree of database fragmentation, can also affect the timings.
SRM DB Size
Event Table Size
Event Table Rows
Time Required for Specified Option:
 
 
 
Preserve All Data
Remove Event Data
Remove All Data
75 GB
39 GB
35,683,681
5 hours (h)
36 minutes (mins)
< 1 min
115 GB
104 GB
50,198,426
7 h
48 mins
3 mins
215 GB
200 GB
64,575,242
9 h
1h 30 mins
8 mins
260 GB
153 GB
372,768,550
96 h
7h 28 mins
30 mins
Pre-Upgrade and Post-Upgrade Tasks
Before you upgrade
, complete these tasks:
  • Stop all running applications other than
    .
  • Stop the following
    applications:
    • Shut down all OneClick clients by logging off all users from OneClick in the Client Details web page in the OneClick home page.
      For more information about shutting down OneClick clients, see .
    • Stop the
      SpectroSERVER
      and the Archive Manager by clicking Stop
      SpectroSERVER
      in the
      Control Panel and then close the
      Control Panel. Or you can stop the
      SpectroSERVER
      and Archive Manager from command line by running the "<$SPECROOT>/bin/stopSS.pl" as Spectrum Owner at the command prompt.
    • Stop all VnmSh connections.
For more information about stopping VnmSh connections, see .
Close all Bash shells.
If you are upgrading from
9.2.2, 9.2.2 H09, 9.2.3, 9.2.3 H11, or H12, character set encoding and
database conversion occurs. For more information, see Upgrade Scenarios that Require a One-Time Database Conversion.
Schema changes in some MySQL databases occur during the upgrade from
9.2.2, 9.2.2 H09, 9.2.3, 9.2.3 H11, or H12. For more information about these schema changes, see Schema Changes in MySQL Databases for Spectrum 9.4.
If you have installed
, verify that free disk space on the system is at least twice the size of the largest MYD file under
$SPECROOT
/mysql/data/reporting.
Do not install third-party software that uses MySQL because the results can be unpredictable.
If your existing
environment manages a VMware Virtual environment, upgrade your remote
CA eHealth SystemEDGE
deployments to the latest version. This release of
does not support the local deployment of
CA eHealth SystemEDGE
, so remove the local
CA eHealth SystemEDGE
deployments. The latest remote
CA eHealth SystemEDGE
deployments can now manage multiple vCenter servers.
After you upgrade from
9.2.2, 9.2.2 H09, 9.2.3, 9.2.3 H11, or H12, complete these tasks:
  • If necessary for your environment, run the conversion script to convert the data in your fault-tolerant DDM database to a supported encoding. For more information, see Upgrade Scenarios that Require a One-Time Database Conversion. The syntax is documented in Perform One-Time Database Conversion (Fault-Tolerant Environments).
  • To know the status of the conversion of the Report Manager database, see the tomcat log file at
    $SPECROOT
    \tomcat\logs.
  • As LACP is supported from this release, run the "RecreateLACPModels.pl" script to reconfigure your existing LACP-enabled interface models. This script is located at "C:\win32app\Spectrum\Install-Tools\PostInstall". Run this script when you are upgrading from 9.3 also.
  • If you configured OneClick to launch from Report Manager using SSL, configure this modification again.
    For more information about this modification, see
This section contains information about the following topics: