|
|
|
The release of Ingres that you are upgrading from can affect the type of upgrade you choose.
|
|
|
If you are upgrading from a version of Ingres prior to release 6.4, you must use an unload/reload upgrade. Furthermore, you must install Ingres into a new, fresh installation; the original installation cannot be upgraded in-place.
|
|
|
If you are upgrading from Ingres 6.4, you can use either the upgradedb or the unload/reload method.
Ingres 2006 provides an improved upgradedb utility that allows 6.4 databases to be upgraded with minimal database preparation effort. You can follow the standard upgradedb procedure described in the chapter "Upgrading Using Upgradedb."
Since most 6.4 databases are several years old, you may choose to use an unload/reload upgrade. Keep in mind that an unload/reload upgrade takes substantially more time and resources. If you choose the unload/reload method, follow the procedures in Unload/Reload Procedure for Upgrading from 6.4.
Regardless of the method chosen, however, an upgrade from Ingres 6.4 requires more planning and preparation than upgrades from newer versions, and you must follow the application and system preparation procedures described in Considerations for Ingres 6.4.
An alternative upgradedb procedure that requires extensive preparation, but will result in a successful upgrade under almost any circumstances, is described in Alternate Upgradeb Procedure.
|
|
|
When upgrading from OpenIngres 1.2 or 2.0, Ingres II 2.0 or 2.5, or Ingres 2.6, we recommend the upgradedb method. The upgrade is internally much simpler than the upgrade from 6.4. In addition, there are fewer application-level incompatibilities among newer versions.
An unload/reload upgrade is possible, but is slower and requires more disk space than an upgradedb upgrade.
OpenIngres 1.2: If you are starting with OpenIngres 1.2, any tables having long varchar, long binary, or long spatial data must be unloaded under 1.x and reloaded into Ingres 2.6. The format of the blob extension tables has changed. The remainder of the database can be upgraded with upgradedb; however, it is probably simplest to use a full unload/reload upgrade with any databases containing "long" datatypes.
|
|
|
You can upgrade your 32-bit Ingres database for use with 64-bit Ingres by running the upgradedb utility. The 32-bit to 64-bit database conversion process redefines views, rules, integrities, and QUEL permits. The data in user tables is not affected by the 32-bit to 64-bit upgrade.
The upgradedb program does the following:
The generated SQL scripts, and the SQL output, can be found in the directory $II_SYSTEM/ingres/files/upgradedb/UPGRADEUSER (where UPGRADEUSER is the user who is running the upgradedb program). There will be files DBNAME.i01 (SQL input) and DBNAME.o01 (SQL output). Depending on the specifics of the database, there might also be files DBNAME.g01 (grant inputs) and DBNAME.go01 (grant SQL output), and files DBNAME.r01 (referential constraint input) and DBNAME.ro01 (referential constraint output).
If your database contains an object that cannot be redefined, the upgradedb may fail to redefine all objects. You can use the SQL script and output in $II_SYSTEM/ingres/files/upgradedb to determine the point of failure. If necessary, contact customer support for assistance.
|
|
|
If you are using OpenVMS on Alpha hardware, and are upgrading to the member-aligned version of Ingres (axm.vms) from a non-member-aligned version (axp.vms), you must use unload/reload. Upgradedb is not available due to shifts in table data positions caused by the new alignment. For instructions, see the chapter "Considerations for Alpha OpenVMS."