|
|
|
The process for installing and configuring Ingres for OpenVMS for the first time on a node is as follows:
This step copies the contents of the distribution onto your system in the correct locations with the correct permissions. If using the Express Install, it also automatically sets required configuration parameters for installed components to default values.
This step sets required configuration parameters for installed components.
Note: On a cluster installation, the setup programs must be run on every node. However, after completing the install and setup phase on just one node, you can start Ingres to test your installation. When you are satisfied with the results, you should shut down the installation and complete the setup programs on the other nodes.
This step starts Ingres on your system so the system administrator can access it.
This step sets optional configuration parameters to allow Ingres to run as desired.
In this step, you perform additional tasks needed to prepare Ingres for its users, such as creating an automatic boot command, authorizing users, and creating databases.
|
|
|
If you are experienced at installing Ingres for OpenVMS, you may want to follow this abbreviated process, which is a summary of the major steps.
The major steps to install Ingres on OpenVMS are as follows:
$ @sys$update:vmsinstal * distribution_medium
The distribution_medium is described in Install Ingres for OpenVMS.
Note: On a cluster installation, the VMSINSTAL utility should be run on only one node, but the setup programs must be run on every node.
$ ingstart
|
|
|
The Ingres logical TERM_INGRES defines the type of terminal you are using. You can enter a value for TERM_INGRES in response to prompts during the install process, or optionally, prior to running the install program. For information on supported terminal types, see the Database Administrator Guide.
To set the TERM_INGRES logical before installation
Enter the following command at the operating system prompt:
$ define TERM_INGRES ingres_terminaltype
For example, the following command defines your terminal as a VT100f:
$ define TERM_INGRES vt100f
|
|
|
Initially, you can configure your installation as one of the following major types. Later, you can install other products or modify parameter settings to add more capabilities to your installation. For example, you can add networking capabilities to a standalone installation that is connected to a network. Or you can add client capabilities to an installation that you initially configured as a networked DBMS Server.
The major configuration options are as follows:
Provides only local access to local databases. This instance includes the Name Server, DBMS Server, and its own set of tools.
Required products: DBMS Server, tools
Runs on one or more nodes in a cluster environment, which provides access to local databases from any of the nodes running Ingres.
This installation includes the Name Server, DBMS Server, and its own set of Ingres tools. It does not require a Communications Server.
Local databases, transaction log files, and other Ingres areas must be located on commonly accessible cluster devices.
If an Ingres node in the cluster installation crashes, any incomplete transactions on the failed node are recovered by Ingres processes.
Required products: DBMS Server, Ingres tools
Allows remote clients to access its databases through a network. (If tools are installed, local users also can access its databases.)
This instance includes the Name Server, DBMS Server, Communications Server, Data Access Server, ODBC driver, and JDBC driver.
By installing Ingres tools and then modifying the Ingres Net connection data, you can add outgoing client capabilities to a networked DBMS Server instance. Doing so enables it to act both as a client of a remote DBMS Server and as a DBMS Server to its own remote clients.
Required products: DBMS Server, Ingres Net, ODBC driver, JDBC driver, Ingres tools (optional, but required for local access to local databases)
Allows access to multiple databases—local and remote, Ingres and non-Ingres—simultaneously. This instance includes Ingres Star, Name Server, DBMS Server, Communications Server, Data Access Server, ODBC driver, and JDBC driver. It may also contain Ingres tools.
Required products: DBMS Server, Ingres Net, ODBC driver, JDBC driver, Ingres Star, Ingres tools (optional)
Has its own set of Ingres tools and accesses databases on a networked DBMS Server instance on a remote node. This installation includes the Name Server, Communications Server, Data Access Server, ODBC driver, JDBC driver, and Ingres tools. It does not contain the DBMS Server.
You can configure a networked DBMS Server instance as a client of another DBMS Server on a remote node. To do so, install Ingres tools on the DBMS Server, and then add client capabilities by modifying the Ingres Net connection data.
You can set up a client in a different environment to access an Ingres database in your current environment. For example, a client in a Windows environment can access a database in a Linux environment. For more information, see the Connectivity Guide.
Required products: Ingres Net, ODBC driver, JDBC driver, Ingres tools
|
|
|
You can have more than one installation on the same standalone computer or network node. Each installation on that computer or node must have a unique installation code.
A single node can contain one system-level DBMS Server or client installation and many group-level installations. The system-level installation is the "main" installation, which may be accessed by all authorized users. Each group-level installation will be the default for the members of a given group with a particular user identification code (UIC). Non-group members may use such an installation by running a script that is provided for that purpose.
Important! Assigning multiple instances to the same group UIC corrupts data and the logging and locking system.
System-level and group-level installations use different logical name tables to store Ingres location logicals (for example, II_DATABASE). In a system-level installation, these logicals are set at the system level and are stored in the LNM$SYSTEM table. In a group-level installation, logicals are set at the group level and are stored in the appropriate LNM$GROUP table. For instructions on how individual users can switch between system-level and group-level installations, see the System Administrator Guide.
The Ingres system administrator must maintain and keep separate any multiple instances on the same node. To help you keep track of these instances, the "ii_installs.com" script and the installation history log file "ingres_installations.dat," are provided in the distribution.
|
|
|
You must define logicals to point to a disk and optional directory location where the various files will be stored.
When specifying file locations other than II_SYSTEM, you must use a defined concealed logical name rather than the actual disk or directory specification. A concealed logical name is a name that you define to represent a particular directory specification. The install program stores the concealed logical name in the appropriate Ingres logical (for example, in II_DATABASE). It then uses your definition of the concealed logical to ascertain the actual location in which it will create the appropriate directory tree. This makes it easier to change locations later, if necessary. For details, see the System Administrator Guide.
The II_SYSTEM logical should be defined as either a concealed logical or as a device, if that device is a concealed logical. There is no advantage to using a concealed logical for II_SYSTEM, because the install program stores only the translated real device and optional directory specification in the II_SYSTEM logical. For more information, see the appendix "General Reference."
You must define any logicals other than II_SYSTEM that you use as both "rooted" and "concealed" at the system or group level as appropriate for your installation. A "rooted" logical can be used directly as if it were a device name. A "concealed" logical is one that is not translated any further; that is, the definition is concealed from programs that use them.
|
|
|
To define II_SYSTEM as a logical, enter one of the following commands at the operating system prompt, as appropriate:
$ define/group/exec/translation=concealed -
II_SYSTEM disk:[dir.]
$ define/system/exec/translation=concealed -
II_SYSTEM disk:[dir.]
|
|
|
To define a concealed, rooted logical
Group-level installation (while logged into an account in the appropriate group and the GRPNAM privileges):
$ define/group/exec/translation=concealed -
logicalname disk:[dir.]
System-level installation:
$ define/system/exec/translation=concealed -
logical name disk:[dir.]
where:
Is the name you assign to the concealed logical representing the location for a particular set of files.
Is the disk on which these files will reside.
Is the directory specification, if appropriate, in which you want the install program to create the directory tree for storing the Ingres files.
|
|
|
Use the following guidelines when configuring a VMS cluster installation:
Installing and configuring Ingres in a VMS cluster environment is described in Ingres Cluster Solution for OpenVMS.
|
|
|
The install program automatically creates the system administrator account if you want, after you specify its user name and user identification code (UIC).
Note: When the install program creates the system administrator account, it automatically sets up the minimum recommended process resources and privileges. However, if you provide the user name or UIC of an existing account, you must ensure that the account has the appropriate resources and privileges.
Each separate installation must be owned by a unique OpenVMS account, even if the same person acts as system administrator for all installations. This applies to both system-level and group-level installations.
For a system-level installation, the recommended user name for the system administrator account is ingres; for group-level installations, it is ingresxx, where xx is the installation ID. These user names are suggested, but not required. You can substitute different names.
Note: The system administrator account must not be the "SYSTEM" account. A separate, privileged account is required.
|
|
|
You can use any user identification code (UIC) for the account that owns a system-level installation as long as it is not used by any other Ingres installation. For a group-level installation, we recommend that you choose a group UIC that does not automatically confer system privileges. This means a UIC greater than the SYSGEN parameter, MAXSYSGROUP.
If you have more than one installation on a particular node, you must place these installations in separate group UICs. For example, if the UIC for the system-level installation is [300,1], the UIC for a group installation on the same node can be [400,1], but cannot be [300,*].
The UIC determines the group logical name table for a group-level installation. The users whose group UIC has an installation will be allowed to access their group's installation by default. Scripts are provided to switch between installations, but users can become confused. Therefore, it is best to be sure the UIC for a given group installation does not include users who must access the system-level installation or a different group installation.
|
|
|
The Setup programs configure installed components.
The Ingres Installation Verification Procedure (IVP) runs the Setup programs automatically at the end of the VMSINSTAL step, if you respond yes to the following installation program prompt:
Do you want to run the configuration IVP following this installation [YES] ?
If you choose to postpone running the setup programs or need to run them on another node in an Ingres cluster installation, you can invoke each setup program individually.
The order in which you execute the Setup programs is important. For a networked server installation, run the Setup program for the DBMS Server before running Ingres Net Setup. Ingres Net can then use several of the values you specified for the DBMS Server. Run Distributed Option Setup last.
To run a setup program
$ @II_SYSTEM:[ingres.utility]program_name
where program_name is the name of the setup program, as follows:
DBMS Server setup
C2 Security auditing
Ingres Net setup
Data Access Server setup
Ingres Bridge setup
Applications-By-Forms setup
Ingres Replicator setup
ODBC Driver setup
Ingres Distributed Option setup
RMS Gateway setup
Kerberos setup
The Setup program for each component displays a description of its purpose and any other important information you should know before setting up the software.
If you are setting up Ingres for clusters, you must provide a unique cluster identification number, between 1 and 32, which identifies the current node.
When setting up required parameters, default values sometimes appear in brackets after the prompt, as in the following example:
How many concurrent users do you want to support? [32]
To accept a default value, press Return. Otherwise, enter an appropriate value and press Return.
If you do not upgrade all databases during setup, you can upgrade specific databases later, using the upgradedb command (which also runs the utility that upgrades the tools catalogs). For more information, see the Migration Guide.
When the Setup programs complete, you are returned to the operating system prompt. Your Ingres installation is now configured.
|
|
|
Post-installation tasks include the following:
|
|
|
If you want your installation to start automatically whenever the system is rebooted, the operating system administrator must add the appropriate startup command to the system startup file.
Note: For any additions to this procedure that are necessary for your platform, see the Readme file.
To add an automatic startup command, follow these steps:
@SYS$STARTUP:INGRES_STARTUP.COM
Remove the comment status and delete any duplicate entries.
|
|
|
The install process identifies only the owner of the system administrator account to your installation to permit authorized access to the databases.
To enable users to access tools and databases, the system administrator must do the following:
|
|
|
To facilitate user access to tools when they log in to the system, add the following access commands to the login.com file for the user:
For users, add:
@II_SYSTEM:[ingres]ingusrdef.com
For database administrators, add:
@II_SYSTEM:[ingres]ingdbadef.com
For the system administrator, add:
@II_SYSTEM:[ingres]ingsysdef.com
The commands in these files provide tools access to all users in a system-level installation and to all users with the appropriate group user identification code (UIC) in a group-level installation.
|
|
|
The install program records in the installation history log file each new installation as it occurs:
SYS$COMMON:[sysexe]ingres_installations.dat
The installation history log file is placed in this location so that it can be as globally accessible as possible. VMSINSTAL will display its contents during installation to help avoid mistakes, so it is helpful to keep it accurate.
|
|
|
The system administrator can edit the installation history file to add data for an existing installation or to maintain data for your new installations.
To edit the installation history log file, use the following executable file provided with the distribution: II_SYSTEM:[ingres.install]ii_installs.com.
To run the ii_installs.com script
$ @II_SYSTEM:[ingres.install]ii_installs
The II_INSTALLS> prompt appears.
help
Note: If editing the file, be sure to maintain the sequential order of wrapped rows.
|
|
|
The Ingres Cluster Solution is a variation of a typical Ingres installation in which Ingres runs simultaneously on multiple host machines to provide cooperative and transparent access to one or more databases.
Ingres Cluster is a full server installation, except that file locations must be storage locations accessible from each node that is part of the cluster. Once installed, you run the iimkcluster utility to convert the initial installation into one of the cluster members (nodes), and then run the iisunode utility to add more nodes.
Use of the Ingres Cluster Solution is incompatible with the following Ingres features:
On each node, make sure that Ingres and your applications perform as expected. Ingres internally handles some restrictions by converting some lock levels and lock modes to lower level locks and stronger lock modes, which may result in increased contention or deadlocks.
|
|
|
The Ingres Cluster Solution has the following requirements:
|
|
|
Before installing Ingres in a VMS Cluster environment, follow these steps:
|
|
|
Follow these steps to install and configure Ingres in a VMS Cluster environment.
Typically, it is easier to resolve any configuration issues at this stage because only one machine is in use.
iimkcluster
The utility prompts you for a node number and a nickname.
Node numbers are unique integers in the range 1 through the maximum supported cluster members for your platform (currently 15). During a partial cluster failure, the surviving cluster member (node) with the lowest node number is responsible for recovering transactions on behalf of the failed nodes, so you should assign low numbers to the more powerful machines in the cluster.
The nickname is an optional simple alias, which you can use in any context in which you could specify a nodename parameter. The nickname appears in the error log instead of the machine name.
The iimkcluster utility renames the transaction logs and certain diagnostic log files (iircp.log, iiacp.log, and so on) by appending the host name of the machine on which the cluster member is running. Also created is a sub-directory in the II_SYSTEM:[ingres.files.memory] directory with the name of the host machine, and directory II_SYSTEM:[ingres.admin.hostname], which is currently unused.
This step keeps entities that are normally operated upon by only one node separate from corresponding objects that will be created by the other nodes.
You should also perform application testing to confirm that certain Ingres Cluster Solution restrictions, such as lack of support for row-level locking, will not impact the usability of your applications.
iisunode
The utility prompts you for a unique node number and nickname. Once entered and confirmed, iisunode does the following:
|
|
|
Applications can access Ingres configured for Ingres Cluster Solution by using any of the following methods:
|
|
|
Ingres allows the creation of server classes that function as regular DBMS servers but can be configured for specialized situations. The server parameter class_node_affinity, if set for a server class, allows servers in this class to be started on only one node at a time.
The configuration name and server class name for the default CNA classes generated is cnnn, where nn is the node number, zero padded.
While iimkcluster and iisunode set up a separate CNA class for each node they are run on, these classes are not bound to the node they were defined on, but can be started on any node. In addition, any database (except iidbdb) that is connected to a server class using CNA cannot be opened by any other server class, including the default class.
The advantage of these restrictions is that because all operations on the database are known to be being performed on one node with pages resident in one cache, operations on the database do not require distributed locks, and the pages for the database do not need to participate in Distributed Multi-Cache Management (DMCM) protocols. For an installation servicing multiple databases, this allows you to increase efficiency by grouping your database operations by node, which significantly increases cache hit rates and decreases the latency of lock resolution and the overhead associated with DMCM. In addition, Row Level Locking and Update Mode Locks are automatically supported for databases serviced by CNA classes, instead of being silently converted to coarser granularity locks and stronger lock modes.