Ingres 6.4 -> OpenIngres upgrade

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 Schendel 
Subject: 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.
Ingres Q & A
To William's Home Page

© William Yuan 2000

Email William