Informix

nested-group-icon.png

DB2

Upgrade with Success from Informix 11.70 to Informix 14.10

By Gaurav Kumar posted Mon July 13, 2020 12:25 AM

  
4 comments
553 views

Permalink

Comments

Wed July 22, 2020 02:06 AM

Hello Art,

Please find my comments in-line:

1 - You mention using a dummy update to resolve outstanding in-place alters, however there is also the API functions: "table update_ipa" and "fragment update_ipa" which do not fire triggers and can run in the background and in with parallel processing.
[Gaurav]: As far as i remember, that API is newely introduced in 12.10.xC4 and here we are fixing outstanding alter in 11.70.

2 - You mention using "cdr" for rolling upgrades by converting the secondaries to ER secondaries, upgrading all the servers then converting them back. However, it is now also possible to perform rolling upgrades of minor releases and up to one major release in-place just be upgrading the secondaries then the primary. I know that this would not work for an upgrade from v11.70 to v14.10, but it should be noted as a newer feature.
[Gaurav]: Yes for minor cdr is not required, but for major and if its a new hardware new OS then cdr feature might help DBA to keep their application up and running while they upgrade. And here we are doing version upgrade from 11.70 to 14.10

Tue July 21, 2020 09:04 AM

Two comments Gaurav:
1 - You mention using a dummy update to resolve outstanding in-place alters, however there is also the API functions: "table update_ipa" and "fragment update_ipa" which do not fire triggers and can run in the background and in with parallel processing.
2 - You mention using "cdr" for rolling upgrades by converting the secondaries to ER secondaries, upgrading all the servers then converting them back. However, it is now also possible to perform rolling upgrades of minor releases and up to one major release in-place just be upgrading the secondaries then the primary. I know that this would not work for an upgrade from v11.70 to v14.10, but it should be noted as a newer feature.

Mon July 20, 2020 12:45 AM

Hi Hrvoje,

Please find my answers in-line.

- I remember I red somewhere that it is recommended for in-place migration 11.70 -> 14.10 to go through 12.10 (i.e. 11-70 -> 12.10 -> 14.10)
[Gaurav]: That is correct, even if you do an upgrade from 11.70 to 14.10 it will go through 12.10, but you dont have to do anything, 14.10 binary will do that automatically and make your engine online to 14.10.

- I found a "problem" for dummy update - if you have update trigger on table doing some business (e.g. for auditing purposes), you will end in lots of side job (even bad job). So dummy is not always dummy.
[Gaurav]: In such cases, you should disable your triggers and then try to fix in-place alters.

- And when doing in-place upgrade, sometimes you end with error during sysadmin upgrade. You can rebuild sysadmin but if you have yours tasks, or you are collecting data it would be wise to export sysadmin before upgrade (after stopping scheduler of course)
[Gaurav]: Before you kick off an upgrade, i have suggested 0 level backup. And its up to the DBA what kind of backup they consider.

Regards,
Gaurav

Thu July 16, 2020 06:24 AM

Hi Gaurav, couple of questions

- I remember I red somewhere that it is recommended for in-place migration 11.70 -> 14.10 to go through 12.10 (i.e. 11-70 -> 12.10 -> 14.10)

- I found a "problem" for dummy update - if you have update trigger on table doing some business (e.g. for auditing purposes), you will end in lots of side job (even bad job). So dummy is not always dummy.

- And when doing in-place upgrade, sometimes you end with error during sysadmin upgrade. You can rebuild sysadmin but if you have yours tasks, or you are collecting data it would be wise to export sysadmin before upgrade (after stopping scheduler of course)

As I wrote you I was not able to participate in your webcast so maybe you already said something about these comments.

Regards