Initialization process

When you start the database server or initialize disk space, the database server performs a set of steps. You can see the results of each step in the message log.

Disk-space initialization always includes the initialization of shared memory. However, some activities that normally take place during shared-memory initialization, such as recording configuration changes, are not required during disk initialization because those activities are not relevant with a newly initialized disk.

The following main tasks are completed during the two types of initialization:

Process the configuration file

The database server uses configuration parameters to allocate shared-memory segments during initialization and restart. If you modify a shared-memory configuration parameter, you must shut down and restart the database server for the change to take effect.

The ONCONFIG environment variable, which specifies the onconfig file that contains your configuration parameters, must be set before you initialize or restart the database server. Be sure that you also have the onconfig.std file. The server does not initialize if the onconfig.std file is missing.

During initialization, the database server looks for configuration values in the following files:
  • If the ONCONFIG environment variable is set, the database server reads values from the onconfig file.

    If the ONCONFIG environment variable is set, but the database server cannot access the specified onconfig file, the server returns an error message.

  • If the ONCONFIG environment variable is not set, the database server reads the values from the onconfig file.

If you omit any configuration parameters in your onconfig file, the database server uses the default values that are built in the server.If you omit any configuration parameters in your onconfig file, the database server reads the configuration values from the $INFORMIXDIR/etc/onconfig.std file.

The restart process compares the values in the current configuration file with the previous values, if any, that are stored in the root dbspace reserved page, PAGE_CONFIG. When differences exist, the database server uses the values from the current onconfig configuration file when the database server is restarted.

Create shared-memory segments

The database server uses the configuration values to calculate the required size of the database server resident shared memory. In addition, the database server computes additional configuration requirements from internal values. Space requirements are calculated and stored.

To create shared memory, the database server acquires the shared-memory space from the operating system for three different types of memory:
  • Resident portion, which is used for data buffers and internal tables
  • Virtual portion, used for most system and user-session memory requirements
  • IPC communication portion, which is used for IPC communication

    The database server allocates this portion of shared memory only if you configure an IPC shared-memory connection.

Next, the database server attaches shared-memory segments to its virtual address space and initializes shared-memory structures. For more information about shared-memory structures, see Virtual portion of shared memory.

After initialization is complete and the database server is running, it can create additional shared-memory segments as necessary. The database server creates segments in increments of the page size.

Initialize shared-memory structures

After the database server attaches to shared memory, it clears the shared-memory space of uninitialized data. Next the database server lays out the shared-memory header information and initializes data in the shared-memory structures. The database server lays out the space that is required for the logical-log buffer, initializes the structures, and links together the three individual buffers that form the logical-log buffer.

After the database server remaps the shared-memory space, it registers the new starting addresses and sizes of each structure in the new shared-memory header.

During shared-memory initialization, disk structures and disk layout are not affected. The database server reads essential address information, such as the locations of the logical and physical logs, from disk and uses this information to update pointers in shared memory.

Initialize disk space, if necessary

Disk space is initialized only when you start the server for the first time or when you run the oninit -i command. Disk space is not initialized when the database server is restarted. After shared-memory structures are initialized, the database server begins initializing the disk. The database server initializes all the reserved pages that it maintains in the root dbspace on disk and writes page zero control information to the disk.

If the DISK_ENCRYPTION configuration parameter is set, the root dbspace is encrypted.

The FULL_DISK_INIT configuration parameter specifies whether oninit -i can run on your instance when a page zero exists at the root path location (at the first page of the first chunk location). Use this configuration parameter to prevent an accidental disk reinitialization of an existing server instance.

The default setting of the FULL_DISK_INIT configuration parameter is 0. When the configuration parameter is set to0, the oninit -i command runs only if there is not a page zero at the root path location.

If a page zero exists at the root path location, initialization occurs only if the FULL_DISK_INIT configuration parameter is set to 1. The database server automatically resets the FULL_DISK_INIT configuration parameter to0 after the initialization.

Start all required virtual processors

The database server starts all the virtual processors that it requires.

The parameters in the onconfig file influence what processors are started. For example, the NETTYPE parameter can influence the number and type of processors that are started for making connections. For more information about virtual processors, see Virtual processors.

Make necessary conversions

The database server checks its internal files. If the files are from an earlier version, it updates these files to the current format.

