Installation Locations

The values for the following Vector variables are established at the time of installation:

Some of these values can be easily changed, and some require unloading of the installation.

Before changing an existing installation location, be sure that the change is necessary: ask yourself what needs to be moved, and why.

• The installation needs space for future growth.

• Existing databases are outgrowing their present disk partitions.

Vector provides the capability of creating new locations and placing any new databases, tables, or indexes in these new locations. If the requirement is space for new tables or databases, you do not need to change existing locations.

Instead, create the necessary new locations for these future tables and databases and use the available location flags of createdb (-d, -c, -j, -b, and -w) to create the data, checkpoint, journal, dump, and work files for the newly created database in some other location.

For more information on creating new databases, see the createdb command in the Command Reference.

Location Variables that Do and Do Not Require Unloading (Linux and Windows)

When you need to change the value of an installation location variable, the procedure depends to some extent on the underlying operating system. On Linux and Windows, the procedure also depends on whether the change requires unloading the database.

You can change the ING_ABFDIR location value without unloading the installation.

The values of the following locations are stored in the configuration file “aaaaaaaa.cnf” of each database at the time it is created and can only be changed by unloading each database, re-installing Vector and reloading the databases (thus creating a new configuration file):

Note: Application developers who do not want to use the installation default can redefine ING_ABFDIR in their local user environment.

Follow these steps to change the value of II_SYSTEM, II_DATABASE, II_CHECKPOINT, II_JOURNAL, II_DUMP or II_WORK. "II_SYSTEM" is used as the example location to be changed:

1. Unload each database. For details, see the unloaddb command in the User Guide.

2. Remove the old installation files by removing everything under the old %II_SYSTEM%\Vector directory and any extended locations.

• Reload each database by appropriately editing and running the reload script.

5. Once you have reinstalled Vector and recreated the databases in the new location, take new checkpoints of each of the databases. Checkpoints taken in old locations are no longer valid. For details, see the User Guide.

Follow these steps in Linux to change the value of II_SYSTEM, II_DATABASE, II_CHECKPOINT, II_JOURNAL II_DUMP, or II_WORK. “II_SYSTEM” is used as the example location being changed:

1. Unload each database. For details, see the unloaddb command in the User Guide.

2. Remove the old installation files by removing everything under the old II_SYSTEM/ingres directory and any extended locations.

3. Set the value of II_SYSTEM and PATH to the desired new values, just as if you were installing Vector for the first time.

Follow the instructions in the Getting Started guide for a new (not upgrade) installation.

As part of the installation procedure, the program prompts you for the new values of Vector location variables II_DATABASE, II_CHECKPOINT, II_JOURNAL, II_DUMP, and II_WORK.

Reload each database by appropriately editing and running the reload.ing script.

6. Once you have reinstalled Vector and recreated the databases in the new location, take new checkpoints of each of the databases. Checkpoints taken in old locations are no longer valid. For details, see the User Guide.

Vector does not support or recommend the use of symbolic links to change locations in Linux. (This is possible with the Linux ln command, which allows the Linux system administrator to create symbolic links to new directories so that files are found in another directory even though the values of Vector installation location variables remain unchanged.)

Common problems that arise from the misuse of symbolic links are as follows:

• Any files to which Vector writes must reside on a file system that is local to the machine on which the writing process is running. This is necessary because of the operating system’s inability to guarantee network writes. If symbolic links are used, writable directories can mistakenly be mounted from remote machines. This can cause write errors and data corruption.

• Occasionally Vector executables reside on NFS file systems that have been exported with the nosuid option. The permissions appear normal when the ls -l command is issued, but setuid programs fails with permission errors.

The rm command does not remove files that are symbolic links. Instead, the symbolic link itself is broken, but the original file remains. This can cause cleanup routines to fail in some circumstances.