TIL: Four Key Configurations Inside the GBase Database `onconfig` File

Many people install GBase Database(GBase 8s), start the instance, and never open the onconfig file again.

I took a closer look at it recently and found four configuration areas that are especially important for database performance, memory management, and logging.

If you're learning GBase Database administration, understanding these parameters is a good place to start.

What Is onconfig?

onconfig is the core configuration file for a GBase Database(GBase 8s) instance.

It contains instance-level parameters that control areas such as memory, buffer pools, logical logging, connections, and other database behavior.

The typical naming convention is:

onconfig.<instance_name>

You can locate the configuration files with:

ls $GBASEDBTDIR/etc/onconfig.*

Four Parameters Worth Checking

1. BUFFERPOOL — Database Buffer Pool

BUFFERPOOL controls how data pages are cached in shared memory.

A larger buffer pool can reduce disk I/O for workloads that repeatedly access the same data, but it also consumes more memory.

The important point is that buffer pool configuration should be based on the workload and available system memory rather than a universal fixed value.

For environments using different dbspace page sizes, buffer pool configuration also needs to account for those page sizes.

2. LOGSIZE — Logical Log Size

LOGSIZE specifies the size of each logical log file.

Logical logs are important for transaction processing and recovery, so the appropriate size depends on workload characteristics, especially transaction volume and logging activity.

One important detail: changing LOGSIZE affects newly created logical log files. Existing logical log files do not automatically change size.

This means LOGSIZE should be considered together with LOGFILES, rather than tuned in isolation.

3. LOGFILES — Number of Logical Log Files

LOGFILES specifies the number of logical log files.

Together, LOGSIZE and LOGFILES determine the amount of logical log space available to the database.

For a write-intensive OLTP workload, insufficient logical log capacity can become a problem as transaction volume increases.

When reviewing GBase Database logging configuration, look at these parameters together with actual log usage and transaction behavior instead of applying a generic "larger is always better" rule.

4. SHMTOTAL — Total Shared Memory

SHMTOTAL specifies the total amount of shared memory that the database server can use.

This parameter is particularly important when planning memory usage on a production server shared with other applications.

A value of 0 can indicate that no specific shared-memory limit is imposed, depending on the database configuration.

Setting a fixed limit requires careful planning. If the database needs more memory than the configured limit allows, some operations can fail.

For that reason, SHMTOTAL should be considered together with the other memory-related configuration parameters and the physical memory available on the server.

How to View the Configuration

You can inspect the active GBase Database configuration with:

onstat -g config

To find a specific parameter:

onstat -g config | grep BUFFERPOOL

You can also inspect the relevant onconfig file directly:

cat $GBASEDBTDIR/etc/onconfig.<instance_name>

Checking the active configuration is especially useful during troubleshooting because the configuration file and the currently running instance should be considered separately.

How Should You Modify onconfig?

Not every onconfig parameter can be changed in the same way.

Some parameters support dynamic changes, while others require modifying the configuration file and restarting the database instance.

For parameters that support dynamic modification, GBase 8s provides administrative commands such as:

onmode -wf parameter=value

For parameters that require a restart, modify the appropriate onconfig file and restart the instance according to your operational procedure.

Always verify the parameter's dynamic configuration support before changing it. The exact behavior can depend on the parameter and GBase 8s version.

A Better GBase Database Tuning Approach

There is no universal onconfig template that works for every GBase Database(GBase 8s) deployment.

A better approach is:

1. Understand the workload.
2. Check available system resources.
3. Review the current configuration.
4. Identify the actual bottleneck.
5. Change one important parameter at a time.
6. Monitor the result.
7. Document the change.

For OLTP systems, pay particular attention to buffer pool usage, logical log activity, transaction volume, and memory consumption.

For other workloads, the important parameters and tuning priorities may be different.

The Takeaway

The GBase Database(GBase 8s) onconfig file is the control center of the database instance.

You don't need to memorize every parameter. But after installation, it is worth understanding the settings that directly affect your workload.

Start with these four:

• BUFFERPOOL — data page caching
• LOGSIZE — logical log file size
• LOGFILES — number of logical log files
• SHMTOTAL — total shared memory

Understanding these parameters can make GBase Database troubleshooting much easier—and help you make configuration changes based on actual workload behavior rather than guesswork.