Informix initialization parameters

Informix initialization parameters
Release 9.3

Naming the onconfig file

setenv ONCONFIG onconfig.sde

Onconfig parameters

• TAPEDEV
The TAPEDEV parameter specifies the device used to back up the dbspaces. During the loading phase of your database, it is often a good idea to set this parameter to the NULL device (Windows) or /dev/null device (UNIX). After the data is loaded, set the parameter to the proper tape device. The reason for this is the data is already backed up by the data source from which you are loading it; therefore, if a dbspace is lost to a disk failure, the data can be restored from the original data source. Once the database is loaded, you can set it to your tape device.
Windows

TAPEDEV  NULL



UNIX

TAPEDEV  /dev/null



In Dynamic Server 10.0 and later, you can set TAPEDEV to STDIO to direct back up and restore operations to standard I/O instead of to a device.
• LTAPEDEV
The LTAPEDEV parameter specifies the tape device to which the ONTAPE utility backs up the logical log files.
Set this to the NULL device (Windows) or /dev/null device (UNIX). Once the server is up, you can set it to your tape device if you intend to archive the log files.
Windows

LTAPEDEV  NULL



UNIX

LTAPEDEV  /dev/null




NOTE: Do not set LTAPEDEV to /dev/null or nul when you use ON–Bar to back up logical logs.

• NETTYPE
Network virtual processors are implicitly defined by the NETTYPE parameter. The NETTYPE parameter defines the number of poll threads allocated for each database connection type. The NETTYPE parameter defines the connection protocol, number of poll threads, concurrent connections per poll thread, and type of virtual processor that will run the connection's poll thread. A poll thread can be run by a CPU virtual processor or by a network virtual processor. The network virtual processors include SHM, SOC, STR, and TLI. All the network virtual processors are defined under the general virtual processor class NET. When the server is initialized, it starts one network virtual processor or each poll thread of the protocol defined by the NETTYPE parameter.
Set separate NETTYPE parameters to configure the poll threads for the shared memory and TCP/IP network protocols. The example settings below allow 20 local connections and 200 remote connections. Set the NETTYPE parameters to the expected number of local and remote connections, as in the examples below:
Windows

NETTYPE  olsoctcp,1,,NET



UNIX
Solaris 2

NETTYPE  ipcshm,1,20,CPU
NETTYPE  tlitcp,2,100,NET



HP

NETTYPE  ipcstr,1,20,CPU
NETTYPE  soctcp,2,100,NET



IBM

NETTYPE  ipcshm,1,20,CPU
NETTYPE  soctcp,2,100,NET




NOTE: Poll threads can be run inline by a CPU virtual processor. Poll threads tend to run more efficiently this way, particularly on single processor computers. If you have a lot of CPU virtual processors, it is possible to run all the poll threads on them. However, as user activity increases and the CPU virtual processors become congested, it is a good idea to off-load the work of the poll threads to network virtual processors. Poll threads are processed faster when run by network virtual processors, but they must still wait for a CPU virtual processor to run the sqlexec thread that processes the client's request.

When you have a large number of remote clients, use network processors to run the poll threads for network connection protocols (soctcp or tlitcp, depending on the platform). Use the CPU processors to run the few local client poll threads (ipcshm or ipcstr, depending on the platform). Some examples are shown below:
Windows

NETTYPE  soctcp,2,100,CPU



UNIX, Solaris 2

NETTYPE    ipcshm,1,20,CPU



• LOGFILES
The LOGFILES parameter specifies the number of logical log files created in your database when it is created or restarted. Logical log files comprise the logical log, which keeps a history of transactions since the time of the last storage-space backup. These allow you to keep the database in a consistent state if your server crashes in the middle of a transaction. This is useful during long single transactions such as geodatabase synchronization; if you are in the middle of synchronizing a large amount of changes between the child and parent geodatabase when the server crashes, the logical log files will roll back the changes, keeping the databases in a consistent state.
To find out how to estimate how many log files to create, see Estimating the number of logical log-files in the IBM Informix Dynamic Server Administrator's Guide.

• ROOTPATH
The ROOTPATH parameter specifies the initial chunk of the root dbspace. The default setting /dev/online_root causes the initialization of the Informix instance to fail unless you have actually created the device beforehand. Change the default setting from /dev/online_root path to the device of rootdbs space you have created. For example, after creating the device with the UNIX touch command as the Informix user and setting its permissions to 660 with the UNIX chmod command, set the ROOTPATH to the full path name of the root dbspace chunk file. If you are using a raw device, set the ROOTPATH to the full path name of the link to the raw device.

ROOTPATH  /disk1/informix_data/rootdbs



