Exam 918 Installation And Configuration

Installing IDS

Downloading IDS

Free for development use only.

Free version of Informix Dynamic Server Developer Edition 11.5

Several installation methods

  • Console mode (This is the default mode — it does not require you to add specific mode parameters in the command line for launching the installation application.)
  • GUI mode
  • Silent mode
  • Extracting the installation with command-line script
  • Invoking the JAR file directly

Installing in Console mode

Use the installation command specific to the products you want to install:

  • ids_install: Installs all components of IDS
  • installserver: Installs the database server only
  • installconn:IConnect only
  • installclientsdk: Installs the Client SDK only

Generate a response file and use it for silent installation

To replicate installation setup in other directories you can use an ASCII file to record the response of your installation. You can capture settings made in a GUI- or console-mode installation of Dynamic Server and bundled Informix products in a response file so that the same configuration can be applied later to silent installations on other instances.

  1. Pass the argument ./installserver [-gui] -record responsefile.ini if you are installing Dynamic Server only, or ./ids_install [-gui] -record responsefile.ini if you are installing Dynamic Server bundled with other Informix products. Do not name the response file server.ini or bundle.ini.
  2. Complete installation in GUI or console mode.
  3. Verify that your system generates a message verifying that creation of your response file was successful. As the root user, run the silent install, as in the following example, where responsefile.ini stands for the file name or file name and path:

./ids_install -silent -acceptlicense=yes -options responsefile.ini

Configuring IDS

Preparing space for data storage

The IDS server uses two types of I/O methods:

  • Kernel AIO: Kernel asynchronous I/O is a method of performing non-blocking disk reads and writes through the operating system. It replaces the traditional read and write operations that require the process to wait while the data is written to disk or read from the disk. Instead, the server submits the read and write request, and can subsequently continue processing. When the I/O completes, the server is notified. Kernel AIO is available only on certain operating systems and hardware platforms. Kernel AIO is also invoked if the chunks are on a raw device (defined below). Kernel AIO threads run on CPU VP.

To find out whether the server supports Kernel AIO, check the release notes in the $INFORMIXDIR/release directory.

  • AIO through AIO VPs: The server can also perform I/O through AIO VPs. The AIO VPs are responsible for performing read and write operations if Kernel AIO is not invoked. Also the AIO VPs perform I/O on all cooked files.

A raw device is a character-special device that you create using a UNIX utility that associates a device pathname with a device driver. This driver is a part of the operating system that translates I/O requests into instructions for the disk hardware. It is independent of the UNIX file system.

Preparing a raw device
Create a new (or identify a free) partition on a disk, and issue the following commands:

chmod 660 <device_name>
chgrp informix <device_name>
chown informix <device_name>

A cooked file is a regular file that is managed by the operating system. While the database server controls the contents of the file, it must make I/O requests to the operating system.

Creating a cooked file:

Issue the following commands:

touch <filename>
chmod 660 <filename>
chgrp informix <filename>
chown informix <filename>

Setting up the environment

Set the following environment variables before initializing a server:

Variable Description
INFORMIXDIR Set to the directory where the IBM Informix products are installed (for example, /usr/informix)
PATH Must include $INFORMIXDIR/bin
INFORMIXSERVER Set to the value of either the DBSERVERDBNAME or DBSERVERALIASES configuration parameter

More on environment variables at section Installing an informix environment.

Sample file (BASH shell):


Managing disk space

Physical Units

The database server uses the following physical units to manage disk space:

  • Chunk: Chunk is a unit of disk or physical space that is assigned to the server. A chunk can be raw device ( character-special device) or a UNIX cooked file. When assigning chunk to the server, you need to specify following the values of pathname, offset and size.
  • Page: The basic unit of I/O that the server uses is page. Any chunk/dbspaces created after the root dbspace can have page size from 2K to 16K, using multiples of default page size. A bufferpool is created if one does not already exist to hold the pages of the size specified.
  • Extent: Collection of physically contiguous pages on a disk. Spaces for tables are allocated in units of extents. Extent sizes for table are specified at the time of table creation.
  • Blobpage: Blobpage is the basic unit of storage for blob data types stored in blobspace. The size of the blobpage can be configured to be multiple of the system page size.
  • Sbpage: An sbpage is the type of page that the database server uses to store smart large objects within an sbspace . Unlike blobpages, sbpages are not configurable. Sbpage is the same size as the database server page.

Logical units

The database server stores data in the following logical units:

  • Dbspace: Dbspace is a logical collection of one or more chunks used to store databases and tables. Each dbspace must have at least one chunk assigned to it.
  • Blobspace: A blobspace is a logical storage unit composed of one or more chunks that store only TEXT and BYTE data. The database server writes data stored in a blobspace directly to disk. This data does not pass through resident shared memory.
  • Sbspace: An sbspace is a logical storage unit composed of one or more chunks that store smart large objects. Smart large objects include BLOB, CLOB, and user-defined data types (UDTs).
  • Tblspace: Tblspace is a collection of all the extents allocated to store information for a particular table or index in a single dbspace. Space represented by a tblspace is not necessarily contiguous, but the space represented by any one of the extents is guaranteed to be contiguous.

