Before you upgrade to CA SDM Release 12.7, consider the following database information to help you upgrade:
- Back up your existing database using your typical database backup procedures.
- Archive the installation directory ($NX_ROOT) using your typical archive procedures. This action lowers the amount of data movement and saves disk space.
- Run the appropriate script from a command prompt to identify any duplicate records on your database:
Note: Run this script on the secondary servers. If you want to run this script using SQL Query Analyzer, edit the SQLCHECK.SQL script and remove the EXIT argument before you run the command.
- (Oracle) Run OracleCheckr12UniqueIndexes.sql, located in the \Migrate directory on the installation media.
- (SQL Server) Open a Command Prompt window and run SQLCHECK.SQL as follows:
cd $NX_ROOT\samples\views\SQLServer
Enter the command:
Sqlcmd -E -e < SQLServer\SQLCHECK.SQL
Note: After you upgrade to CA SDM Release 12.7, you can find these files at $NX_ROOT/samples/views/SQLServer or $NX_ROOT/samples/views/Oracle on the server.
Important! These scripts identify your duplicate records. Delete identified duplicate records before you proceed with the migration.
- For Windows, you can upgrade directly to CA SDM Release 12.7 from r11.2, r12.0, r12.1, r12.5, and r12.6.
- If you intalled CA SDM on UNIX or Linux, you can upgrade to CA SDM Release 12.7 from r12.5 and r12.6.
- If your installation contains an earlier version of the product, such as CA SDM r11.2, r12.0, or r12.1 on a nonsupported UNIX/Linux operating system and database, you must upgrade to CA SDM r12.5. Then, move CA SDM to a supported operating environment and database before you upgrade to CA SDM Release 12.7.
- Upgrade your CA SDM r11.2 system to a supported database (SQL Server and Oracle).
Note: For more information about supported database, see the Release Notes.
- Upgrade from Unicenter Service Desk r11.0 to CA SDM r11.2 before migrating your data to a supported database.
- Special Windows characters, such as a long hyphen, in CA SDM or Knowledge Management on a non-Windows system, are not properly stored in the database.
- Ingres—If you are using an Ingres database, convert your data to Oracle or SQL Server before upgrading.
Note: For information about the conversion process, see your database documentation.
- Oracle—Oracle does not support case insensitive indexes for Configuration Item registration. Before you start the migration on Oracle, verify SQLPlus and Oracle DB are able to communicate using hostname. If communication fails, verify that Oracle is configured with loopback adaptor.
Note: When you migrate in a double-byte character environment with an Oracle database, increase the maximum open cursor limit to at least 500. For more information, view Oracle documents about ORA-01000 (maximum open cursor exceeded).
- SQL Server—For an SQL Server upgrade to the current release of CA SDM, the default database for the configured Database Userid must be CA MDB. If the default database is not CA MDB, the migration console fails and displays the following message:
"The acctyp_v2 table does not exist on the MDB"
- Tomcat—(for Unicenter Service Desk r11.0, r11.1 or CA SDM r11.2) If you configured Tomcat for external authentication, manually reconfigure Tomcat for external authentication after upgrading to the current product release.
- Table Updates—Consider the following table updates that occur during migration:
- Status Tables—These tables are also updated with the appropriate status records when the same code values do not exist in your database. For example, Cr_Status is updated with the code AEUR (Awaiting End User Response).
- Functional Areas—For each role, migration automatically adds a row for each usp_functional_access record. Migration sets the access level to the same level for each CA SDM r12.0 and r12.1 functional area that the usp_role table includes. New functional areas are mapped using a reference field.
- Foreign Keys—Consider the following information:
- Foreign keys (SRELs) that reference tables, in which the primary key is a UUID, change from integer type to UUID type (or BYTE 16).
Note: For information about setting SREL attributes with foreign key values, see the CA SDM Technical Reference Guide.
- If you dropped foreign key constraints in your previous CA SDM system to mass load data, recreate the foreign key constraints before you run the upgrade. The scripts that drop the constraints are found in the following locations:
Note: Reapply the dropped constraints by running the appropriate script OracleAddConstraints.sql or SQLServer/SQLAddConstraints.sql. These scripts are found in the same directory as the drop constraints and contain instructions within the files mentioned.
- MDB—The MDB provides a consistent database schema for various IT management data. During the development of the MDB, data elements from your previous CA SDM environment were incorporated into this schema. The size of the data elements can increase and, consequently, increase the overall database size.
Note: When standard data elements extend beyond the column width defined for the MDB, the update process can truncate data in these elements. Messages alert you to any truncation that occurs during the upgrade.
- Distributed Setup—We recommend that you upgrade your primary server before any secondary servers.
- Remote Database Setup—Consider the following information:
We recommend that you upgrade the database server with a new MDB before upgrading the Primary Server. If your database server is remote, run the CA MDB installation on the database server before running the upgrade.
- If you are using a SQL Server MDB database, sqlcmd must be on the client computer before connecting to the remote MDB.
