Is there recovery from this?

I upgraded Informix IDS from 7.24.UC7 to 7.31.UD6 over the weekend, and = everything was fine with our production instance, but I couldn't get our = Test instance back. It seems like someone (me) forgot to shut down that instance before = upgrading....I got errors complaining about shared memory, so I figured = I'd free it up by rebooting....That didn't work. =20 Since it was only a Test instance that I planned to do a dbimport on = anyway, I just recreated all the dbspaces, but I was wondering if there = was anything else I could have done (short of calling Informix and = hoping they could salvage it). Can anyone confirm that upgrading while an instance is up should have = this effect? (This was the same instance my dbexport was 'hanging' on that I asked = about a few weeks ago - I never resolved that, but I never had trouble = bringing it online). BTW, nobody was in that instance when the upgrade was done. Thanks, Danny Wright Below is output from the online log when I attempted to bring it up. 11:01:39 Event alarms enabled. ALARMPROG =3D '/informix/etc/no_log.sh' = 11:01:44 DR: DRAUTO is 0 (Off)=20 11:01:44 AIX MP latch code enabled=20 11:01:44 Requested shared memory segment size rounded from 2132KB to = 2144KB=20 11:01:44 Informix Dynamic Server Version 7.31.UD6 Software Serial = Number ...... 11:01:45=20 11:01:45 (5) connection rejected - no calls allowed for sqlexec=20 11:01:45 listener-thread: err =3D -27002: oserr =3D 0: errstr =3D : No = connections are allowed in Dynamic Server quiescent mode. =20 11:01:45 Informix Dynamic Server Initialized -- Shared Memory = Initialized.=20 11:01:45 Physical Recovery Started.=20 11:01:45 Physical Recovery Complete: 0 Pages Restored.=20 11:01:45 Logical Recovery Started.=20 11:01:45 Open transaction detected when changing log versions.=20 11:01:46 Cannot Rollforward from Checkpoint.=20

Hi, I cannot "confirm that upgrading while instance is up should have this effect". But if you think about the effect of such actions it will become more clear why such an effect is plausible ... : So far there's no special check in the installation script that would detect a running instance (that was started from the installation to be upgraded), because this itself is not trivial (there was internal discussion about this recently, but I don't know the result yet). It is still assumed that only the administrator does upgrades of the installation and that he knows what he's doing ... :) Anyway, therefore when you do the upgrade, it means that binary executables are copied onto the disk to the same location where there is/was already one. If from this installation an instance was started and is still running, then the system has a (potentially partial) copy of the binary executable in memory for current execution. At any time may the system (UNIX kernel) decide to load something from this binary executable (on disk) into memory for execution. The same applies for shared libs ... Due to the upgrade activity, the original binary on disk is gone and there's now something different (the new binary). So you can easily imagine that at this point the kernel and your running binary executable will get into trouble ... The effect is different, depending on platforms. E.g. on Solaris the running binary is generally known to crash in some unspecified way. On HP-UX the installation will get an error because the OS detected that a binary is running in memory and will prevent overwriting the corresponding binary on disk. In your case (according to online.log excerpt) it looks like the running binary managed to write some log record in the new format before it (finally) crashed. Don't ask me how this was possible - I don't know, but as I tried to explain above, the effects can be non-deterministic (at least from my perspective as application programmer) ... So this is a bad situation for the fast recovery, when it expects old format log records and suddenly there are new format log records, and that switch happened in the middle of an open transaction. This is (obviously) not accounted for (and does not happen when the system is brought down before upgrade). With that I don't think that there would have been a way to bring the system back up without the help of IBM Informix Support. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich Data Management Solutions "Danny Wright" <dwright@sherwoodfoods.com> Sent by: forum.subscriber@iiug.org 30.09.2003 02:14 To: ids@iiug.org cc: Subject: Is there recovery from this? [1953] I upgraded Informix IDS from 7.24.UC7 to 7.31.UD6 over the weekend, and = everything was fine with our production instance, but I couldn't get our = Test instance back. It seems like someone (me) forgot to shut down that instance before = upgrading....I got errors complaining about shared memory, so I figured = I'd free it up by rebooting....That didn't work. =20 Since it was only a Test instance that I planned to do a dbimport on = anyway, I just recreated all the dbspaces, but I was wondering if there = was anything else I could have done (short of calling Informix and = hoping they could salvage it). Can anyone confirm that upgrading while an instance is up should have = this effect? (This was the same instance my dbexport was 'hanging' on that I asked = about a few weeks ago - I never resolved that, but I never had trouble = bringing it online). BTW, nobody was in that instance when the upgrade was done. Thanks, Danny Wright Below is output from the online log when I attempted to bring it up. 11:01:39 Event alarms enabled. ALARMPROG =3D '/informix/etc/no_log.sh' = 11:01:44 DR: DRAUTO is 0 (Off)=20 11:01:44 AIX MP latch code enabled=20 11:01:44 Requested shared memory segment size rounded from 2132KB to = 2144KB=20 11:01:44 Informix Dynamic Server Version 7.31.UD6 Software Serial = Number ...... 11:01:45=20 11:01:45 (5) connection rejected - no calls allowed for sqlexec=20 11:01:45 listener-thread: err =3D -27002: oserr =3D 0: errstr =3D : No = connections are allowed in Dynamic Server quiescent mode. =20 11:01:45 Informix Dynamic Server Initialized -- Shared Memory = Initialized.=20 11:01:45 Physical Recovery Started.=20 11:01:45 Physical Recovery Complete: 0 Pages Restored.=20 11:01:45 Logical Recovery Started.=20 11:01:45 Open transaction detected when changing log versions.=20 11:01:46 Cannot Rollforward from Checkpoint.=20