Linux-UNIX: Managing GIM clients during a major upgrade of the database server operating system

When you upgrade the operating system on your database server, use the GIM client to automatically upgrade itself and the GIM bundles (for example, GIM, S-TAP, CAS) installed on the Linux-UNIX database. However, most operating systems do not support a major upgrade, for example from RHEL7 to RHEL8.

Before you begin

The target upgrade GIM bundles must be available on the GIM server. The build number of each bundle must be the same or greater than the bundle that is installed. Download from Fix Central.

About this task

This procedure is only relevant for databases whose operating system can be upgraded. If you cannot upgrade the operating system, you must uninstall the S-TAP, install the new operating system, and install the S-TAP bundle that is compatible with the newly installed operating system.

GIM bundles are OSType/OsVersion/Processor specific. When the OS version changes (for example, from RHEL7 to RHEL8), all the bundles need to be upgraded.

The GIM parameter auto_install_on_db_server_os_upgrade controls GIM's ability to auto-upgrade all bundles. If enabled, when the database server boots up after an operating system upgrade, GIM automatically downloads and install these bundles. This parameter is disabled by default, to prevent unintentional bundle upgrades.

If the parameter is disabled when you upgrade the database operating system, the GIM client detects that the operating system changed, and it changes the _x suffix of the version to _0. You can see the version in the Set up by Client, for example, 10.6.1.4_r123456_0. To resolve the mismatch between the GIM client and the database operating system, do one of:
  • Enable the GIM global parameter auto_install_on_db_server_os_upgrade, which automatically upgrades all the GIM clients with the latest bundle of the operating system they support.
  • Do not enable auto_install_on_db_server_os_upgrade, and upgrade the GIM clients manually.
It is best to update all your GIM-installed modules as soon as possible after the upgrade, whether manually or automatically. K-TAP is not loaded after an operating system upgrade.

Procedure

  1. Log in to the CLI of the Guardium system that is the GIM server
  2. Enable auto_install_on_db_server_os_upgrade by entering: 
    grdapi gim_set_global_param paramName="auto_install_on_db_server_os_upgrade" paramValue="1"
  3. Upgrade the operating system on your database server.

Results

At first boot after OS upgrade, the GIM client recognizes that the operating system was upgraded and:
  1. Changes the configuration files for all GIM-installed modules to support the new operating system attributes.
  2. Reregisters all the modules to the GIM server with the updated attributes. This change triggers the GIM server to look for a bundle that has the same build number as the previously installed bundle, but is compatible with the upgraded operating system. If it does not find such a bundle, it looks for the latest bundles that support the new operating system attributes. When the server finds appropriate bundles, it schedules them for upgrade and runs the upgrade process immediately. If the server cannot find appropriate bundles, it issues an error message.
  3. Records an alert in the GIM_EVENTS report, that an operating system upgrade occurred and lists the actions that should be taken.

What to do next

Review the messages in the GIM_EVENTS report. If the GIM server reports that the modules were upgraded successfully, verify the proper operation of the modules as you would do after any update.

If error messages were written to the GIM_EVENTS report, indicating that the upgrade was not successful, review the error messages for guidance.

When the operating system upgrade is complete, disable the automatic update option on the GIM server to prevent a GIM client from erroneously starting an update process.
grdapi gim_set_global_param paramName="auto_install_on_db_server_os_upgrade" paramValue="0"