Fix 'MXServer is running' when UpdateDB cannot start

Maximo's UpdateDB and ConfigDB utilities can stop with this message even after you shut down the application server:

MXServer is running. It must be down to run UpdateDB.

The check exists for a good reason: changing the database while a Maximo JVM is using it can leave the application and schema out of step. Do not clear the check until you have proved that every Maximo JVM connected to that database is stopped.

How Maximo detects a running server

When a Maximo application server starts, it creates a row in MAXSESSION with ISSYSTEM = 1. The server refreshes SERVERTIMESTAMP every 60 seconds. UpdateDB and ConfigDB look for a recent system-session heartbeat and refuse to continue if they find one.

IBM explains the server and user rows in The MAXSESSION table unmasked. IBM also documents this exact UpdateDB symptom in Updatedb process does not start due to active Maxsession.

The legacy checks are equivalent to the following platform-specific queries.

Oracle

SELECT
  SERVERHOST,
  SERVERTIMESTAMP
FROM
  MAXSESSION
WHERE
  ISSYSTEM = 1
  AND SERVERTIMESTAMP >= (SYSDATE - (60 / 86400));

DB2

SELECT
  SERVERHOST,
  SERVERTIMESTAMP
FROM
  MAXSESSION
WHERE
  ISSYSTEM = 1
  AND SERVERTIMESTAMP >= (CURRENT TIMESTAMP - 60 SECONDS);

SQL Server

SELECT
  SERVERHOST,
  SERVERTIMESTAMP
FROM
  MAXSESSION
WHERE
  ISSYSTEM = 1
  AND DATEDIFF(SECOND, SERVERTIMESTAMP, GETDATE()) < 60;

These queries are useful diagnostics, but the implementation can vary between Maximo releases. They also depend on accurate clocks. In particular, a future SERVERTIMESTAMP caused by clock skew produces a negative SQL Server DATEDIFF, which still satisfies < 60.

Prove that the row is stale

First stop every Maximo application JVM that connects to the database, including cluster members, integration servers, cron servers and forgotten test instances. IBM's UpdateDB guidance explicitly requires the Maximo application server to be stopped before the utility runs.

Then:

Query all system sessions and save the result for your change record.
Wait for longer than the 60-second heartbeat interval.
Query the rows again.
Compare SERVERTIMESTAMP and SERVERHOST with the first result.

Use this platform-neutral inspection query:

SELECT
  SERVERHOST,
  SERVERTIMESTAMP,
  ISSYSTEM
FROM
  MAXSESSION
WHERE
  ISSYSTEM = 1
ORDER BY
  SERVERHOST,
  SERVERTIMESTAMP;

If a timestamp advances, a JVM is still connected. Find and stop it instead of deleting its row. If the timestamp is in the future, correct the clock difference between the application and database hosts before continuing.

If the rows remain unchanged and every relevant process is stopped, they are stale records left behind by an abnormal shutdown.

Remove stale system sessions

Back up the database, or at least export the rows you are about to remove. Start a transaction and delete only system-session rows:

DELETE FROM
  MAXSESSION
WHERE
  ISSYSTEM = 1;

Check the affected-row count against the rows you inspected. If it differs, roll back and find out what changed. Commit only when the result is expected.

Do not delete user-session rows with ISSYSTEM = 0, and do not edit SERVERTIMESTAMP simply to defeat the check. A server that is still running will recreate or refresh its system session, and proceeding in that state can damage the update.

Run UpdateDB or ConfigDB again from the correct Maximo installation after the stale rows are committed. Keep all Maximo JVMs stopped until the database work and any required application rebuild and deployment have completed. Review the utility log before bringing the environment back into service.

If the warning immediately returns, treat it as evidence of another live JVM, a connection to the wrong database, clock skew or a release-specific problem rather than repeatedly deleting MAXSESSION rows.

Settings

Keyboard shortcuts