Upgrade to IDS 10.00.UC*
RedHat AS 3, running IDS 9.40.UC2, 9GB RAM, 4cpus
Installed IDS 10.00.UC3 (most current) and tried to upgrade a copy of a
production db. Followed the suggestions in the Migration manual (after the
upgrade failed once) and brought the system up with 10. Stopped the instance
under 9.4, did the "onmode -c", "ontape -a" and "onmode -yuk". Switched
$INFORMIXDIR and used "oninit".
Online.log seems to show everything upgraded ok; no errors or failures.
When I started a copy of our production apps, db AF'd and shut down,
complaining that:
12:44:29 Conv/rev: Failed to convert component SQL to component version 26
12:44:29 Conversion failed for component SQL : entity_ver 26 != target version
29
12:44:29 Assert Failed: Conv/rev: Failed to convert for component SQL
12:44:29 IBM Informix Dynamic Server Version 10.00.UC3
12:44:29 Who: Session(30, root@resbetrn, 0, 0x8ff18c18)
Thread(39, convert, 8feeff20, 1)
File: framework.c Line: 668
12:44:29 Results: Dynamic Server must abort
12:44:29 Action: Restart conversion after fixing the problem.
I then tried to do "update statistics" for the entire database (which failed)
and now I cannot even connect to our db, receiving the following errors:
311: Cannot open system catalog (sysdirectives).
102: ISAM error: illegal argument to ISAM function.
It appears that no 'sysdirectives' table was ever built. Has anyone else run
into this? Are there *mandatory* steps required in order to upgrade to 10 from
9.40?
Bob
Bob,
First of all, the 'previous IDS' shutdown process should be:
onmode -kuy
oninit -s
onmode -c
onmode -kuy;
...Then, start the new IDS version.
Also, 'update statistics for procedure' is required after the upgrade.
-Alexey
> -----Original Message-----
> From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf
> Of Bob Roussey
>
> RedHat AS 3, running IDS 9.40.UC2, 9GB RAM, 4cpus
>
> Installed IDS 10.00.UC3 (most current) and tried to upgrade a copy
of a
> production db. Followed the suggestions in the Migration manual
(after the
> upgrade failed once) and brought the system up with 10. Stopped the
instance
> under 9.4, did the "onmode -c", "ontape -a" and "onmode -yuk".
Switched
> $INFORMIXDIR and used "oninit".
>
> Online.log seems to show everything upgraded ok; no errors or
failures.
> When I started a copy of our production apps, db AF'd and shut down,
> complaining that:
>
> 12:44:29 Conv/rev: Failed to convert component SQL to component
version 26
> 12:44:29 Conversion failed for component SQL : entity_ver 26 !=
target
> version
> 29
> 12:44:29 Assert Failed: Conv/rev: Failed to convert for component SQL
> 12:44:29 IBM Informix Dynamic Server Version 10.00.UC3
> 12:44:29 Who: Session(30, root@resbetrn, 0, 0x8ff18c18)
> Thread(39, convert, 8feeff20, 1)
> File: framework.c Line: 668
> 12:44:29 Results: Dynamic Server must abort
> 12:44:29 Action: Restart conversion after fixing the problem.
>
>
> I then tried to do "update statistics" for the entire database
(which
> failed) and now I cannot even connect to our db, receiving the
following
> errors:
>
> 311: Cannot open system catalog (sysdirectives).
> 102: ISAM error: illegal argument to ISAM function.>
> It appears that no 'sysdirectives' table was ever built. Has anyone
else
> run into this? Are there *mandatory* steps required in order to
upgrade to 10
> from 9.40?
>
> Bob
The mystery is apparently solved. In my previous attempts, the upgrade process appeared to have ended with the db in 'Single-User' mode. I then tried to take it to multi-user mode, then shut it down and things just went downhill quickly. Another attempt was made this week after opening a case with IFX. Went through all the extra steps of doing full 'onchecks', full archive and archiving the last TX log. Shut it down and brought it up under 10.00.UC3. I watched the online.log and saw it converting the system catalogs as usual and then stop again in 'single-user' mode, without seeing the 'Conversion completed successfully' message indicated in the Migration manual. I called the IFX tech and told him that the same thing happened and I have the system sitting in that state. When he got back with me and we looked at the online.log again, it showed that the process had 'stopped' for almost 20 minutes, then started going again to completion! He could not explain the reason for the system just sitting, (apparently) doing nothing (no cpu activity, no disk activity) for 18 minutes. It might be a Linux quirk or specific to our db; don't know. Anyone else see this in a 10 upgrade? Bob