On May 9, 19:33, Jianchun Zhang wrote: > Is there anybody out there who have experienced the upgrading > Ingres 6.4 to OpenIngres/1.2? we've tried 6.4 to 1.1. We don't have the 1.2 ckpdb patch here yet so I haven't tried 1.2. > .. > ...And also some error occurs > when we do transactions on some tables (eg update, insert). A > typical one is "E_RD0146, Consistency check -- invalid tree version". The safe answer here is to drop all grants, views, permits, db procedures, rules, etc -- drop everything except data tables. Do the upgrade, then reapply all views, etc etc. This is a somewhat stronger statement than necessary, but I think it's the easiest. (I think it's actually group and role permits that cause the problems.) I think there may be some stuff related to 6.4 --> OI upgrading in the FAQ, or would be if Roy would quit doing that mercenary money making stuff, and get down to some real work :-) :-) -- Karl Schendel Phone: (412) 963-8844 Telesis Computer Corp Fax: (412) 963-1373 wiz@telesis.com jzhang@nqnvs46.bnr.ca (Jianchun Zhang) wrote: >Is there anybody out there who have experienced the upgrading >Ingres 6.4 to OpenIngres/1.2? >We have the Ingres 6.4 running on Sparc (kernel sun4m) with >SunOS 5.5 currently. And we are ready to upgrade to OpenIngres/1.2. >I know that there are some problems during the upgrading. For >example, a lot of reserved words are introduced into 1.2. >Therefore, we need to change the schema. And also some error occurs >when we do transactions on some tables (eg update, insert). A >typical one is "E_RD0146, Consistency check -- invalid tree version". >Ok, my question is that what is the best way to upgrade from 6.4 to >1.2. The choices are, you can do it based on 6.4 without touching >the current system, Or you can completely wipe out the 6.4 and >install 1.2, then bring back the database. Other choices? And >what is your suggestion to do the upgrading? >Send mails to jzhang@nt.com or post it on the group. >Thanks! >Jianchun >Nortel, Ottawa >Canada The first thing to do when planning this type of upgrade is Don't panic. It is not as much of a big deal as it is made out to be. I can't get my hands on 1.2 yet because we are a VMS site(never mind the sarcasm, I didn't pick it) but I migrated a 6.4/05p database up to 1.1 without any major difficulties. I would advise you to create a 1.2 database using the unload script from your 6.4 database removing the $ingres tables and just running your DBA scripts. You can do a sysmod after you get the data loaded to freshen up the Ingres tables. Do the unload with -c to make the data go ASCII. Print the results of the reload to a file, and then go in afterwards and see which if any tables gave you reload problems. If you are lucky the new keywords won't even burn you, and you will just have to recompile the application. The worst case scenario is that you might have to change a couple of column names and massage the data. Remember that the best way to do this type of thing is to get your hands dirty. You can read all the articles you want but when it comes down to it your upgrade will have its own particular quirks to overcome. Don't be afraid to give Tech Support a workout. They have been pretty good the last 6 months or so. Michael Greene Database Administrator Bowater Mersey Paper Co. Ltd Liverpool, NS Canada On Thu, 25 Jul 1996, MDKale wrote: > I am working on a site who is migrating to OI 1.1 on an Alpha platform. > We plan to run our ABF applications client/server on VMS machines where > the applications are compiled in 6.4/05/02. > > We are very interested in any sites which have made this kind of > migration. What things worked, what did not? > > So far, we have not gotten roles to work which may be a show-stopper. We > always get the error that role_name/pw is wrong regardless if a password > is used or not. I'm sure more obstacles await. > > Please Email or post any experiences which may help us, or convince us not > to perform the migration. > > Mark Kale mdkale@aol.com > York & Associates, Inc. > (V) 612-831-0077 > (F) 612-831-0887 Mark, We have migrated from 6.2/03 and 6.4/04 to OI1.1 and, in addition to the problem you encountered with the roll/pw, we have also found the following problems: 1. Reports written to a file which were single-spaced are now double-spaced. (RW pads each line out with spaces and throws in an extra line of spaces for good measure.) 2. We have experienced some problems with temporary table corruption; we quit using them for now. The role/pw thing was not critical for us so we wound up using groups. There may well be a fix from CA TS on this. We also have OI1.2/00 up but haven't tried the role/pw thing yet. The RW problem still exists except it is inserting an extra newline (actually a space and newline) at the end of each detail line. Others may have other experiences to report. Thank you, Lucky Lucky Leavell Phone: (812) 945-6555 Relational Information Systems, Inc. FAX: (812) 949-9233 4727 Grant Line Road Email: ris@iglou.com (Internet) New Albany, IN 47150-2013 71534,2674 (CompuServe) WWW Home Page: http://www.iglou.com/ris ftp://www.iglou.com/members/ris From: rjm@merkle.baaqmd.gov (Morey, Robert) Subject: Re: Problems/Questions with OI 1.1 in production Date: 26 Jul 1996 19:02:19 -0400 Mark, I vaguely recall that OI does not allow 'pre-stored' passwords but instead requires that the user type in the password each time. Another point is that UPGRADEDB skips roles (as well as groups) and these have to be re-built manually (or separately). Is this an uppercase/lowercase problem? BTW, we have 6.4/04 on HP-UX 9.0; we're currently considering moving to 6.4/06 or OI 1.2 when the next patch comes out late summer/early fall. See ya at Ingres World? 'Luck--Robert ------------------------------------------------------------------------------ - Robert J. Morey, Systems Analyst, Bay Area Air Quality Management District - - San Francrisco, California, rmorey@baaqmd.gov, ideamen@well.com - - Slay a sacred cow today On a clear disk you can seek forever - - Dare to victualize whirled peas. - ------------------------------------------------------------------------------ On May 12, 10:59, Simon Pamplin wrote: > Subject: Upgrading to OpenIngres from 6.4 > > I'm in the unenviable position of having to upgrade from Ingres 6.4 to > OpenIngres 1.2 or possibly 2.0. The problems I'm looking at are - How to > convert a 15GB database with 800 tables and 1000 (yes I did mean 1000) > users with as little (preferrably none) downtime as possible. This system > currently runs 19Hrs a day seven days a week. > > I'm starting to have some weird ideas about how to achieve this and would > appreciate some comments from yourselves. what sort of hardware? what kind of applications? and what sort of weird ideas? If you can pilot your particular applications using OI on a separate machine, i recommend that. (You can run OI and 6.4 on the same machine, too, if you are careful.) Your time constraints are going to be related to how long it takes to reapply storage structures to all tables, twice, and take a full system backup. Your timeline looks like: - reapply storage structures so as to ensure good table structure - full backup - some misc prep work, eg drop views and stats - upgrade (takes about 2.5 hours, a bit less if you practice) - reapply optimizer stats - reapply storage structures you can defer the last storage structure reapply but you dare not skimp on the rest. i've left out a lot of detail and steps that don't take long, eg ckpdb's to turn off journaling (you can fiddle cktmpl.def so that this goes fast), sysmods, etc. one thing we're learning is that if you rely heavily on large compressed tables you might have a problem in OI 1.2. the compression algorithm is very cpu intensive. OI 2.0 gives you a choice and is a LOT easier to admin on SMP machines, but do you really want to wait that long? finally -- if you go with OI 1.2 make sure you get a good patch to 1.2/01. Patch numbers right around 4500 seem good. Patch numbers in the mid 4500s are bad, they have an opf bug. Patch numbers >= 4603 should be good again. The "bad" patches might work for you depending on your app but you have to test your situation (the bug is related to certain query flattening situations and can be worked around by turning flattening off). [Will: try and get the latest patch!] -- Karl Schendel Phone: (412) 963-8844 Telesis Computer Corp Fax: (412) 963-1373 wiz@telesismfg.com From: Karl & Betty SchendelSubject: Re: Upgrade Ingres 6.4/06 to Ingres II At 1:12 PM +0200 10/28/99, =?UNKNOWN?Q?Fr=E9d=E9ric?= Barbier wrote: >Hi, > >Thanks for your information. I already read the Migration Cookbook some time >ago. I really want some *real word* experience of Ingres clients: problems >encountered, pitfalls,... . The Migration Guide is as "real world" as I could make it. It's what I have learned from doing some 50 real world upgrades, mostly to OpenIngres 1.2 but some to OI 2.0 or Ingres II. CA asked me to write it, and they provided a LOT of support and help, but the contents (and the errors!) are 95% mine. One Ingres II specific thing that I would add to the Guide is this: You'll want to run CBF and turn off the Remote Command Server (set its startup count to zero) before upgrading your databases. Otherwise upgradedb is liable to hang attempting to get at the iidbdb. I have not bothered to figure out why, it might (or might not) have something to do with imadb. I'm sure there are some other people on the list who will share their experiences with you as well. Karl R. Schendel, Jr. K/B Computer Associates schendel@kbcomputer.com Ingres and Unix Expertise Past President, North American Ingres Users Association past_president@naiua.org From: JIANHUA WANG Subject: Re: Upgrade Ingres 6.4/06 to Ingres II Some "real word" from our lessons; Drop all indexes which column data type is date and recreate after upgrade, otherwise the upgrade will take long time to modify each record in the index. Drop all views and procedures and recreate after the upgrade. The upgrade can cause base table corrupted if the table has some views or procedures. Run optimizedb after upgrade.
© William Yuan 2000
Email William