Every Ingres installation starts with the contents of the variable II_SYSTEM ($ II_SYSTEM Unix / Linux or% Windows% II_SYSTEM). From the directory pointed by this variable, there is always a directory called ingres. Under this directory, there is at least one bin directory, files, utility and lib.
Ingres is works with a set of variables of its own and are stored in the file symbol.tbl (directory files). We should never edit this file by other than Ingres commands ingsetenv, ingunset and ingprenv. The file has a particular format and can easily be corrupted ...
Managing the symbol.tbl file:
- ingsetenv: set a variable
- ingprenv: show the value of a variable or all variables
- ingunset: deposition a variable
ingsetenv variable value
These variables can also be positioned in the local environment of the user (export, setenv, set) and for some it is especially forbidden and dangerous (eg II_INSTALLATION).
config.dat,,protect.dat and config.log
The rest of the configuration is essentially in two files: config.dat and protect.dat (still in the directory files). Do not edit these files by a publisher (unless otherwise requested by the support, a guru or stipulated in the doc), but use cbf (Configuration By Form). The format of this file is all that is more mundane, but some depend on other resources and to advance together in a coherent way it is better to use cbf. The rules that bind these settings are stored in files. Crs (as Configuration Rule System). The basic rule with all these files is: we look but not touch it (so you edit them with view on Unix instead of vi, for example ...).
The file contains protect.dat protected resources (for the parameters derived in cbf). For example, the cache of the DBMS depends, by default, the number of users. If you increase the cache significantly ingres not protect this value and later you increase the number of users of the engine, setting the cache will be recalculated to a value that you do not a priori (since below your need ). It also offers file config.log which traces the history of changes: who, when, what (direct and derived parameters) Cbf.
- If you do not like or if you need to script changes to settings you can use the following commands:
- Generate the content of a config.dat :
- Valid a resource:
- Read a resource :
- Position a resource :
- Destroy a resource :
- name: parameter (or resource) as read in config.dat before:
- -v: verbose, to see the parameters affected by the change
- + p |-p: protected or unprotected (adds or removes the resource protect.dat)
- host name of the machine (as read in ingprenv II_GCNxx_LCL_VNODE where xx is the result of ingprenv II_INSTALLATION
- rule_map: file. crs
resource can not be positioned by cbf
and corresponds to the rights of the user (for a given machine) on the installation:(such as) have the right to start or stop, start ipm, etc..
is located in the name directory (in the directory files) and files are suffixed by the name of the machine. It is controlled exclusively through the netutil
All files mentioned in this document is to save regularly, to avoid panic in case of loss ...
Ingres / Replicator
Part of the configuration of replication and replication paths are stored directly in the system catalogs Ingres/Replicator (they start with dd_ for Data Distribution). The rest (configuration file server replication, for example) is in a rep
directory, usually located under $II_SYSTEM/ingres
Each tool mentioned in this document exists on each platform (that will cut into 2 large packages: windows on one side, Linux and Unix on the other). On Windows, they also exist in graphical format and are accessible via menus created during installation of the product.
Published by hyts78
Latest update on June 24, 2010 at 01:31 PM by jak58.