Infx 5 to 7.2 - Problems ?
A user asked what pitfalls to expect when migrating OnLine 5 (with I4GL 4.16 and hundreds of 4GL programs) to Informix 7.2, while simultaneously moving from SCO 5 to UnixWare. Advice given: don't change everything at once; research prior postings; consider going straight to 7.31UC2; drop indexes under 5.x and rebuild them in parallel after upgrading (the upgrade rebuilds them single-threaded); take all recommended archives; allow at least 60MB in rootdbs for sysmaster/sysutils. Also: recompile ALL programs and set DBCENTURY. On RAID-5, Art Kagel noted the main short-term issue is up to a 50% write performance penalty versus mirroring/RAID-10. No single "fix" — it's collected migration guidance.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi , we're upgrading our Informix On-Line system from 5 to 7.2. Can anyone point out any pitfalls that we may encounter ? We run hundreds of 4ges on hundreds of tables, we will of course be re-compiling all programs in batch. Incidentally the the OS is being upgraded from SCO 5 to UnixWare at the same time.
Robert Taylor wrote: > Hi , we're upgrading our Informix On-Line system from 5 to 7.2. Can > anyone point out any pitfalls that we may encounter ? > > We run hundreds of 4ges on hundreds of tables, we will of course be > re-compiling all programs in batch. Incidentally the the OS is being > upgraded from SCO 5 to UnixWare at the same time. Which version of I4GL are you migrating from? If it is 4.10, you will have a very different set of issues from if it is 4.20. I strongly counsel going to DejaNews (OK, deja.com) and doing some research on the postings on this subject in this news group. One comment; changing everything at once is going to be more exciting than changing just one product at a time. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>
i4gl is 4.16. Mores exciting probably means mores stress. But I guess thats what we're in it for. Jonathan Leffler <jleffler@earthlink.net> wrote in message news:379C403D.50B9@earthlink.net... > Robert Taylor wrote: > > Hi , we're upgrading our Informix On-Line system from 5 to 7.2. Can > > anyone point out any pitfalls that we may encounter ? > > > > We run hundreds of 4ges on hundreds of tables, we will of course be > > re-compiling all programs in batch. Incidentally the the OS is being > > upgraded from SCO 5 to UnixWare at the same time. > > Which version of I4GL are you migrating from? If it is 4.10, you will > have a very different set of issues from if it is 4.20. > > I strongly counsel going to DejaNews (OK, deja.com) and doing some > research on the postings on this subject in this news group. > > One comment; changing everything at once is going to be more exciting > than changing just one product at a time. > > -- > Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) > Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN > #include <disclaimer.h> >
Robert Taylor wrote: > > Hi , we're upgrading our Informix On-Line system from 5 to 7.2. Can anyone > point out any pitfalls that we may encounter ? > > We run hundreds of 4ges on hundreds of tables, we will of course be > re-compiling all programs in batch. Incidentally the the OS is being > upgraded from SCO 5 to UnixWare at the same time. I say go straight to 7.31UC2 or later. The upgrade from 5 to 7 will have to rebuild all indexes single threaded so you are better off dropping all indexed under 5.xx and recreating them in parallel under 7.xx manually after a successful upgrade. Do not skip any of the recommended archives (take the 5.xx archive before dropping any indexes). Make sure you have at least 60MB for the rootdbs before beginning the upgrade to leave room for the sysutils and sysmaster databases. Art S. Kagel
In article <7nhea2$e29$1@uranium.btinternet.com>, "Robert Taylor" <robertt@scotlegal.com> wrote: > Hi , we're upgrading our Informix On-Line system from 5 to 7.2. Can anyone > point out any pitfalls that we may encounter ? > > We run hundreds of 4ges on hundreds of tables, we will of course be > re-compiling all programs in batch. Incidentally the the OS is being > upgraded from SCO 5 to UnixWare at the same time. > > We too have recently upgraded from OnLine 5.01 to IDS 7.30 and have 200- 300 I4GL programs and numerous Ace reports supporting our third-party OLTP application. We are into our second (very long!!) week and are getting there, albeit slowly. We took the opportunity to accurately size initial extents for the main tables(we have the advantage of "knowing" our system pretty well). We positioned the chunks with an eye to performance. We separated out the indexes. We avoided RAID-5 (thanks Art for all your info!!). We specified a machine with a decent spec (for our needs). We upgraded from SVR4 to SCO OpenServer 5.0.4. In essence, if it could be changed, we changed it. Virtually all of the above was for Y2K / performance reasons. 10 days later, the box is absolutely flying !! The only database problems we have encountered were as a result of not recompiling ALL programs - something we very swiftly rectified. The other STUPID problem hit us yesterday when we sussed out we hadn't set $DBCENTURY (yes, yes, basic stuff, I know, but after a 12-day stint we were somewhat lagging!). Other than the above, the main problem reported by our OLTP users (seriously!) is that the system is too fast for them ! The odd, well-placed UNIX "sleep" command will doubtless pay dividends later when the box gets more heavily loaded and we can instantly remove them aka. "I'll just press the TURBO (sic) button for you, Sir!). Regards Glyn Balmer BICC General UK Cables Limited -- If it always works, why don't parachutists pull the emergency 'chute first? Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.
In article <379C403D.50B9@earthlink.net>, jleffler@earthlink.net wrote: > Robert Taylor wrote: > > Hi , we're upgrading our Informix On-Line system from 5 to 7.2. Can > > anyone point out any pitfalls that we may encounter ? > > > > We run hundreds of 4ges on hundreds of tables, we will of course be > > re-compiling all programs in batch. Incidentally the the OS is being > > upgraded from SCO 5 to UnixWare at the same time. > > Which version of I4GL are you migrating from? If it is 4.10, you will > have a very different set of issues from if it is 4.20. > > I strongly counsel going to DejaNews (OK, deja.com) and doing some > research on the postings on this subject in this news group. > > One comment; changing everything at once is going to be more exciting ^^^^^^^^ This must be a new meaning of the word "exciting" I have yet to meet ! (But I agree 100% having just changed platform, engine, application and UNIX version in one hit!) - Dull it ain't ! > than changing just one product at a time. > > -- > Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) > Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN > #include <disclaimer.h> > > Regards Glyn Balmer BICC General UK Cables Limited -- If it always works, why don't parachutists pull the emergency 'chute first? Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.
We took the opportunity to accurately size initial extents for the main tables(we have the advantage of "knowing" our system pretty well). We positioned the chunks with an >eye to performance. We separated out the indexes. We avoided RAID-5 >(thanks Art for all your info!!). I work with robert who sent this original post on the upgrade. We are fortunate to have a server of similar spec to our production one which we can use for testing an upgrade. This also means we dont need to bother about initial extents as we can get this info from a schema after the import of the db into IDS 7.1. We run RAID 5 at present and have decided not to change this for the time being. This may be a bad idea but at least we have some protection against disk failure. I would like to just get the system up and running first before moving away from RAID 5. I also require another RAID controller as I think my system has i/o bottlenecks and more disks so that I can use mirroring. Will RAID 5 give me any problems apart from the fact that i/o threads will not work to our advantage ? >.
Tam McLaughlin wrote: > > We took the opportunity to accurately size initial extents for the main > tables(we have the advantage of "knowing" our system pretty well). We > positioned the chunks with an > >eye to performance. We separated out the indexes. We avoided RAID-5 > >(thanks Art for all your info!!). > > I work with robert who sent this original post on the upgrade. We are > fortunate to > have a server of similar spec to our production one which we can use for > testing > an upgrade. This also means we dont need to bother about initial extents as > we > can get this info from a schema after the import of the db into IDS 7.1. > We run RAID 5 at present and have decided not to change this for the time > being. > This may be a bad idea but at least we have some protection against disk > failure. > I would like to just get the system up and running first before moving away > from > RAID 5. I also require another RAID controller as I think my system has i/o > bottlenecks > and more disks so that I can use mirroring. Will RAID 5 give me any problems > apart > from the fact that i/o threads will not work to our advantage ? For the full RAID5 rant you will have to look in the IIUG archives. For this specific discussion, for a short term solution the biggest safety issue with RAID5 is unlikely to bite you if you use new drives so that leaves the write performance bottleneck. RAID5 takes a performance hit up to 50% on writes over mirrored drives or RAID10. Art S. Kagel