TOP 10 DO's and Don'ts :Migrating from Ingres 6.4.x to OpenIngres 1.2

DO's and DON'Ts of making the 6.4.x to OpenIngres 1.2.
TOP TEN ITEMS TO KEEP IN MIND.

1)  DO  set up a new file system when installing OpenIngres 1.2 This will
        make for a cleaner install. (Can have multi installations
        setingenv II_INSTALLATION param.) While CA claims that you can upgrade
	an existing installation. I would recommend that you start from scratch.
        This will make sure all front-end catalogs, new exec's, lib's get
        installed correctly. Whenever possible use the same directory names and
	or mount points for data , source, unload dirs. and so forth. (see #7
	this doc) You may need to tune some kernel params, and you will need a
	roll back plan. This gets a bit nasty trying to get back to your
	original setup. When you've installed over your original. Also makes
	chasing down bugs a lot easier.  Once you have the second install up
	and running then migrate your data and apps. This action is also
	prudent when dealing with production apps and data.

2)  DO  Install all patches and bug fixes. Latest patches are available
        from CA direct. http://www.cai.com  The rush to get OpenIngres 1.2 to
        market has left a few holes. (Note: OpenIngres 1.2 for HPUX must
        install patch to work correct.) This will also eliminate the first
        question CA-Ingres tech support asks. (Um... I don't know.. have
        you installed the patch?...)

3)  DO  Install compatability links. When switching platforms or upgrading
        your O/S make sure to install the compatability links. These links are
        usually provided by the O/S vendor. These links will enable OpenIngres
	to find all the Unix Utils and/or lib's that it needs. If you do not
	install these links you get lots of cannot open/find Unix errors.
	(Note: AIX v4.2 (IBM RS6000) must install compatability links
	OpenIngres 1.2 will not run correctly.)

4)  DO  Make back-up copies of config.dat and symbol.tbl file the path is
        -II_INSTALLATION/Ingres/files These files are critical to your old and
	or new installation. Having a good backup before starting is always
	wise.

5)DON'T  -forget to use the -c flag when unloading your databases. The -c
        flag in the unloaddb command dumps data down to the ASCII level.
	Technically this is only required when switching platforms or O/S.
	However, I would recommend that you always use this flag. (Eliminates
	another variable, should you be stuck tracking down a problem on the
	reload)

6)DON'T  - use the unloaddb util. The unloaddb util dumps data, forms,
        reports, app's ect. all at once. However, in migrations like this I
	have found it best to separate the data move from the app move. Call me
	a wimp, but it's easier for me to focus on an application port and then
	data migration. (Kind of a divide and conquer thing.) This is true when
	dealing with large amounts of data or a complex application. Also I
	would recommend this one, two punch when dealing with production data.
	In that, it is unlikely that you will be able to finish a migration
	before the data needs to be refreshed. Therefore having different data
	and application migration scripts becomes paramount.

7)  DO  use the copydb util to move the data. (Note: Don't forget to use
        the -c flag. see #6 this doc.) The copydb util will give you copy.in
	copy.out sql script files. When possible use the same name for unload
	and reload dirs.  If you can use the same mount point and dir names
	when moving to a new platform. (Note: copy.in and copy.out scripts have
	a path hard coded. By using the same path names when possible you don't
	have to edit as much.) You will need to modify these scripts in the
	following ways; change the 'from' dir path.  This is where the data
	will be loaded from. If you have used the same unload and reload path
	names you may not need to change this. Change the 'location'.
        If you have used multi locations make sure all alternates are setup in
        accessdb before you attempt a re-load. I would also recommend that you
	insert a 'drop' command before each create table statement. This will
	allow you to rerun this script without having to destroy the db and
	start over. It also makes sure the new table Scriptures and fields are
	correct.

8) DO modify the log file.  You may need to adjust the transaction log file
	size.  (II_INSTALLATION/Ingres/logs.  In OpenIngres 1.2 this is done
	through the cbf util.  very easy to do.) You may get aborts do to the
	log file filling up.  Over estimate the size of this file during the
	migration.  You can always go back and change it later.  (NOTE: 
	********* WARNING ********* when you set up your new OpenIngres 1.2
	installation make sure and use the same char set between the two
	databases.  ISOxxxxxx if you do not do this you could corrupt data on
	the reload.)

9)  DO  have plenty of tmp disk space. Remember it takes almost two and a
        half times the size of a table to sort and/or rebuild indices. (not
	including log space) Its worth the hassle to get more disk than you
	need.  Disk is cheap when compared to your time, and or the down time
	your company will take.  (Note:  OpenIngres 1.2 defaults jornalling ON. 
	This will become active after you chkpoint for the first time.) When
	you run the reload scripts dump the output to a log file.  use a
	command like sql [dbname] reload.log& this will give you something to
	look at should the reload fail.

10) DO  take your time. You will more that likely have to do this
	migration a couple times before you get it right.  Just plan on it. 
	It's better to take your time than get it wrong.

*************(Source-code) ABF MIGRATION NOTES ********************

Please note the following;

OSQ     - There are a number of newly reserved words and syntax
	changes from 6.4.x to OpenIngres 1.2 (Namely outer-joint statements and
	the use of " " see white pages http://www.cai.com ) Most have to do
	with new SQL standards.  You may wish make a test compile on a few of
	your more complex .osq files.  This might show if your migration is
	going to take longer than you planned on.

FORMS - On a couple occasions I have had a few forms fail on reload
	because of an invalid date field format.  However, the date field
	appeared to be correct to me.  I was under time constraints so I did
	not chase this problem down to a root cause.  I edited the form.txt
	file (reload file) and deleted the field in question.  This allowed the
	form to reload.  Used vifred to re-add the field.

ANSI C - The HPUX v.10 O/S cc does not default to ANSI c
	compliant.  You must pass an -a flag to the cc command.  However, the
	Ingres linker does not pass this flag by default.  Again under a time
	constraint, so I created the obj files from the command line (using the
	-a flag) this tricked the linker into using the newly created obj files
	and the build app went through.  I'm sure H.P and Ingres are working on
	a solution.  I know you can pass link options however, I have not tried
	a solution.

**********************************************************************l
J.Tyler McGraw
Systems West
136 South Main Stree #A300
Salt Lake City UT, 84101
(801)364-7900 V
(801)364-9700 Fax.
tmcgraw@xmission.com  E-Mail.

Tyler McGraw is an Ingres consultant. Current Utah Ingres Users Group
Pres.and all-around nice guy. (ha ha ha ).

Ingres Database Reference

To William's Home Page

© William Yuan 2000

Email William