• MSGPATH
The MSGPATH parameter specifies the full pathname to the message log file to which the server the database is on will write status and diagnostic messages.
Update MSGPATH to reflect the location of your Informix installation. For example:

MSGPATH  /disk1/informix/online.log



• ALARMPROGRAM
The ALARMPROGRAM parameter specifies the full path of the script that will be executed when a log full event is issued. Set the parameter to log_full.sh to have the logical logs backed up automatically and to no_log.sh if you intend to back up the logs manually.
Update ALARMPROGRAM to reflect the location of your Informix installation. For example:

ALARMPROGRAM  /disk1/informix/etc/log_full.sh



• DBSERVERNAME
The DBSERVERNAME parameter specifies the unique name of the server. The DBSERVERNAME is assigned a communications protocol in the sqlhosts file. Typically the DBSERVERNAME is set to the server name that is associated with the shared memory communications protocol. The DBSERVERALIASES parameter normally holds the server name associated with the TCP/IP communications protocol.
Set this value to the lowercase name of your shared memory server. For example:

DBSERVERNAME  gis



• DBSERVERALIASES
Set this value to the lowercase name of your TCP/IP server. For example:

DBSERVERALIASES  gis_net

• BUFFERS
The BUFFERS parameter file controls the size of the regular buffers—the area of memory in which Informix stores the most recently used pages of data.
Buffers are specified in system pages. The Informix server checks the regular buffers to find the pages it needs. If it doesn't find them, it reads them into the regular buffers before using them. Doing so avoids reading the pages from disk for each user, improving performance. Pages accessed from memory are much faster than from disk. The pages are maintained in the buffer as long as the instance remains up or until more recently accessed pages require the space. Informix recommends that, initially, the buffers occupy 20–25 percent of physical memory. For example, if the page on your system is 2 KB and you have 512 MB of physical memory, set BUFFERS to 65,536 to occupy 25 percent of the physical memory.
Ideally, you want to keep the ratio of disk reads to buffer reads as low as possible. You can monitor the ratio by periodically issuing onstat –p and examining the percent cached reads after the system has been up for a while. If this ratio falls below 90 percent for a decision support system, you should consider increasing the size of the regular buffers.
Increase the number of data buffers to 2,000 or 25 percent of your physical RAM, whichever is greater. If your pages are 2 kilobytes (page size can be determined with the Informix command onstat –b) and your physical RAM is 256 MB, BUFFERS would be calculated as follows:

BUFFERS = <physical RAM converted to kilobytes> * 25% / 
          <page size in kilobytes> 
        = (256 * 1024) * 0.25 / 2    
        = 32768

BUFFERS 32768




NOTE: Beginning with Version 10.0, this is specified using the BUFFERPOOL configuration parameter.

• LOGBUFF
The Informix server uses three log buffers to temporarily store changes. As one buffer flushes to a log file, a user thread can write to another one. The log buffers generally default to 32 kilobytes or pages. Set the LOGBUFF to an even increment of the page size.
Determine the optimal size of the logical log buffer with the onstat –l command after the system has been running for awhile in update mode. Onstat –l reports the current statistics of the physical log buffer and logical log buffer.
Under the Logical Logging section of the onstat –l output, if the value under pages/io is less than 75 percent of the value under bufsize, the logical log buffer is too large, and shared memory is being wasted. Reduce the onconfig LOGBUFF parameter.
If the value under pages/io is greater than 95 percent of the value under bufsize, the logical log buffer may be too small. Increase the LOGBUFF parameter. (Generally, you would not set LOGBUFF to greater than 64 kilobytes.)
• PHYSBUFF
The Informix server uses two physical log buffers to temporarily store the pages that are about to be changed, commonly referred to as the before image. A physical buffer flushes to the physical log file once it becomes full. As one buffer flushes, the other buffer becomes current and the user thread writes to it.
The PHYSBUFF should always be an even increment of the page size.
Determine the optimal size of the physical log buffer with the onstat –l command after the system has been running for awhile in update mode. Onstat –l reports the current statistics of the physical log buffer and logical log buffer.
Under the Physical Logging section of the onstat –l output, if the value under pages/io is less than 75 percent of the value under bufsize, the physical log buffer is too large, and shared memory is being wasted. Reduce the onconfig PHYSBUFF parameter.
If the value under pages/io is greater than 95 percent of the value under bufsize, the physical log buffer may be too small. Increase the PHYSBUFF parameter.
• LOGSIZE
The LOGSIZE parameter controls the default size of the logical logs. The size of the logical logs can be specified when they are created with the Informix onparams utility. However, if the size is not specified, LOGSIZE is used.
Set the logical log file size to 100,000 kilobytes. When the logical logs are moved out of the rootdbs, they will be created with this size.

LOGSIZE 100000