onspaces is a utility used for creating, dropping and changing the dbspaces. More on Informix OnLine utilities

SQL admin API

You can use the new built-in SQL administration API functions to perform administrative tasks remotely through EXECUTE FUNCTION statements of SQL. They are the ADMIN and TASK functions. These provide SQL interface to administrative command-line utilities of IDS. These can only be called by user informix and are defined in the sysadmin database.

Configuring connectivity

Connection types and communication protocols

There are three methods available for configuring client-server connectivity to an online system:

  1. Through a shared memory connection. When the client application and the database server are on the same host computer, this is the preferred method of communication. The client application and the server attach to the same segment of the shared memory.
  2. Through TCP/IP, using sockets or TLI programming interface. TCP/IP can be used for both local and remote communication.
  3. Through a stream pipe connection. This is a local, inter-process communication method that uses UNIX streams.

sqlhosts file

When an application attempts a connection to a database server, there is some basic information needed to make the connection. More details on Section Installing an informix environment.

Configuration file

The configuration parameters for the server are stored in a file located in the $INFORMIXDIR/etc directory.
Specify the name of this file by setting the ONCONFIG environment variable. Do not specify the full path, only the file name. The configuration file contains many different parameters that allow you to configure your server for your specific needs. Some parameters are set at the time you first set up your server and, once the server has been initialized for the first time, cannot be changed. Most parameters, however, can be modified after server initialization.

The following sections of parameters in the configuration file must be configured before a server can be initialized because the root dbspace contains the reserved pages, information about all databases on the server, and databases that track server activity:

  • Root dbspace: Every server must have a root dbspace. Initially, the root dbspace also contains the physical and logical logs. However, these can later be moved to other dbspaces. These parameters can only be modified before initializing the server for the first time. They cannot be changed once the space has been allocated for the root dbspace during server initialization.
  • Messages: IDS Server provides two different destinations for server messages - MSGPATH and CONSOLE
  • Server information: These parameters must be set so that your server can be uniquely identified on the host computer.

Logical logs

The logical log is a set of files that keep history of database transactions and database server changes since the last level 0 backup. These files are created automatically by the Informix Server during first initialization and then managed by Informix Dynamic Server onparams utility.
These transaction records are used to track all the changes made to databases that were created with logging. All databases share the same set of logical log files. Each server must have at least three logical log files.

Logical log files are circular. In other words, they can be used again and again after they are filled up. But there are certain conditions for reuse:

  • The logical log file must be backed up. By default, Informix Dynamic Server will automatically back up logical log files when they are filled up. This is stipulated by ALARMPROGRAM parameter in the configuration file. This parameter should always be set to a script which does logical log files backups. Usually this is done by the parameter BACKUPLOGS=Y. This script is a server system script that comes with Informix Dynamic Server software package.
  • All records in the logical log must be associated with closed transactions. By closed transactions, we mean transactions that are either committed or rolled back. If a transaction is pending and there is a record associated with that transaction in the logical log, then this logical log can't be reused.
  • The logical log must not contain the last checkpoint record. Onstat -l output can tell us which logical log contains the last checkpoint record: if the last position of flags field in its output is "L", then that indicates the logical log contains the last checkpoint record and could not be reused.
  • The logical log must not contain any transactions that did not get flushed to disk. This is to ensure all transactions will not be lost. When a transaction is completed, it stays in the logical log, waiting for the checkpoint to be flushed to disk. If we reuse the logical log before the checkpoint, we will lose all those transactions.

Logical log are managed by the onparams utility which allows adding, dropping and moving of logical logs. More on Section Informix OnLine utilities.

During its first initialization, Informix Dynamic Server will automatically create some logical logs. The number of logical logs it creates is stipulated by LOGFILES parameter in configuration file.

You might add logical-log files manually for the following reasons:

  • To increase the disk space allocated to the logical log
  • To change the size of your logical log files
  • To enable an open transaction to complete
  • As part of moving logical log files to a different dbspace

Useful Commands
To view all logging: onstat -l

To display logical log records: onlog -l

addr     len  type     xid      id link    

18       48   BEGIN    20       155 0        07/01/2003 15:34:08 737      eric

         00000030 009b0001 00000000 00009af8 ...0.... ........ 

         00000014 00000000 0427bcdf 00000000 ........ .'...... 

         00000000 3f01f040 0000006e 000002e1 ....?..@ ...n.... 

