This appendix describes special considerations when upgrading from Ingres 6.4.
Regardless of the upgrade method you are using, you should perform the tasks described in Considerations for Ingres 6.4.
If you are using the unload/reload method to upgrade from Ingres 6.4, follow the instructions in How You Upgrade from Ingres 6.4 Using Unload/Reload.
If you are using the upgradedb method to upgrade from Ingres 6.4, you can follow the procedure in the chapter "Upgrading Using Upgradedb." If you have difficulties with that procedure in your testing, you can use the process described in Alternate Upgradeb Procedure.
This appendix also lists Ingres 6.4 parameters and their corresponding names in newer releases.
|
|
|
There are additional considerations when loading Ingres 6.4 databases and applications into the new development installation. These considerations include application preparation and system preparation.
|
|
|
After successfully creating databases and applications in the new Ingres development installation, you should check for the following additional application issues.
|
|
|
In Ingres 6.4/05 and earlier, the "ambiguous replace" test allowed an update using the UPDATE…FROM statement if each target row was being updated with an unambiguous value. Ingres 6.4/06 and higher releases test for multiple FROM rows and generate an ambiguous replace error message even if all the FROM rows generate the same replacement value.
For example, Ingres 6.4/05 and earlier allowed the following update:
UPDATE table_1
FROM table_2
SET column_3 = 3;
even though there is no WHERE qualification joining the tables, since the replacement value was non-ambiguous. In later releases, an "ambiguous replace" error message displays.
The recommended approach for this semantics change is to review all applications for ambiguous updates and change them to use EXISTS or IN, instead of a join. If this is not feasible, the original UPDATE . . . FROM handling can be restored by setting the DBMS parameter "ambig_replace_64compat" to ON in Configuration-By-Forms.
|
|
|
With the introduction of the DECIMAL data type, fixed-point literals such as 1.0 are now considered DECIMAL, rather than FLOAT.
Typically, this does not matter, as Ingres does appropriate type conversions. However, it is important when doing a CREATE TABLE . . . AS SELECT with a constant in the SELECT result list.
For example:
CREATE TABLE table_1
AS SELECT column_1, column_2, column_3=1.0
FROM table_2;
In Ingres 6.4, the column_3 is created as FLOAT8; in Ingres it is created as a DECIMAL(2,1) column. This may result in overflow in an application.
The recommended approach is to examine uses of fixed-point constant usage in applications and change them to floating point constants, or add an explicit FLOAT8 type conversion.
A less thorough but easier alternative is to set the environment variable II_NUMERIC_LITERAL to FLOAT, as follows:
setenv II_NUMERIC_LITERAL FLOAT
Ingres then interprets fixed-point constants as floats rather than decimals. If you decide to use II_NUMERIC_LITERAL, it will be necessary for every user of the applications to set II_NUMERIC_LITERAL in their environment.
|
|
|
Ingres 6.4 4GL programs are insensitive to length and type errors when returning BYREF values to a calling program. Ingres is more sensitive to return values that are too long or the wrong type. In some cases, this can result in programs aborting and segmentation violations. The cure is to ensure that the called and calling routines return values of compatible length and type.
An as interim fix, an environment variable can be set to cause the 4GL runtime system to pass parameters the way 6.4 did: all integers forced to 4-byte, all floats forced to 8-byte. Character string passing is not affected. The environment variable setting is:
setenv II_PARAM_PASSING FORCEMAX
|
|
|
In Ingres 6.4, if a database was journaled, a newly-created table would not be journaled unless WITH JOURNALING was explicitly stated.
In Ingres, journaling is on by default. This means that if an application creates temporary tables, those tables will be journaled; this may consume more system resource, resulting in Ingres applications running more slowly than expected.
You can turn default journaling off by changing the Configuration-By-Forms parameter "default_journaling." Alternative options are to issue a SET NOJOURNALING statement at the beginning of an application, create temporary tables WITH NOJOURNALING, or use session tables.
|
|
|
Ingres 6.4 ignores a number of arithmetic error conditions (such as floating point overflow and divide-by-zero). Ingres correctly reports arithmetic errors on all platforms. If an application generates arithmetic exceptions when tested with Ingres, it is probable that the application had problems in Ingres 6.4 that were not reported. The application must be corrected.
|
|
|
Conversion of 4GL VARCHAR variables to the TABLE_KEY type gives length errors. Avoid this by converting to char first:
TABLE_KEY(CHAR(varcharVariable))
Some 6.4 releases of 4GL had problems with variables of type TABLE_KEY. If you were doing type conversions to avoid the use of TABLE_KEY variables, consider removing the conversion altogether and using the TABLE_KEY type directly.
|
|
|
If you are using Object Management Extension to declare user-defined data types in the server, be aware of some changes in calling sequences. For details, see the Object Management Extension User Guide.
|
|
|
Many of the changes required for Ingres are backward compatible with Ingres 6.4. Make application changes in the Ingres 6.4 installation, and bring them forward to the Ingres installation for testing. In this way, you do not have to freeze application development while preparing for Ingres.
At this stage, resist the temptation to make Ingres-specific application changes. While an outer join or a session temp table may enhance performance, there is plenty of time to add performance enhancements after the upgrade.
|
|
|
Take the following steps to prepare your system:
|
|
|
Ingres uses new commands for startup and shutdown: ingstart and ingstop instead of iistartup and iishutdown. If you have customized shell scripts that start and stop Ingres, you must change them. Verify the changes in the development Ingres installation and have the revised scripts ready for the production environment at time of upgrade.
If you are running multiple DBMS servers with Ingres 6.4, you should be able to simplify your startup and shutdown procedures. Ingres supports multiple DBMS servers directly from the Ingres configuration.
|
|
|
In Ingres, the ingprenv command replaces the Ingres 6.4 ingprenv1 command, which displayed one Ingres environmental variable. Shell scripts that use ingprenv1 must be changed.
It is possible to recreate ingprenv1 as follows:
echo 'exec $II_SYSTEM/ingres/bin/ingprenv $*' >/usr/local/bin/ingprenv1
chmod +x /usr/local/bin/ingprenv1
|
|
|
Ingres has a sample Archiver exit script, acpexit.def. If the Ingres 6.4 acpexit script was customized, you must carry over these changes to the Ingres installation.
For information about the acpexit script, see the System Administrator Guide.
|
|
|
Generally, Ingres uses less transaction log file space than Ingres 6.4. A few operations may use more (for example, MODIFY TO MERGE). To allow for its improved logging algorithms, Ingres reserves transaction log space that it may not actually write.
The force-abort limit cannot be set as close to log-full as was possible in Ingres 6.4.
If your Ingres 6.4 transaction log was barely large enough, it may be advisable to increase the size before or during the upgrade.