• LOG_BACKUP_MODE
The LOG_BACKUP_MODE parameter specifies the mode in which logical logs are backed up. This mode can be either continuous or manual. Continuous mode will allow you to automatically do logical log backups when required.

LOG_BACKUP_MODE CONT



It is recommended you do not set LOG_BACKUP_MODE to NONE.
• CLEANERS, LRU_MIN_DIRTY , and LRU_MAX_DIRTY
Each page read into the regular buffers is added to a least recently used (LRU) queue that tracks the frequency at which each page is accessed. If the regular buffers become full, the user sqlexec process selects an LRU queue at random to find pages that can be overwritten. The sqlexec process examines the free least recently used (FLRU) list of the LRU queue.
Pages are free if they have not been changed. Changed pages are referred to as dirty pages. They move from the FLRU list to the modified least recently used (MLRU) list. If no free pages are listed in FLRU, the sqlexec is forced to do a foreground write to clear pages from the MLRU queue. Foreground writes are performed one at a time and are resource intensive.
Page cleaners normally write dirty pages to disk. They perform inexpensive background writes. However, if the page cleaners are unable to keep up, foreground writes become necessary.
The onstat -F command can determine how often foreground writes have occurred. Avoid foreground writes by making sure enough LRU queues and page cleaners are available. The number of LRU queues is set by the LRU variable in the onconfig file. Informix recommends you set LRU to a minimum of 4. For multiprocessor machines, set LRU to four times the number of CPUs.
The onconfig parameter CLEANERS controls the number of page cleaner threads running. Set the number of page cleaners to 6 or the number of disks that contain frequently accessed data, whichever is higher.

CLEANERS 6



The LRU_MIN_DIRTY and LRU_MAX_DIRTY parameters determine when the page cleaners wake up and go to sleep. Page cleaners wake up whenever the percentage of dirty pages in the MLRU reaches the LRU_MAX_DIRTY threshold, and they clean the dirty pages, starting with the least recently used, until the percentage of dirty pages is less than LRU_MIN_DIRTY.
The default setting of the LRU_MIN_DIRTY is 50, and the default setting of the LRU_MAX_DIRTY is 60. If the onstat –F command shows a significant number of foreground writes and increasing the number of LRU queues and page cleaners does not have any effect, try lowering the LRU_MIN_DIRTY and LRU_MAX_DIRTY thresholds to shorten the queues.

NOTE: Information that was specified with the LRU_MIN_DIRTY configuration parameter prior to Version 10.0 is now specified using the BUFFERPOOL configuration parameter.

• STACKSIZE
STACKSIZE specifies the amount of stack allocated to the Informix instance. For most applications, Informix recommends this parameter be left at its default value of 32 (kilobytes); however, for ArcSDE it is important to increase the size of this parameter to 64 (kilobytes) to support the Informix Spatial DataBlade user-defined data types (UDTs) accessed by ArcSDE.
Increase the initial stack size of each thread to 64 kilobytes by setting the STACKSIZE parameter to 64.

STACKSIZE 64



• RA_PAGES
This read-ahead parameter sets the number of data and index pages that are cached in the regular buffers whenever a sequential scan of one or more tables occurs.
Set the read-ahead pages to 125.

RA_PAGES  125



• RA_THRESHOLD
RA_THRESHOLD, the read-ahead threshold, specifies the number of remaining unread pages that triggers another call to read more pages from disk.
Set the number of unprocessed pages that trigger another read ahead to 85.

RA_THRESHOLD 85



• DUMPDIR
The DUMPDIR parameter specifies the location of the dump directory where error log files are written in the event of an assertion failure.
Leave the dump directory set to tmp if you have adequate space there. However, you can create a tmp directory under the Informix installation directory and set DUMPDIR to that. Should an assertion failure occur, the diagnostic files are one directory below the online.log file that references them.
Windows:

DUMPDIR C:\informix\tmp 



UNIX:

DUMPDIR /usr/informix/tmp



• RESIDENT
The RESIDENT parameter specifies which portion of the Informix instances shared memory can be swapped out of the operating system's shared memory. Allowing as many portions of the instance's shared memory as possible to remain resident eliminates a large amount of input/output (I/O) and context switching of the instance's memory structures.
When the operating system switches between processes, it normally pages portions of process memory to disk. Process memory designated as resident is not swapped to disk, so setting the RESIDENT parameter to 1 keeps as many of the instance's memory structures as possible resident given the amount of physical memory and system resources available.

RESIDENT 1



• MULTIPROCESSOR
The MULTIPROCESSOR parameter specifies whether the Informix server machine has one or multiple processors to use.
Set to 0 if the Informix server machine has only one processor, and set to 1 if there are multiple processors.