How You Prepare Your System

Some upgrade tasks involve system or Ingres administration. Coordinate these changes with the system administrator.

The system administrator should back up the Ingres system and make sure the system can be restored from the backup.

In addition, changes may be required to the following:

• System monitoring shellscripts
• Your customized checkpoint template files
• Shared library search path
• UNIX kernel parameters

System Backup

When upgrading, it is important to have a system backup. If something goes wrong, you will be able to restore from the backup.

Make sure that the system administrator knows how to take a complete system backup and how to restore that backup. Do a trial backup and verify that the backup is readable. This is especially important with tapes: failing tape drives can appear to write tapes without error, but the tapes may not be readable.

The system administrator should ensure that proper backup procedures are being followed. Backups taken as part of an upgrade should be removed from any backup media recycling, and kept in a secure location for a long time.

System Monitoring Shellscripts

Production systems may have tools to provide the system administrator with early warning of Ingres problems. If these tools have been developed in-house, they must be reviewed for compatibility with your new Ingres release.

Check for these items:

• Are there still IO slaves on the UNIX platform? OS-thread architectures such as Windows and Sun Solaris do not use IO slaves.
• Does the tool parse iimonitor, logstat, or lockstat output? The detailed wording and positioning of logstat and lockstat output can change from release to release. Consider using IMA instead.
• If you are upgrading from Ingres 6.4, the log files II_RCP.LOG and II_ACP.LOG are renamed to iircp.log and iiacp.log.
• If your tool parses Ingres 6.4 parameters, you will have to change it. Ingres parameters are held in the files config.dat and protect.dat.
• If you are using a commercial monitoring tool, contact the vendor to see if an upgrade is needed to support Ingres.

If your Ingres monitoring tool uses the Ingres Monitoring Architecture (IMA), it is likely to continue to function with new Ingres versions. IMA is the recommended data source for any Ingres monitoring tool.

Checkpoint Template Changes

The Ingres checkpoint template file, cktmpl.def, may change from release to release. If you have customized your checkpoint template file, you must review and verify your changes with the new Ingres version.

If you are upgrading from Ingres 6.4, or from OpenIngres 1.2, you must redo your template changes. The cktmpl.def file format has been expanded since Ingres 6.4 and is therefore not compatible. The OpenIngres 1.2 template file format is similar to the current one, but additional entries are required. Your old checkpoint template can serve as a guide.

For more information on the format of the checkpoint template file, see the Database Administrator Guide.

Tip: If your checkpoint template was customized to do multiple location checkpoints in parallel, you may be able to remove this customization entirely. Ingres supports parallel checkpoint and rollforwarddb processing directly.

If you are upgrading from an Ingres II release, compare your revised checkpoint template against the one installed with your new Ingres version. You may be able to use your customized template as is, but first check for new or changed entries in the new version.

The Ingres development installation can be used to develop and test the new cktmpl.def.

Checkpoint and Rollforward Changes

Typically, checkpoints and journals are not compatible from one version to the next. After an installation is upgraded, you must assume that all old checkpoints and journal files are no longer usable with the new version of Ingres.

Rollforwarddb no longer supports a -b option. (In Ingres 6.4, the –b option gave a starting time for applying journals.) Rollforwarddb no longer supports the -noblobs option because it makes the table physically inconsistent and unusable.

Shared Library Search Path (UNIX)

On many UNIX platforms, Ingres uses shared libraries. Since there is no default installation directory for Ingres, it is necessary to tell applications and tools where Ingres is installed so that the shared libraries can be found.

Define Shared Library Search Path (UNIX)

To define the Ingres installation shared library search path, use one of the following methods:

• For all users who access any Ingres programs or applications, set the library environment variable (for example, LIBPATH, LD_LIBRARY_PATH, or SHLIB_PATH) to include the Ingres library directory, $II_SYSTEM/ingres/lib.

  Failure to set the library variable will result in an error message:

  ld.so.1:       /ing20/20/ingres/bin/tm: fatal:
  libframe.1.so: open failed: No such file or directory

  You can arrange for this setting ahead of time, while you are still running Ingres 6.4. The 6.4 binaries do not use LD_LIBRARY_PATH.

  The exact name of the environment variable depends on your flavor of UNIX. Most UNIX environments use LD_LIBRARY_PATH; HP-UX uses SHLIB_PATH; AIX versions 3 and 4 use LIBPATH. See the ld(1) or ld.so(1) man page in your operating system documentation.

• Link the Ingres library files to a standard UNIX library directory, such as /usr/lib.

  For example:

  ln -s /ing20/ingres/lib/libframe.1.so /usr/lib

  and repeat for each .so file in the Ingres lib subdirectory.

  This approach does not require application wrappers or user environment changes. The disadvantage is that you have to link (or copy) each Ingres library individually, and check the validity of these links after a subsequent upgrade.

UNIX Kernel Parameters

Review the UNIX kernel parameter settings, particularly the maximum shared memory size.

If upgrading from Ingres 6.4, you may have to increase the size of a shared memory segment because Ingres builds a larger shared memory segment for locking and logging than did Ingres 6.4.

A 100 MB shared memory segment will accommodate most migrated installations. Each platform has its own way of modifying the shared memory limits; discuss this with the system administrator or read the platform-specific information in the Readme file.

If upgrading from a more recent version of Ingres, you probably do not have to change the kernel parameters. It is prudent to configure your new Ingres development installation similar to the production installation, to make sure that no kernel changes are needed.