|
This section contains the following topics: |
Multiple copies of Ingres can be installed on a single server and run simultaneously. Each copy of Ingres is referred to as an Ingres instance.
An Ingres instance consists of a set of installed products that share a unique system-file location, ownership, and instance name, together with any data files created by these products.
An instance is classified as either a server installation or a client installation.
The default instance name is: Ingres II.
The instance ID is a two-character code that identifies a specific instance on a node and allows all processes and images to be installed and shared successfully. The value of the instance ID is stored in the II_INSTALLATION environment variable.
In the default instance name Ingres II, the instance ID is II.
The first character of an instance ID must be a letter; the second character can be a letter or numeral. The default instance ID is II.
If you have more than one instance on the same node, each instance on that node must have a unique instance ID. For example, you can install and run a new version of Ingres under one instance name, while maintaining an existing older version under a different instance name on the same computer or network node.
The system administrator account is a user account that is used for system management on each Ingres instance. The system administrator account owns the instance, and so the system administrator is often referred to as the instance owner.
This account is created when installing the DBMS Server. Ingres must be installed under this account because every DBMS system file requires ownership by this user.
Note: Use the system administrator account only for Ingres system management work. We recommend that you do not put non-Ingres files in this account.
The system administrator must have privileges to:
An Ingres instance includes the following files:
These files include the master database and user databases. The master database, iidbdb, stores information about all databases, their locations, and the users who can access them.
This file stores uncommitted transactions and buffers committed transactions before they are written to the database. Ingres uses one logical instance-wide log file. The file is circular and wraps when it encounters the physical end-of-file.
Each logical log file may consist of up to 16 physical disk files, referred to as partitions, which helps to alleviate I/O bottlenecks. To ensure that no committed transactions are lost if the primary transaction log devices fail, Ingres can maintain a backup of the primary transaction log file, also known as a dual log, on the storage locations you specify.
Checkpoint, journal, and dump files provide for data recovery in case of a database disk failure. Checkpoints alone provide for data recovery up to the time of the checkpoint. Checkpoints and journals provide for recovery up to the time of failure. Checkpoint, journal, and dump files provide online checkpoints.
Work files are temporary files created during external sorts and other DBMS Server operations that require large amounts of temporary file space.
Before installing Ingres, you must decide on locations for the Ingres files. Choose these locations carefully because they cannot be easily changed once specified (except for the location of the transaction log).
During installation, each location is stored in an Ingres environment variable/logical (for example, the location for the system files is stored in II_SYSTEM).
Use the following guidelines when choosing file locations:
The location you choose for Ingres system (executable and script) files will also contain the error log and configuration files. Choose a location that has adequate disk space.
The location for your databases contains the master database (iidbdb), which stores information about all databases, their locations, and the users that can access them. By default, this location also contains all user databases, unless the database administrator specifies an alternate location for a database when creating it.
When choosing this location, consider the following:
Checkpoint files, journal files, and dump files can reside on the same device because journals and dump files are useful in recovery only if the associated checkpoint is also available. By default, the install program places journal and dump files in the same location as the checkpoint files.
Important! Do not place the checkpoint device on the same disk as the database files. Storing data and backups on the same device provides poor insurance against disk failure. On single-disk systems, we recommend checkpointing to magnetic tape.
Work files can reside on the same device as the checkpoint files because work files are useful in recovery only if the associated checkpoint is also available. For highest performance, however, assign your temporary work files to a different physical device than your database, checkpoint, journal, or dump files.
For more information about temporary files and sorting, see the Database Administrator Guide.
Consider the following when choosing the locations for the transaction or backup transaction log file:
Locations for these files are defined by the log_file (primary) and dual_log (backup) configuration parameters. You can add, modify, or delete locations for your primary and dual transaction log files using the Configuration-By-Forms utility.
Note: On Ingres for Linux, the backup transaction log is disabled by default. To enable the backup transaction log, set the environment variable II_DUAL_LOG to the location of the backup log file (either in the response file or prior to installing).
Warning! We strongly recommend that you do not use ReiserFS for database locations. Severe performance degradation was noticed when using this file system.
Note: The II_SYSTEM location should not be placed on an OCFS-1 CFS.
Typical disk configurations for an Ingres installation are described here.
For any DBMS Server configuration, you can set up an optional backup transaction log device on a separate disk from the primary transaction log. This setup enables recovery of unsaved, committed transactions if the primary transaction log device fails.
A configuration with four or more disks provides the best performance and recovery options. For best performance, configure your system with the operating system on a separate disk and your Ingres files on three or more other disks, as follows:
Disk 1—Operating system files
Disk 2—Checkpoint, journal, and dump files
Disk 3—Product system files, and transaction log work files
Disk 4—Databases
If possible, put your backup transaction log on a separate disk from both your database and primary transaction log. Also, you can use more than one disk partition for your transaction log.
The following three-disk configuration provides better performance and additional recovery options than a two-disk system:
Disk 1—Operating system, checkpoint, journal, and dump files
Disk 2—Product system files, transaction log, and work files
Disk 3—Databases
Your backup transaction log can reside on either Disk 1 or Disk 3.
If Disk 3 fails, you can recover databases and committed transactions. If Disk 2 fails, you can recover your committed transactions if you have a backup transaction log; if you have no backup log, you will lose committed transactions that were not written to the database.
A two-disk system is the minimal recommended configuration because it avoids a single point of failure:
Disk 1—All Ingres files except for those on Disk 2
Disk 2—Databases, optional backup transaction log file
If Disk 2 fails, you can recover databases and committed transactions. However, if Disk 1 fails and you do not have a secondary log device, you will lose unsaved, committed transactions.
A single-disk system is a high-risk setup and not recommended. If the disk fails, you could lose all your data. On single-disk systems, you should checkpoint to magnetic tape.
Note: The default installation method installs Ingres as a one-disk system.
In the Client configuration, the Ingres Net and Ingres tools system files reside on a single disk on the client instance. The Ingres DBMS Server executables reside on the networked DBMS Server instance.
In the Network File System (NFS) configuration, no files reside on the NFS client instance. All Ingres files reside on the networked DBMS Server instance.
The NFS client instance uses the Network File System to share executables and other Ingres files. The ingmknfs utility, which you use to create and configure NFS clients, creates an NFS admin directory on the DBMS Server instance to store NFS client-related files.
During the installation process, values are assigned for several installation and configuration parameters. The values are stored in environment variables.
General installation parameters apply to all instances.
The general installation parameters are as follows:
Identifies the instance, and is part of the instance name.
Defines location of the product's system (executable) files.
Defines the user ID of the system administrator that owns the Ingres instance. The ID is added to the system if it does not exist.
Defines the group ID to which the system administrator user ID belongs and that owns the Ingres instance. The ID is added to the system if it does not exist.
Quiets installation messages except those from RPM.
Controls whether the instance will be started automatically when the operating system boots.
Controls whether the instance will be started automatically when the operating system boots.
Specifies the user ID that starts Ingres as a service.
The parameter settings when installing the Ingres DBMS Server are as follows:
Defines the location for the Ingres master database (iidbdb) and the default location for database files.
Defines the location for the checkpoint files that serve as a static backup of the database.
Defines the location for the journal files, which provide a dynamic record of changes made to Ingres databases since the last checkpoint.
Defines the location for the dump files used to perform online backups.
Defines the location for temporary files created during external sorts and other DBMS Server operations.
Defines the location of the transaction log file.
Defines the location of the backup transaction log file.
Defines the default size of the transaction log file. The default size (32768 KB per file) is adequate for most instances. You should change the file size only if you have an existing application that requires a larger transaction log file.
Specifies the maximum number of concurrent users.
Specifies the region and time zone.
Specifies the character set.
You must specify the time zone for your instance. This value is stored in the II_TIMEZONE_NAME environment variable.
On some systems, the default value for II_TIMEZONE_NAME is NA-PACIFIC. If you are in a different time zone, you must change the value of II_TIMEZONE_NAME.
Time zone names are organized by world region. In some cases, the time zone name is a positive or negative offset from Greenwich Mean Time (for example, GMT2 or GMT-2). If you are unable to locate the correct time zone within one of the designated world regions, use the GMTOFFSET world region and specify one of the GMT offsets as your time zone.
The time zone parameter tells Ingres what adjustments to make for Daylight Savings Time. If you must make other adjustments for special time changes imposed in your area (such as for energy conservation purposes), you can use the iizic time zone compiler provided in the distribution.
The world regions and their time zone names are as follows:
Africa Asia Australia Middle East |
North America North-Atlantic South America South Pacific |
Southeast Asia GMT-Offset |
You must select the character set during installation. The installation program provides a default value.
Important! After Ingres is installed, you cannot change the character set from its current setting (II_CHARSET) at any time without risking the corruption of your data.
Ingres-supported character sets for the non-Unicode character data types are as follows:
Character Set |
Description |
Format |
|---|---|---|
ALT |
Support of Cyrillic on DOS |
Single byte |
ARABIC |
Arabic-449-Plus |
Single byte |
CHINESET |
Traditional Chinese - Taiwan |
Double byte |
CHINESES |
Simplified Chinese - PRC |
Double byte |
CHTBIG5 |
Traditional Chinese - Taiwan, BIG5 |
Double byte |
CHTEUC |
Traditional Chinese - Taiwan, EUC |
Double byte |
CHTHP |
Traditional Chinese - Taiwan, HP ROC15 |
Double byte |
CSGB2312 |
Simplified Chinese - GB2312 |
Double byte |
CSGBK |
Simplified Chinese - GBK |
Double byte |
CW |
Cyrillic on Windows 3.1 |
Single byte |
DECMULTI |
DEC Multinational (superset of ASCII) and default for VMS |
Single byte |
DOSASMO |
IBM DOS ASMO Arabic (cp708) |
Single byte |
ELOT437 |
Greek for PC/RS6000/SCO-UNIX |
Single byte |
GREEK |
DEC Greek Elot |
Single byte |
HEBREW |
DEC Hebrew |
Single byte |
HPROMAN8 |
HP Roman8 (superset of ASCII) |
Single byte |
IBMPC437 |
IBM PC Code Page 437 (US and English) |
Single byte |
IBMPC850 |
IBM PC Code Page 850 (Multilingual), includes accented characters |
Single byte |
IBMPC866 |
IBM PC 866 (Cyrillic for DOS) |
Single byte |
IS885915 |
ISO 8859/2 (Latin and some Greek). Identical to ISO 8859/1 Latin, except for eight characters, including the Euro currency symbol (€, Unicode U+20AC). |
Single byte |
ISO88591 |
ISO 8859/1 Latin and default for UNIX (superset of ASCII) |
Single byte |
ISO88592 |
8859/5 (Latin and Cyrillic) |
Single byte |
ISO88595 |
8859/9 (Latin and some Turkish) CP 920 |
Single byte |
ISO88599 |
ISO 8859/15 (Latin and Euro sign) |
Single byte |
KANJIEUC |
Japanese, EUC |
Double byte |
KOI18 |
KOI 8-bit (ISO 6937/8), Russia |
Single byte |
KOREAN |
Korean |
Double byte |
PC857 |
IBM PC Code page 857 - Turkish |
Single byte |
PCHEBREW |
IBM PC / MSDOS Hebrew |
Single byte |
SHIFTJIS |
Shift-JIS Japanese |
Double byte |
SLAV852 |
IBM PC Code Page 852 (Slavic) |
Single byte |
THAI |
DEC Thai Tis |
Single byte |
WARABIC |
Arabic |
Single byte |
WHEBREW |
Microsoft Windows Hebrew |
Single byte |
WIN1250 |
Eastern Europe: Windows page 1250 |
Single byte |
WIN1252 |
Windows code page 1252 - Latin 1 (Western Europe) and default for Windows |
Single byte |
WTHAI |
IBM/Windows Thai (cp874) |
Single byte |
Note: On Linux, the character set value must be entered in uppercase.
Note: ja_JP.UTF-8 on Japanese SUSE Linux is not supported.
The following server types are available, depending on your particular instance:
Enables network communications between an Ingres client using one network protocol and an Ingres server using a different network protocol.
Enables network communications between an Ingres client and an Ingres server instance on a remote machine through Ingres Net.
Allows users access to your instance's databases.
Translates requests from the Ingres JDBC Driver and .NET Data Provider and forwards them to the appropriate DBMS Server.
Allows developers to build World Wide Web applications that can access enterprise-wide corporate data, through the Ingres Web Deployment Option.
Keeps track of all the servers associated with an instance.
Handles online recovery from server and system failures.
Enables the execution of Ingres commands on a remote Ingres instance. This server is used by the Visual DBA suite of tools.
Allows users to connect to multiple databases simultaneously through Ingres Distributed Option.
Computer, directory, and user names must be valid for the operating system that Ingres is being installed on and also adhere to the following restrictions.
Ingres supports computer names that contain the following ASCII characters only: alphanumeric and hyphen (-). Computer names must not start with a hyphen.
A valid Ingres directory path has slightly different syntax on UNIX and Windows.
On both UNIX and Windows, a directory name must start with an ASCII letter (that is, a-z and A-Z) or a digit (0-9), and can continue with ASCII letters, digits, and the following symbols: space, hyphen (-), underscore (_), full stop (.), colon (:), left square bracket ( [ ), right square bracket ( ] ), tilde (~).
Note: Windows does not allow a colon in a directory name.
UNIX and Linux: Absolute directory paths must start with a forward slash (/) and continue with a relative directory path. A relative directory path contains a number of directory names separated by /, as in the following example:
/usr/local/ingresII 
Windows: Absolute directory paths must start with a drive specification (a drive letter immediately followed by a colon), a backward slash (\), and then a relative directory path, as in the following example:
c:\program files\ingres\ingresII
The directory name can also start with underscore (_). 
Note: On UNIX and Linux, uppercase letters are distinct from lowercase ones (for example, a is not the same as A). On Windows, uppercase letters are not distinct from lowercase ones (for example, a is the same as A). In general, we recommend that path names not be distinguished by case.
Ingres supports user names that contain the following ASCII characters only: alphanumeric, at (@), pound (#), dollar ($), underscore (_). User names must not start with @, #, $, or a digit. These restrictions apply to the user names used to install Ingres and to connect to Ingres. Passwords must not exceed 20 characters.