Re: v11 upgrade
We've found two caveats in upgrading. One of them should only affect in place upgrades: Ensure that your rootdbs is big enough to hold the new sysadmin stuff, especially if you have lotsa tables / columns with lotsa indexes. Not having sufficient rootdbs space can make for a long day. The second: IDS 11.X is much LESS forgiving when it comes to an under-indexed schema. One of our customers' production instances had been missing an index on a key, very often joined field in a somewhat busy table, and had rolled along fine in 10. Only when they were moved to 11.5 did they have performance problems as a result of the missing index. Perhaps they were having performance problems under 10, but nothing to the extent that they had under 11.5. So do some rootdbs enlarging if necessary, as well as a bit of index analysis, and it should all be good. Those caveats aside, you should expect improved performance and MUCH improved reliability, especially under load. John Fahey On Thu, Oct 15, 2009 at 9:44 AM, Plugge, Joe R. <JRPlugge@west.com> wrote: > -----Original Message----- > From: informix-list-bounces@iiug.org [mailto: > informix-list-bounces@iiug.org] On Behalf Of Tom Lehr > Sent: Thursday, October 15, 2009 8:14 AM > To: informix-list@iiug.org > Subject: v11 upgrade > > hello all > > I am wondering what kind of experiences people are having upgrading to > version 11 - specifically in place upgrades. > we are currently on AIX 5.3 (on a carved out LPAR) running HDR with > version 10.FC9 > > thanks > tom > > -- > > One problem that we had was existing entries in the SYSAGGREGATES table in > each database. It seems that when going from IDS 10.00.FC8 to 11.50.FC4 it > would fail hard and I could not revert, I had to restore. Apparently, 11.50 > "assumes" that the sysaggregates are NOT there and tries to create them, > thus failing. > > This is an example of one of the entries that will trip you up. > > name aggrxml > owner informix > aggid 5 > init_func init_aggrxml > iter_func iter_aggrxml > combine_func comb_aggrxml > final_func final_aggrxml > handlesnulls f > > > My solution was to create Level 0 first, to be safe, drop all entries in > the SYSAGGREGATES tables for each DB in your instance, then do the upgrade. > Of course the usual checks apply as well: Check for no in place alters as > well as make sure that you do not have any open transactions. > > Joe > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- John Fahey President Mitchell & McCormick, Inc. 2165 West Park Ct Suite G Stone Mountain, GA 30087 (770) 465-1511
Thanks so much for the replies! I will be sure to ask many more folks at IOD - especially in relation to our sepcific version we are looking to upgrade Tom
On 21 Oct, 15:12, Tom Lehr <tomc...@gmail.com> wrote: > Thanks so much for the replies! > > I will be sure to ask many more folks at IOD - especially in relation > to our sepcific version we are looking to upgrade > > Tom Well I would consider waiting for some bug fixes before considering using 11.50 in anger depending upon how you intend to use it: As per http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.relnotes.doc/ids_1150xc5/ids_defects_11.50.html IC56775 ARCHECKER RETURNS CRITICAL ERROR: WRONG TAPE NUMBER 1 != 2 USING A RETORE FILTER IC60634 BACKUP OF SBSPACE CAN PLACE INSTANCE IN BLOCKED:ARCHIVE FOR EXCESSIVE TIME EVEN IF SBSPACE IS EMPTY IC61452 SQL FUNCTION MULTISET IN SELECT STATEMENT ASSERT FAILS IN ALLOC_CHANGELOG() OR FREELST_FIND() IC60800 OUTPUT FILE CONTAINING ERRORS FROM VIOLATION TABLE CONVERSION IS OVERWRITTEN WHEN A SUBSEQUENT DATABASE IS CONVERTED IC61534 ENGINE DOES NOT RELEASE OPEN TABLES WHEN PDQ IS ENABLED AND AN UPDATE ON A NON-EXISTENT ROW IS PERFORMED. and a good one... IC59086 [X86] RDTSC BASED TIME MEASUREMENTS CAN BE WRONG ON AMD SYSTEMS Is anyone else waiting on these? Regards, David.