Understanding OnLine 's Physical Architecture

Here, the differences between OnLine and IDS differ significantly. This section speaks to OnLine's physical architecture only.

The DBA's goal is to understand what is going on inside the database. Informix can be an intimidating, complex creation that uses as much shared memory as the disk capacity of some personal computers. Shared memory sizes of 50 to 100 megabytes are not uncommon. All of the files are usually invisible to the computer's operating system and cannot be inspected as ordinary files.

Most of the workings of an OnLine database will show up as sqlturbo on a UNIX ps listing, yielding very little data about what the process is really doing. On IDS systems, the virtual processors will show up as oninit in the ps listing. Understanding what's really happening means learning how to use the Informix tools provided for peeking into the database and knowing how to interpret the data provided by these tools.

Processes and Daemons

The OnLine system uses a two-process architecture. The database process, or server process, does the actual manipulation of data within the system. This manipulation consists of retrieving (querying) and modifying (inserting or updating) the data within the database tables. This process is named sqlturbo. The other process is the client process. This process is often I-SQL or ESQL/C. The client process is the interface between the user and the database system. It interprets user input and commands, passing the requests to the server process and receiving appropriate responses from the server.

Even when the client process is operating against a single database on a single machine, the client/server model is in effect. When a transport mechanism such as INFORMIX-Star or INFORMIX-Net is added to the OnLine system, the client and server applications can be on different machines connected by a network. Thus, the OnLine database is designed from the beginning as a client/server database.

Although the division of labor between client and server processes is efficient, one of the drawbacks is that each client, or frontend process must have a corresponding server, or backend process. Since these backend processes can use over a half megabyte of RAM, performance can deteriorate when available RAM begins to get low. This problem is often addressed by third-party "middleware." Middleware, also known as transaction monitors, accepts requests from multiple clients and calls the server only once. IDS systems reduce the need for some middleware, as this new version supports a dynamic server environment that allows the DBA to choose to start a given number of back-ends that will serve the requests of all the frontend processes. IDS is designed using a multiprocess architecture, rather than a two-process architecture.

Unlike the Oracle database, which allows the frontends to communicate with the backends using different methods, OnLine uses UNIX pipes to transmit the data from the frontends to the backends.

References to UNIX in general are full of discussions of daemon processes. In OnLine these daemon processes run in the background and are responsible for such jobs as handling the checkpoints and maintaining the shared memory. The daemon processes for the OnLine system will show up first in the tbstat -u output and can be identified by the trailing "D" (for daemon) or "F" (for page flusher) in the flags field. These daemons will show up in ps listings as tbinit.