48       60   HUPDAT   20       0  18       3000c1   1707     0        108 108 1  

         0000003c 00000049 00008010 00006d91 ...<...I ......m. 

         00000014 00000018 0427bcdf 00000000 ........ .'...... 

         003000c1 00001707 00000000 006c006c .0...... .....l.l 

         00010003 00020100 00000000          ........ ....

84       48   COMMIT   20       0  48       07/01/2003 15:34:08

         00000030 00000002 00000010 00006d91 ...0.... ......m. 

         00000014 00000048 0427bcdf 00000000 .......H .'...... 

         3f01f040 00001707 00000000 3f01f040 ?..@.... ....?..@

The output shows that the transaction generated three logical log records, each containing two parts: record header and ASII dump. ASII dump is the ASII code of the data change.

Display logical log records in a specific logical log: onlog -n LOGID

In the previous example onlog -n 155 will give the following output:

addr     len  type     xid      id link    

18       48   BEGIN    20       155 0        07/01/2003 15:34:08 737   eric

48       60   HUPDAT   20       0  18       3000c1   1707     0        108 108 1  

84       48   COMMIT   20       0  48       07/01/2003 15:34:08

To monitor logical logs usage: onstat -l

[root@onlinehost /]# onstat -l

IBM Informix Dynamic Server Version 10.00.UC3R1   -- On-Line -- Up 01:20:46 -- 27700 Kbytes

Physical Logging
Buffer bufused  bufsize  numpages   numwrits   pages/io
  P-2  0        16       1704       116        14.69
      phybegin         physize    phypos     phyused    %used
      1:263            1000       210        0          0.00

Logical Logging
Buffer bufused  bufsize  numrecs    numpages   numwrits   recs/pages pages/io
  L-3  0        16       59864      3949       1808       15.2       2.2
        Subsystem    numrecs    Log Space used
        OLDRSAM      59864      5585968

address  number   flags    uniqid   begin                size     used    %used
445340b0 1        U-B----  181      1:1263               1000     1000   100.00
445340f8 2        U-B----  182      1:2263               1000     1000   100.00
44534140 3        U-B----  183      1:3263               1000     1000   100.00
44534188 4        U---C-L  184      1:4263               1000      430    43.00
445341d0 5        U-B----  179      1:5263               1000     1000   100.00
44534218 6        U-B----  180      1:6263               1000     1000   100.00
 6 active, 6 total


  • The Number field indicates logical log number.
  • The Flags field indicates the logical log status.
    • U stands for logical logs that have been used
    • B for backed up.
    • C for currently in use.
    • L for logical log that has the most checkpoint record.
  • The Uniqid field is the unique log id. Since logical logs are circular; this number changes whenever logical logs are getting reused.
  • The Size field indicates how large logical logs are in pages (one page is about 2 k bytes).
  • The Used field indicates spaces used for transaction records, also in pages.
  • The %used field indicates logical log usage in percent.

Physical Logs

The server has a special log that is used for automatic recovery purposes. This log is called the physical log. The physical log is a collection of contiguous pages on disk.
When a page is read into a shared-memory buffer and modified by a user, a copy of the page in its original condition is written to the physical log. This copy of the page is known as a before image (the copy of the page before it was changed). Only the first change to a page in a buffer causes a before image to be written to the physical log. Any subsequent changes to that same page do not cause additional before images to be written to the physical log. These before images are used by an automatic-recovery mechanism.
You can move the physical log location and size using onparams.
Checkpoints are triggered when physical log is 75% full and processing needs to complete before the rest of the physical log is used, so the database server blocks all the transactions to avoid filling up the physical log. In order to avoid transaction blocking, make sure the database server has enough physical log space to contain all the transaction activity that occurs during the checkpoint processing.

Configuring security

The configuration parameters for the server are stored in a file located in the $INFORMIXDIR/etc directory. The configuration file contains many different parameters that allow you to configure your server for your specific needs. More details on Section Installing an informix environment.

Label-based access control security feature

Label-based access control (LBAC) is a means by which the database system controls access to table objects. The database system controls access by attaching security labels to the table objects and comparing this with the security labels granted to users attempting to access that object. It grants access if the two match, denies access otherwise.

There are three types of security labels:

1. Row security label: A security label associated with a data row or record in a database table
2. Column security label: A security label associated with a column in a database table
3. User security label: A security label granted to a database user. A user can have labels for read access or write access.

A security label can contain one or more security label components. There are three types of security label components:

  1. Set: A set is a collection of elements where the order in which those elements appear is not important
  2. Array: An array is an ordered set. In an array, the order in which the elements appear is important because it denotes the degree of sensitivity of the data
  3. Tree: A tree represents a hierarchy that can have multiple nodes and branches. For example, trees can be used to represent organizational charts and to identify different departments within the organization.

A security policy defines the set of security label components that make up a security label. DBSECADM is required to manipulate LBAC objects.hys

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.