Failing upgrade to E0504P02

[jerodrig]

Hello,

I've tried to upgrade our IMC installation from 7.3 (E0504) to 7.3 P02 (E0504P02). The upgrade failed with the following error :

Begin to install database and data...
-----------------------------
Begin to install monitor_db data...
-----------------------------
Begin to create monitor_db table...
Msg 2705, Level 16, State 4, Server PR-STI-IMCDB01, Line 2
Column names in each table must be unique. Column name 'res_source_type' in
table 'tbl_trap_data_event' is specified more than once.

IMC is installed on Windows as well as the database (SQL Server).

Only one module got upgraded (Resource Management), the others are in state For Upgrade. I can start the processes and IMC is still available so it's not critical, but I can't upgrade. I've tried with the newest patch (E0504P04) and the problem remains the same.

Any ideas ?

Regards.

[NeilR]

Hi,

I've had these types of errors before. They occur when the update script tries to modify the database and add new table structures or values and finds existing stuff it didn't expect. I've had it occur between patches and going between 7.2 and 7.3.

The safest course is to contact HPE and log a support ticket, whch will eventually work up to the devs who can help resolve it.

However I've had success resolving these - so first: You need a backup before trying this. I use the IMC backup tool as well as VMware snapshots so I can recover the system or the data serparately if I don't succeed.

SO MAKE A BACKUP BEFORE ANY UPGRADE or trying any of these suggestions - unrecoverable damage may occur!

one cause is customizations - adding additional items to the system. if you suspect these, try deleting them before the upgrade. Sometimes deleting from the UI does not remove all the references - you may need to use SQL to hunt these down.

SQL server managment tool for MS SQL server or SQL workbench for mySQL are useful for finding the tables, querying the data and locating suspected issues that can then be deleted.

Another option is to undeploy/remove the module that uses the table or DB causing the script to error. This will - ususally - remove the DB/tables/records used by the modules.

Then redeploy the module and a fresh instance will be created. You can then usually run the update. You will loose any data in those tables, so if you need to keep it, back it up first. You can restore later within the same versions, but not across major releases. 

If that doens't work or you can't undeploy you can try removing the table itself.. The module scripts may create a new table - but not always at the patch level. This option is less successful.

I've been able to get past these, but I've given up some history data and had to do some rework. If your data is critical, or you don't feel confortable contact HPE for help.

Good luck - hope this helps

[jerodrig]

Thanks for your answer Neil.

I've tried to manually delete the faulty column in the database. When I did that and then relaunched the upgrade procedure, the column was recreated but it then complained about another faulty column. I repeated the procedure a few times (deleting 4 columns in 6 different tables) and I thought the problem was resolved but again, another error was dropped. This time, it was about an all new table without any link with the previous faulty ones.

Deleting any complaining columns in multiple tables seems too risky, so I'll try to open a ticket to HPE.

Thanks for your help.