Start fast recovery and checkpoint, if necessary

The database server checks if fast recovery is required and, if so, starts it. Fast recovery is not performed during disk-space initialization because there is not yet anything to recover.

For more information about fast recovery, see Fast recovery.

After fast recovery completes, the database server runs a checkpoint to verify that all recovered transactions are flushed to disk so the transactions are not repeated.

As part of the checkpoint procedure, the database server writes a checkpoint-complete message in the message log. For more information about checkpoints, see Checkpoints.

Document configuration changes

The database server compares the current values that are stored in the configuration file with the values previously stored in the root dbspace reserved page PAGE_CONFIG. When differences exist, the database server notes both values (old and new) in a message to the message log.

Update the oncfg_servername.servernum file

The database server creates the oncfg_servername.servernum file and updates it every time that you add or delete a dbspace, blobspace, logical-log file, or chunk.

You are not required to manipulate this file in any way, but you can see it listed in your $INFORMIXDIR/etc directory on UNIX™ or in your %INFORMIXDIR%\etc directory on Windows™. The database server uses the oncfg_servername.servernum file during a full-system restore for salvaging the logical log.

Change to quiescent mode

The database server now moves to quiescent mode or online mode, depending on how you started the initialization or database-server restart process.

Drop temporary tblspaces (optional)

Temporary tblspaces, if any, are tblspaces left by user processes that died prematurely and were unable to perform appropriate cleanup. The database server deletes any temporary tblspaces and reclaims the disk space. For more information about temporary tblspaces, see Temporary tables.

This task is performed when the database server is restarted; it is not performed during disk-space initialization.

If you use the -p option of oninit to initialize the database server, the database server skips this step.

Set forced residency, if requested

If the value of the RESIDENT configuration parameter is -1 or a number greater than 0, the database server tries to enforce residency of shared memory.

If the host computer system does not support forced residency, the initialization procedure continues. Residency is not enforced, and the database server sends an error message to the message log.

Change to online mode and return control to user

Control returns to the user when the database server writes the HCL OneDB™ Dynamic Server initialized - complete disk initialized message in the message log only if initialization, not database-server restart, occurred and dynamically allocates a virtual shared-memory segment.

The server returns control to the user. Any error messages that are generated by the initialization procedure are displayed in the following locations:
  • The command line
  • The database server message log file, which is specified by the MSGPATH configuration parameter

You can use the oninit -w utility to force the server to return to a command prompt within a configurable timeout. The oninit -w utility is useful for troubleshooting initialization failures.

Create or update SMI tables as necessary

The database server creates the system-monitoring interface (SMI) tables and other system databases if they do not exist.

If the SMI tables are not current, the database server updates the tables. If the SMI tables are not present, as is the case when the disk is initialized, the database server creates the tables. After the database server builds the SMI tables, it puts the message sysmaster database built successfully in the message log. The database server also re-creates the sysmaster database during conversion and reversion. For more information about SMI tables, see the chapter on the sysmaster database in the HCL OneDB Administrator's Reference.

If you shut down the database server before it finishes building the SMI tables, the process of building the tables stops. This condition does not damage the database server. The database server builds the SMI tables the next time that you bring the database server online. However, if you do not allow the SMI tables to finish building, you cannot run any queries against those tables, and you cannot use ON-Bar for backups.

The database server drops and re-creates the sysutils database during disk initialization, conversion, or reversion. ON-Bar stores backup and restore information in the sysutils database. Wait until the message sysutils database built successfully displays in the message log.

The database server creates the sysuser database during initialization. The sysuser database is used for Pluggable Authentication Module (PAM) authentication in HCL OneDB server to server communication.

The database server creates the sysadmin database during initialization. The sysadmin database provides remote administration and scheduler API features in HCL OneDB.

After the SMI tables and system databases are created, the database server is ready for use. The database server runs until you stop it or, possibly, until a malfunction.

Recommendation: Do not try to stop the database server by stopping a virtual processor or ending another database server process. For more information, see Start and stop virtual processors.

Monitor maximum number of user connections at each checkpoint

The database server prints the maximum number of user connections in the message log at each checkpoint in the following format: maximum server connections number. You can monitor the number of users who connected to the database server since the last restart or disk initialization.

The number that is displayed is reset when the customer reinitializes the database server.