Question How complex is an Ingress upgrade from 2.0 to 2.6.
Answer Hello,
It depend on the database volume, age, state, how machine do you have, etc. etc. Usualy it is a quiet simple and straight forward process.
The best way is to have 2 machines or at leat Ingres installed with both versions. The migration guide talk about 2 ways : unload/reload method and upgradedb method. Personnaly I prefer the first one.
What you need to prepare on the new installation is :
- create the appropriate locations
- create the appropriate users (extract them from Ingres 2.0 via accessdb and use the "SQL Script" menu in the Users frame)
Before exporting your data it is preferable to reorganize them (modify all tables). Delete all report, ABF or OpenROAD applications (there is an other way to migrate them). Use the "-c" option with unloaddb (ASCII format), it is better to transport data from an OS to an other (even if they are of the same flavour).
You can find all relevant informations in the migration guide. See this link : http://docs.ingres.com/mg/ or the same guide in PDF version (it come with Ingres 2006 on Windows or you can download the documentation separately). I have worked many years at Computer Associates (the old owner of Ingres) and I ensure you this book is a very good migration cookbook (and at least his first name was "migration cookbook" :-))
Usualy there is nothing else to do. The major issues I have met on customer sites are :
- II_DATE_FORMAT, II_DECIMAL, (and so on) must be set to the same values on both Ingres install
- sometimes some data are not loadable(usualy because they are already corrupted in the source database). Try to recreate the table in the old environment, or modify the table to heap via MODIFY or verifydb ...
- sometimes SQL sentences for views or database procedure creation are not correctly cut by copydb or unloaddb (it is an old bug, particulary if you use comma for something else than a list of columns in the SQL) : you need to correct them manualy (ie to re arange the word of the SQL sentence)
- Take care of the customised files you can have in the old installation (Ingres environment [symbol.tbl content], termcap, *.opt & *.def files, etc)
- Take care of the ingres library (from an Ingres version to an other, or an OS version to an other some stuff can change)
- Read carefully the readme file of your target version. Sometimes it can contain relevant information (usualy about system configuration. For example Solaris kernel parameter must be tunned before installing Ingres [shmmax]).
If you have applications to migrate (ABF, OpenROAD, Report Writer), export them from the old database and import them in the new one. Migrating application directly with system catalogs is not supported (I think) and at least it often cause issues that are difficult to deal with (frame no more accessible, strange application behavior on compilation and/or run, etc). It is at least a good thing to regulary export thoses particular data to text files ... (just to have a backup or reload them on a new machine for example)
If your company (or your customer) provide particular restore service to their users via checkpoint, keep somewhere in the company a copy of Ingres 2.0. Checkpoints are very sensitive to new versions so if you want to restore data from an old version to Ingres 2006 you must issue the rollforwarddb in the old environment and then use unloaddb to transport thoses data.
Then I have a question for you : why not migrate directly to Ingres2006 ? Personnaly I have already done some migration from Ingres 6.4 to Ingres2006 without problem ... and Ingres2006 can be free of charge (the community edition).
Hope this reply to your question and my english is clear (it is not my mother tongue :-).
