Mark Maximo objects for deletion with SQL

Maximo Migration Manager can move new and changed database objects between environments, but removing a group of objects is less convenient. This script marks several objects and their attributes for removal in the Database Configuration staging tables. ConfigDB then applies the deletion through Maximo's normal database configuration process.

The values in the script are Maximo object names, even when each object owns a physical table.

This operation deletes database structures and their data. Use it only for custom objects that your organisation owns. Do not mark an IBM-supplied object for removal, and do not assume an object can be deleted just because its name looks custom. Take a tested database backup and rehearse the complete change in a disposable environment first.

IBM explains that Database Configuration stores pending changes in secondary tables and applies them only when the database is configured. Its Database Configuration overview also requires a backup before creating or deleting objects, attributes or indexes.

Check every object first

Replace the example names with the objects you intend to remove and inspect their configuration records:

SELECT
  OBJECTNAME,
  ENTITYNAME,
  PERSISTENT,
  ISVIEW,
  USERDEFINED,
  CHANGED
FROM
  MAXOBJECTCFG
WHERE
  OBJECTNAME IN (
    'TABLE1',
    'TABLE2',
    'TABLE3'
  );

Before proceeding, confirm all of the following:

• every name resolves to exactly one expected object;
• each object is user-defined and belongs to this customization;
• no other object shares or extends the physical entity in a way that still requires it;
• its data has been archived or is safe to destroy;
• applications, relationships, domains, object structures, integrations, reports, escalations, cron tasks, workflows, security options and automation scripts no longer refer to it;
• no unrelated Database Configuration changes are waiting to be applied.

Prefer marking the objects for deletion through the Database Configuration application when it is practical. Direct SQL is a fallback for a controlled bulk removal or a migration process that cannot represent the deletion cleanly.

Mark the objects and attributes for removal

Start a database transaction. Mark the selected object definitions with the removal status:

UPDATE
  MAXOBJECTCFG
SET
  CHANGED = 'R'
WHERE
  OBJECTNAME IN (
    'TABLE1',
    'TABLE2',
    'TABLE3'
  );

Verify that the affected-row count equals the number of objects in your list. If it does not, roll back and correct the list.

Next mark every staged attribute belonging to those objects:

UPDATE
  MAXATTRIBUTECFG
SET
  CHANGED = 'R'
WHERE
  OBJECTNAME IN (
    'TABLE1',
    'TABLE2',
    'TABLE3'
  );

Review the staged result before committing:

SELECT
  OBJECTNAME,
  ATTRIBUTENAME,
  CHANGED
FROM
  MAXATTRIBUTECFG
WHERE
  OBJECTNAME IN (
    'TABLE1',
    'TABLE2',
    'TABLE3'
  )
ORDER BY
  OBJECTNAME,
  ATTRIBUTENAME;

Every returned attribute should have CHANGED = 'R'. Check the object rows again as well. If any result is unexpected, roll back the transaction.

When the staged records are correct, commit them using the transaction procedure for your database platform:

--Commit Changes
COMMIT;

Run ConfigDB

Schedule an outage and stop every Maximo application server connected to the database. Wait at least one minute for its server-session heartbeat to expire, then run ConfigDB from the matching Maximo administrative workstation:

cd <MAXIMO_ROOT>\tools\maximo
configdb.bat

On Linux or UNIX, use the corresponding configdb script from the same directory. IBM's command-line database configuration procedure covers the shutdown, command and log location.

Do not restart Maximo merely because ConfigDB exits. Review its latest log under <MAXIMO_ROOT>\tools\maximo\log and confirm that it removed only the intended objects, attributes and physical structures. If ConfigDB reports an error, preserve the log and restore or repair the configuration using the tested recovery plan rather than making additional ad hoc metadata changes.

After a successful run:

1. confirm the object and attribute definitions are gone;
2. confirm the expected tables or views were removed;
3. run the Maximo Integrity Checker and investigate new errors;
4. rebuild and deploy the application EAR if the customization also removed Java classes or other application files;
5. start Maximo and test the applications and integrations that previously touched the objects.

This is a legacy Maximo Asset Management procedure. Maximo Manage customizations use deployment-managed customization archives and should follow the removal process documented for their exact release.