6.5 Upgrade Platform Container

Follow the steps in this section to upgrade the Platform Container.

1. Before performing an upgrade, the database may require an upgrade by running certain patch scripts. 
    

   1. Run the following script for generating a *.tar file containing the patch script(s):

      $ ./setup.sh prepare_db_upgrade

      Note!

      You must specify username, password, and database type. You can also specify them using command line.

      $ ./setup.sh prepare_db_upgrade -Dmz.username=mzadmin -Dmz.password=<password> -Dmz.databasetype=<database type: [oracle, postgresql, derby, saphana]>

      The file database-upgrade.tar containing the required patch scripts is generated.

      Derby Database

      For a Derby database, no tar file is generated. It is automatically upgraded during step 2, skipping steps b-d.

   2. Copy the file to the database server. This is not applicable for Derby databases.
       

   3. Extract the script(s):

      $ tar xvf database-upgrade.tar

   4. Run the commands specific to the database.

      1. For Oracle:

         $ sqlplus <Owner user>/<password> < database-upgrade.sql
         $ sqlplus <JDBC User>/<password> < database-upgrade-synonyms.sql

      2. For PostgreSQL:

         $ psql -d mz -U <Owner user> -f database-upgrade.sql

      3. For SAP HANA:

         $ hdbsql -d MZ -u <JDBC User> -p <password> -I database-upgrade.sql

2. Use the setup script setup.sh, that was extracted when unzipping the upgrade software, to upgrade the Platform Container.

   $ ./setup.sh upgrade

   Note!

   Before running the upgrade, ensure that the install.xml file does not exist in your installation directory. In this case, the upgrade script will fail. If a copy of install.xml is present, it is recommended to either move the file to another directory or remove the file in case it is no longer needed.

   Hint!

   The setup script verifies that the target file system has at least 5 GB free space. If the validation fails you are prompted to choose to continue or not. Choosing not to continue aborts the upgrade. You can disable this validation by adding the following flag to the setup script:

   $ ./setup.sh upgrade -DsilentMode=y

   


3. Enter the username and password.

   Hint!

   You can also add the username and password properties to the setup.sh script:

   $ ./setup.sh upgrade -Dmz.username=mzadmin -Dmz.password=<password>

4. Enter the URL for the Platform web interface, for example http://platform1:9000, and the upgrade will start. 

   Hint!

   You can also add the URL to the setup.sh script:

   $ ./setup.sh upgrade -Dmz.platform=<URL>

   When using the setup.sh upgrade command, three different log files are created: generate<timestamp>.log, validate<timestamp>.log, and upgrade<timestamp>.log. By default, these log files are placed in the same directory as setup.sh.

   Example - Extracting the upgrade software

   If you want the log file to be placed in another directory, add the upgradelogdir property to the setup script:

   $ ./setup.sh upgrade -Dmz.upgradelogdir=<directory path>

   Hint!

   It may be a good idea to open a new command line window in order to keep track of the log files.

   A successful upgrade command will display "Version successfully changed from <old_version> to <new_version>" at the end of the command output. A successful upgrade may also display "The following things may require your manual attention" at the end of the command output, followed by a list of things that may need manual attention.
   In case the upgrade is unsuccessful, this will be indicated. Check the latest upgrade_<timestamp>.log file for further details in order to analyze the result and see what may have caused the problem. If it is needed, a downgrade can be performed. For information about how to perform a downgrade, see 7. Standard Downgrade Procedure.

   Note!

   If the upgrade fails, you may want to perform a downgrade. In case the downgrade also fails, you can try to manually remove or rename the version folder that has been created in MZ_HOME/upgrade_history/<version> before you attempt to downgrade the system again. The version folder may be stored in a different directory if the property pico.upgrade_history is set in common.xml.

   Note!

   If you are using SAP HANA as the Platform database, you must enable TLS/SSL on the SAP HANA database after you upgrade your Platform. Refer to Upgrade to 8.2 in the Release Information for the steps.

   Hint!

   If any configurations have become invalid due to the upgrade, these are listed in the log file. Search for the string "Regenerating configs" in the log file to find information about any invalid configurations.

   Example - Output in the upgrade_<timestamp>.log file with invalid configurations

   Mon Nov 19 10:52:10 CET 2013 Regenerating configs 
   The following configurations changed status and may require manual attention: 
   Workflow Test.WF1 became invalid, 
   Workflow Test.WF2 became invalid, 
   APL Code Test.apl_profile became invalid,