Ingres® 2006 - Migration Guide

Peter Kitson

ISBN : -

Order a printed copy of this book from Amazon --UNAVAILABLE--

Cover Design - Ingres® 2006 - Migration Guide

For your free electronic copy of this book please verify the numbers below.

(We need to do this to make sure you're a person and not a malicious script)

Sample Chapter From Ingres® 2006 - Migration Guide
Copyright © Ingres Corporation

Chapter 1: Planning the Upgrade

This guide, when used with the other guides in the Ingres documentation set, will assist in the planning and execution of a successful upgrade of Ingres. This guide also describes the new features for past Ingres releases, so that after the upgrade is complete and running successfully for several days, you can begin using these new features.

This chapter describes how to plan for the upgrade, methods of upgrading, considerations for specific Ingres releases, required installations and hardware when upgrading, overall strategy for the upgrade, and application issues.

The Upgrade Plan

The key to a successful upgrade is to prepare a detailed plan. A detailed plan can prevent problems when upgrading. The plan should include items such as how long it will take to complete a backup and how to verify that the data is complete and secure.

The plan should then be tested, preferably with a copy of the production system data. Testing reveals areas that may cause problems during the upgrade of the production system.

You should then implement the plan, but only after preliminary testing is complete.

The best strategy for upgrading is to first implement any compatibility fixes in the current environment. When the databases and applications are ready, test them in that environment, practice the upgrade, and then perform the upgrade.

Do not use any new features until the upgrade is successfully implemented. Doing so keeps to a minimum the number of variables at each step.

Upgrade Types

There are two options for upgrading your production systems:

The upgradedb utility
The unload/reload method

You can mix the two upgrade types, upgrading some databases while reloading others.

Upgradedb Method

The upgradedb utility allows for a fast, in-place upgrade path for an older version Ingres database, with no additional disk space requirements. Because upgradedb is faster, it is typically the recommended way of upgrading. Preparing for a safe and reliable upgradedb, however, can take time, especially when upgrading from Ingres 6.4.

Databases using the system-maintained logical key feature are best upgraded using upgradedb. Tables that contain SYSTEM_MAINTAINED table_key or object_key columns cannot be safely unloaded and reloaded without additional work. The reload step generates all new logical key values. If there are other tables referencing the logical key columns, the new values must somehow be manually propagated to those other tables.

Unload/Reload Method

The database unload/reload method ensures a clean start with a fresh database. Depending on the kind of table data, additional disk space may be needed to perform the unloading and reloading; the space could be as large as three to five times the space of the database that is to be upgraded. For example, compressed tables with wide char or varchar columns can expand substantially when unloaded.

The unload/reload process takes longer than upgradedb, thus increasing the downtime of the production system. However, it ensures a clean final installation.

A database that has been running for years, perhaps surviving a number of system crashes and hardware failures, may have suffered hidden damage that can confuse the upgradedb utility. For example, a database that is used by a small department or group of people may not be maintained as well as a production database. Such a database may have work tables owned by a user who no longer exists, or may be missing table data files. An unload/reload upgrade may be a better choice for this database.

The typical unload/reload upgrade uses the original Ingres installation as a base. The system databases iidbdb and imadb are upgraded in-place with upgradedb, even if user databases are unloaded/reloaded. A variation of the unload/reload method uses a brand new installation (perhaps even on a different machine). When this is done, additional work is needed to transfer iidbdb information (users, groups, roles, and database and installation privileges) to the new installation.

Upgrade Method and Ingres Releases

The release of Ingres that you are upgrading from can affect the type of upgrade you choose.

From Releases Prior to Ingres 6.4
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.

From Ingres 6.4
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 (see page 82).

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 (see page 77).

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 (see page 94).

From Releases Newer than Ingres 6.4

When upgrading from OpenIngres 1.2 or 2.0, Ingres II 2.0 or 2.5, or Ingres 2.6, use 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.

From a 32-bit to a 64-bit Release

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:

Redefines the standard catalog views (iitables, iicolumns, and so on)
Generates an SQL script to drop and redefine views, rules, integrities, and QUEL permits
Executes the SQL script

The generated SQL scripts, and the SQL output, can be found in the directory /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 /ingres/files/upgradedb to determine the point of failure. If necessary, contact customer support for assistance.