Skip to main content

Update the SSMS

The chapter instructs you on how to update the existing SSMS and how to migrate the database from the old versions to the new version.

Note: Please back up the existing configuration directory <SSMS_HOME>) as well as the existing database.

In a cluster environment it is generally required to do a full cluster shut down for a module or installer update. Each node must be updated and restarted.

You have two options to update the system and to migrate the database: on the same server you have used so far or on a new server, thus having two SSMS versions running simultaneously. For the second option, you must import the configuration file (config.xml) and the certificates of the old version. Find a diagram of the two options on the next page:

1 - Diagram about migration option 1​

image

Carry out the steps described in option 1, if you install the new SSMS version on the same server you have used so far

  1. Stop the SSMS and the configuration utility.

  2. Back up the database (default name „ssms_db") as well the configuration file config.xml, contained in the directory <SSMS_HOME>{=html}/configutil. Optionally, you can also back up the whole directory <SSMS_HOME>{=html}. >. In this regard, we need to point out that is necassary to safing the the complete path of SSMS_INSTALL.

  3. Install the new SSMS version over the already existing version.

  4. Start the CU

    1. If the CU displays the error message that you should migrate the database go to step 5
    2. The error message under a may be displayed after installing specific modules. Click on "Verify configuration" on the right of the CU view and go to the "Modules" view. Check the modules to be installed and click "Save". If the CU displays the error mess age that you should migrate the database go to step 5
    3. If none of the scenarios a or b is your case, skip to step 6
    4. Stop the CU. Run the database migration program contained in the directory <SSMS_INSTALL>{=html}/tools/db-migration on the console

Windows: db-migration.exe Linux: ./db-migration

To start the database migration process, enter Yes or y.

You get a notification, which reminds you about the requirement to back up your database in case you have not done it yet. You must confirm this action by entering: Yes, I did a backup

You are then prompted to enter the administrator or table owner name and the corresponding password. In case you do not enter anything, you are prompted three times before the migration is canceled.

Please note that the name of the database administrator for Oracle database must be the same as the name given for this purpose in the CU and saved in the config.xml. If both names do not match,the database migration is interrupted before the database is changed. The user name for Oracle should first be created in the CU and the database migration should be started again. For MSSQL and MySQL, the name entered during the migration is not compared to the name in the config xml; in this case, only the permissions are verified. In case the permissions are not sufficient, the migration is canceled.

After you entered the administrator name and the password, the database information are first shown to you. In addition you receive information about the modules that are updated and from which version to which current version the database is migrated. After this information you are prompted to confirm or to interrupt the desired migration on the base of the information displayed before. In case you wish to interrupt the migration, you are prompted to confirm the interruption.

In case of an error, the database migration toll returns corresponding information on the console. In addition, errors are stored in the log file “ssms_database_migration.log” (saved in the directory <SSMS_HOME>/logs).

If the migration was successful, you receive the message: SSMS Database Migration SUCCESSFUL.

You are prompted to press the Enter key to exit the database migration tool.

The old SSMS database is automatically migrated under the same name into the new database schema. All existing data are either retained or are migrated. New tables and master data are added, if needed.

Re-start the CU.

Click on "Verify configuration" on the right of the CU view and go to the "Modules" view Check the modules to be installed and click "Save".

  1. Confirm the changes with Deploy and start the SSMS via the configuration utility. The new SSMS and the database are ready for use.

If the SSMS does not start after the migration, delete the Tomcat webapps directories ssms-gui and ssms-services.

The log file ssms_database_migration.log of the migration tool is created in the directory <SSMS_HOME>{=html}/logs.

2 - Migration Option 2​

image

Diagram about migration option 2

Carry out the steps described in option 2 if you want to install a new SSMS version, parallel to the old one, on a new server. In this case, you must import the configuration file (config.xml) in order for the new server to know the URL of the database.

  1. Install the new SSMS version

  2. Stop the old SSMS nodes and the old configuration utilities.

  3. Copy the configuration file config.xml of the old SSMS, contained in the directory <SSMS_HOME>{=html}/configutil onto the new server.

  4. Start the CU on the new server and import the copied config.xml.

    1. Go to "Database" view and save the database configuration. If the CU displays the error message that you should migrate the database stop the CU and go to step 5
    2. The error message under a may be displayed after installing specific modules. Click on "Verify configuration" on the right of the CU view and go to the "Modules" view. Check the modules to be installed and click "Save". If the CU displays the error message that you should migrate the database stop the CU and go to step 5.
    3. If none of the scenarios a or b is your case, skip to step 8

  5. Back up the database (default name "ssms_db")

  6. Run the database migration program contained in the directory <SSMS_INSTALL>{=html} /tools/db- migration of the new SSMS on the terminal

    Windows: db-migration.exe Linux: ./db-migration.sh

    To start the database migration process, enter Yes or y.

    You get a notification, which reminds you about the requirement to back up your database in case you have not done it yet. You must confirm this action by entering: Yes, I did a backup

    You are then prompted to enter the administrator or table owner name and the corresponding password. In case you do not enter anything, you are prompted three times before the migration is canceled.

    Please note that the name of the database administrator for Oracle database must be the same as the name given for this purpose in the CU and saved in the config.xml. If both names do not match, the database migration is interrupted before the database is changed. The user name for Oracle should first be created in the CU and the database migration should be started again. For MSSQL and MySQL, the name entered during the migration is not compared to the name in the config.xml; in this case, only the permissions are verified. In case the permissions are not sufficient, the migration is canceled.

    After you entered the administrator name and the password, the database information are first shown to you. In addition you receive information about the modules that are updated and from which version to which current version the database is migrated. After this information you are prompted to confirm or to interrupt the desired migration on the base of the information displayed before. In case you wish to interrupt the migration, you are prompted to confirm the interruption.

    In case of an error, the database migration toll returns corresponding information on thcconsole. In addition, errors are stored in the log file “ssms_database_migration.log” (saved in the directory <SSMS_HOME>/logs).

    If the migration was successful, you receive the message: SSMS Database Migration SUCCESSFUL.

    You are prompted to press the Enter key to exit the database migration tool. The old SSMSdatabase is automatically migrated under the same name into the new database schema. All existing data are either retained or are migrated. New tables and master data are added, if needed.

  7. Start the new configuration utility.

  8. Work through the open issues of the configuration utility. In the "Connections" view u se the same nodeID as the nodeID of the old SSMS (from the config.xml you copied).

  9. Confirm the changes with Deploy and start the SSMS via the configuration utility. The new SSMS and the database are ready for use. You can delete the old SSMS after checking the functioning of the new one.

If the SSMS does not start after the migration, delete the Tomcat webapps directories ssms-gui and ssms-services.

The log file ssms_database_migration.log of the migration tool is created in the directory <SSMS_HOME>{=html}/logs.