Maximo Open Forum

 View Only
  • 1.  Database tables are empty after failed migration of database configuration changes

    Posted 03-28-2025 13:54

    I attempted to do a migration from a DEV environment to a TEST environment using Migration Manager.

    The migration failed with an error, and the server then "thought" that database configuration was still happening.  It would not allow the Maximo UI server to be restarted.

    I had to manually update the flag that indicated a DB Config was in process, after which Maximo server did start up.

    The issue is that now the work order table is totally empty of records... associated tables such as wostatus, etc still do contain records.

    The table that I was doing the configuration changes to was the work order table.
    The question I have for the group, have you ever seen were a failed deployment of a migration package has cause Maximo database data to be deleted?

    thanks
    Steve H.


    #Architecture

    ------------------------------
    Stephen Hume
    Sheffield Scientific LLC
    ------------------------------


  • 2.  RE: Database tables are empty after failed migration of database configuration changes

    Posted 03-29-2025 16:56

    OK I learned something new about Maximo yesterday... when doing a database configuration, the table that is being updated is copied to a temporary table called XXtablename (in this case XXWORKORDER).  

    On the Maximo server there are a series of small command files that will help correct the situation when your DB Config goes awry.  In the following folder on the server  install_home\tools\maximo  there are three tools that will help in the situation I found myself.

    In all cases the Maximo Application Server needs to be stopped to run the commands

    configdb.bat it can be used to run database configuration
    restorefrombackup.bat is the command that will copy the XX table back into the main table (in my case XXWORKORDER  copied into WORKORDER.
    dropbackup.bat to get rid of the backup table once it has been restored.

    I needed to learn how to do this, because to be honest I cannot remember the last time a database configuration went sideways.

    Here is the link to the page that helped me correct things.
    https://maximobymanoj.blogspot.com/2015/01/how-to-recover-failed-database.html



    ------------------------------
    Stephen Hume
    Sheffield Scientific LLC
    ------------------------------



  • 3.  RE: Database tables are empty after failed migration of database configuration changes

    Posted 03-30-2025 14:21
    Hi Stephen, I recently faced this issue when I was adding an attribute with audit enabled in the WORKORDER table. DB config process got stuck, and all records in the WORKORDER table got deleted. I tried these steps, but when I executed restorefrombackup.bat, it ran for about 30-35 minutes with no visible updates or background activity. Maybe it just needed more time to restore the workorder data, but I stopped it and it was a test environment, I was able to restore the data using an online backup.
     
    How long did restorefrombackup.bat take for you? Is there a way to check if the restorefrombackup.bat process is actually running? the terminal was blank and I wasn't sure if there was any updates.
     
    Thanks for sharing, it will help me in a similar scenario in the future.


    ------------------------------
    Hariprasad R
    ------------------------------



  • 4.  RE: Database tables are empty after failed migration of database configuration changes

    Posted 03-30-2025 17:43

    The restorefrombackup took about 10 minutes to complete... that being said it all depends how many records are in the workorder table.



    ------------------------------
    Stephen Hume
    Sheffield Scientific LLC
    ------------------------------



  • 5.  RE: Database tables are empty after failed migration of database configuration changes

    Posted 03-31-2025 16:17

    Is this a case of the database running out of logical space? I know we encountered something similar during our 7.1 to 7.6 upgrade. We had plenty of physical disk space, but the database itself had a logical size constraint: the DBA had to allow more significant growth during the upgrade process. The DBA may have more clues as to why the migration failed by reviewing the logs.



    ------------------------------
    sun kim
    ------------------------------