An ADABAS instance consists of a set of UNIX processes or Windows NT threads. Under UNIX, a process acts as UKP (user kernel process) or as special process with special tasks. Under Windows NT, the term "thread" is used instead of process; consequently, there are UKTs (user kernel threads). Strictly speaking, the ADABAS instance is realized in Windows NT by a process subdivided into threads. The required number of UKPs/UKTs and of special processes/threads depends on the number of used devspaces, the hardware configuration, and the database parameters.
In the following example, each box represents one UKP/UKT. Some UKPs/UKTs bundle up several tasks, others realize just one special task. The example is valid for a process structure in a UNIX system with one CPU.
A UKP/UKT bundles up a subset of all tasks (internal tasking). There are the following tasks:
Usertasks
Each user or each application program is assigned a usertask when connecting to the database. The usertask ensures the processing of SQL statements for the session. The number of available usertasks is defined by the database parameter MAXUSERTASKS.
Servertasks
The main purpose of servertasks is to perform data backups. If the installed database is a distributed system, servertasks also realize access to remote data. When configuring the database, the number of servertasks is automatically computed from the number of data devspaces and the number of provided backup devices.
Servertasks ensure the writing to secondary storage. They become active when a savepoint is being performed. A savepoint means that the modifications done to the data cache are also performed to the data on the disk.
Logwriter 1
The logwriter 1 ensures the writing of modification information (before and after images) to the transaction log.
Logwriter 2
The logwriter 2 ensures the writing of before and after images to the archive log(s).
Bufreader
For a large data cache, savepoint writing takes a long time. The bufreaders become also active between two savepoints to write data asynchronously from the data cache to disk. The number of bufreaders to be activated, if needed, must be defined in xparam. It depends primarily on the data cache size and the number of data devspaces.
Utility Task
The utility task is reserved for the database operating. It is only used to handle administrative tasks. As there is only one utility task for each serverdb instance, no parallel operating actions can be done.
Bufwriter Task
ADABAS allows a special trace, the so-called vtrace, to be activated for diagnose purposes. The bufwriter task is provided for this purpose.
Sender and Receiver
In a distributed database installation, these tasks perform the communicative operations between the serverdbs involved.
Timertask
The timertask handles all kinds of timeout situations.
Special processes/threads are activated in addition to UKPs/UKTs. There are the following special processes/threads:
Requestor
The requestor receives the local communication requests (connect) as well as requests from the network and assigns them to a UKP/UKT. For example, the requestor informs the corresponding UKP/UKT when a user disconnects abnormally.
Timer
The timer monitors the time for timeout control.
Dev Processes/Threads
Dev processes/threads ensure that write and read operations to be done for the corresponding tasks are actually performed. Their number primarily depends on the number of devspaces in the installed database. Usually, two dev processes/threads are activated for each data devspace and the system devspace, one dev process/thread is activated for the log devspaces and for vtrace writing, if this has been enabled.
The process/thread dev0 plays a special part. Dev0 coordinates and monitors the dev processes/threads. For example, if a mirrored devspace fails in warm mode (bad devspace), dev0 ensures that the corresponding dev processes/threads are terminated. Database operation is not impaired in this case.
If the database is enlarged in warm mode by adding another data devspace, dev0 ensures that new dev processes/threads are generated.
All the other dev<i-> processes/threads write data to or read it from the devspaces.
Temporary Dev Processes/Threads
Processes/threads are temporarily activated to read and write data for data backups. These processes are called asdev<i>. Their number depends on the number of data devspaces and of the number of backup devices.
In UNIX systems, dev0 coordinates these processes.
Under Windows NT and Windows 95, the special thread async0 coordinates these processes.
Coordinator
The coordinator process/thread has a special meaning. It monitors all kernel processes/threads of the instance. When starting the database instance, the coordinator is the first process/thread that becomes active coordinating the start of the other processes/threads. For example, if a process/thread fails in warm mode, the coordinator stops all the other processes/threads in the worst case.
There are some more special processes/threads in addition, according to the operating system:
Clock Thread
The clock thread is only used under Windows NT and Windows 95. It computes internal times; for example, to determine the time needed to execute an SQL statement.
Console Process
In UNIX systems, the console process gathers information produced by other processes that could be useful to the administrator and writes it to the knldiag operating message file.
Under Windows NT and Windows 95, there is also a knldiag operating message file into which the information is entered by each thread.
Console Thread
Under Windows NT and Windows 95, this special thread satisfies requests made by the x_cons console. x_cons communicates with the console thread for this purpose.
In UNIX systems, x_cons receives the required information from the processes' shared memory.
Death Prozeß (UNIX only)
The death process monitors the coordinator process. If the coordinator process fails in an operative database, the death process stops all the other processes.
Network Process (UNIX only)
If REMOTE-ACCESS is set to YES in xparam, this process - instead of the vserver - is used for communication between a remote application (remote SQL) and the kernel. A network process can serve several connections.