Before upgrading a TIBCO LogLogic LMI instance, a health check script, called healthcheck.sh, must be executed to check that all database tables are present and have the correct definitions.  Occasionally, the script may fail, and you will see something similar to the following output on screen:

Logapp root:/loglogic/tmp/upgrade/healthcheck 0$ ./healthcheck.sh
-------------------------------------------------------------
The platform checking passed.
-------------------------------------------------------------
Post upgrade checking passed.
-------------------------------------------------------------
Using /loglogic/conf/lsp_packages/LSP31/schemas_5.5.1_31.tar as reference
Checking schema definitions in database logapprtrpt ...
Checking schema definitions in database logappconfig ...
Schema consistency checking failed. Check log file /loglogic/tmp/_schemaChecking/schemaChecking.log for details.
-------------------------------------------------------------
Dmi information is correct.
-------------------------------------------------------------
Ignore the inconsistency?[yes/no]: yes
The inconsistency is ignored.

On checking the schemaChecking.log file, created in /loglogic/tmp/_schemaChecking/ you may see the following:

  ** The table logappconfig.oddsfieldtags has been altered or does not exist.
======
13c13
<   KEY `msgPatternId` (`msgPatternId`),
---
>   KEY `oddsfieldtags_ibfk_1` (`msgPatternId`),
======

This indicates that there is a key on the oddsfieldtags table that has an incorrect name.

This is an issue that only occurs when upgrading to 5.6.0 or higher. It has been seen primarily in HA-enabled configurations.

To rename the key, perform the following procedure. TIBCO recommends creating a backup of the database before making these changes using the LMI backup feature, or the command below can be used to quickly create a full backup snapshot. The key we are renaming has a foreign key constraint as well, so we will also be removing and later re-adding that. 

To create a full backup of the logappconfig database, simply paste the following at the toor prompt and press Enter:

$ mysqldump logappconfig > /loglogic/tmp/logappconfig.backup

• At the toor prompt, paste the following, then press Enter:

$ mysql logappconfig -vve '
ALTER TABLE oddsfieldtags DROP FOREIGN KEY oddsfieldtags_ibfk_1;
DROP INDEX msgPatternId on oddsfieldtags;
CREATE INDEX oddsfieldtags_ibfk_1 on oddsfieldtags(msgPatternId);
ALTER TABLE oddsfieldtags ADD CONSTRAINT oddsfieldtags_ibfk_1 FOREIGN KEY (msgPatternId) REFERENCES oddsmessagepattern(uuid) ON DELETE CASCADE;'

If you now run the healthcheck.sh script again, you should see the following:

Logapp root:/loglogic/tmp/upgrade/healthcheck 0$ ./healthcheck.sh
-------------------------------------------------------------
The platform checking passed.
-------------------------------------------------------------
Post upgrade checking passed.
-------------------------------------------------------------
Using /loglogic/conf/lsp_packages/LSP31/schemas_5.5.1_31.tar as reference
Checking schema definitions in database logapprtrpt ...
Checking schema definitions in database logappconfig ...
Schema consistency checking passed.
-------------------------------------------------------------
Dmi information is correct.
-------------------------------------------------------------

Note that this is a one time change for each LMI instance so after these changes are made they will not need to be applied again for future upgrades. The discrepancies that are flagged between what the database table schemas contain and what the healthcheck expects can differ across LMI and LSP versions so if you encounter other messages other than what is documented in this article then contact TIBCO LogLogic Technical Support.

This article shows how to proceed when the healthcheck.sh script fails and the schemaChecking.log file has references to a table called oddsfieldtags.