GBase Database Instance Won't Start After Manual Installation? 5 Things to Check

You have completed the manual installation of GBase Database (GBase 8s), but the database instance refuses to start when you run oninit.

Before reinstalling the database software, check the instance configuration. A successful software installation does not necessarily mean that a database instance has been initialized or that its configuration is ready for startup.

In a manual deployment, several settings must work together, including environment variables, the onconfig configuration file, root database storage, network configuration, and file permissions.

Here are five areas to investigate when troubleshooting a GBase Database instance startup failure.

1. Has the Database Instance Been Initialized?

The first question is whether an instance has actually been created.

Manual installation does not necessarily create an instance automatically. Depending on the installation options, the software may be installed successfully while instance initialization remains a separate task.

Check the instance status:

onstat -

If the output indicates that shared memory has not been initialized, the instance is not currently running. This alone does not tell you whether the instance has ever been initialized.

Before running initialization commands, verify the instance configuration, environment variables, storage paths, and ownership.

For a new instance, oninit -ivy is an initialization-oriented command sequence that should only be used when appropriate for your deployment. The -y option automatically answers yes to prompts, while -i initializes the instance. Do not run it against an existing instance as a routine startup command, because initialization can have destructive consequences.

Follow the initialization procedure documented for your installed GBase 8s version.

2. Is the ONCONFIG Environment Variable Correct?

The ONCONFIG environment variable identifies the instance configuration file. If it is unset or points to the wrong file, the database may not load the configuration you intended.

Check the relevant environment variables:

echo "$GBASEDBTDIR"
echo "$ONCONFIG"

Then inspect the configuration file:

cat "$GBASEDBTDIR/etc/$ONCONFIG" | head

Confirm that:

• GBASEDBTDIR points to the correct software installation directory.
• ONCONFIG identifies the intended configuration file.
• The configuration file exists and is readable by the database account.
• The configuration values match the intended instance and storage layout.

If the file is missing, do not simply create an empty file with the expected name. Prepare the configuration according to the product documentation and your deployment requirements.

3. Does ROOTPATH Point to Valid Storage?

The root database space is another important area to verify.

In GBase 8s, ROOTPATH specifies the location of the root database space. The configured target must match the intended storage layout, and the database account must have the access required to use it.

Inspect the relevant setting in your onconfig file, then check the target path. For example:

ls -l /opt/GBASE/gbase/dbs/rootdbs

This example path is illustrative; use the actual location configured for your instance.

Check the following:

• The configured path matches the intended root database storage.
• The target file or storage resource exists when required by the initialization procedure.
• The filesystem has sufficient free space.
• The database account has the required ownership and access permissions.
• The storage configuration follows the requirements of your GBase 8s version.

Do not assume that every deployment must use a pre-existing file at a particular path. The correct preparation depends on how the root database space is provisioned.

Likewise, avoid changing ownership or permissions until you have verified which account should own the resource and how it is supposed to be initialized.

4. Is the sqlhosts Configuration Consistent?

The sqlhosts file defines connectivity information for database servers and services. An incorrect hostname, service name, or protocol entry can prevent clients from connecting, even when the database instance itself starts successfully.

Inspect the relevant entries in sqlhosts and compare them with the server's actual network configuration.

For example:

hostname
getent hosts "$(hostname)"

Check whether the hostname resolves to the expected address and whether the connection configuration uses the correct server and service information.

Remember that a sqlhosts problem does not always explain an oninit startup failure. It may instead explain why applications or database clients cannot connect after the instance starts.

Distinguishing startup problems from connectivity problems helps narrow the investigation.

5. Is the Required Port Already in Use?

A port conflict can prevent a database service from binding to its intended network endpoint.

If your GBase Database configuration uses port 9088, check whether a process is already listening on it:

ss -ltnp | grep ':9088'

Replace 9088 with the actual configured port if your environment uses a different value.

If another process is listening on the port, identify the process before making changes. Do not terminate it blindly; it may belong to another database instance or an unrelated service.

Also verify that the configured service name and port mapping agree with the intended network setup.

A port conflict is only one possible cause of a startup failure, so correlate the result with the database error messages and logs.

A Better Troubleshooting Order

When a GBase Database instance will not start after manual installation, work from the basics toward the more specific configuration issues:

1. Confirm that the software installation completed successfully.
2. Determine whether the instance has been initialized.
3. Verify the database account and environment variables.
4. Inspect the onconfig file and root database storage configuration.
5. Review startup errors and relevant database logs.
6. Check network configuration and port availability when indicated by the symptoms.

This sequence helps avoid unnecessary reinstallation and reduces the risk of damaging an existing database through inappropriate initialization or permission changes.

Conclusion

A failed oninit command does not automatically mean that your GBase Database installation is broken.

The underlying cause may be an uninitialized instance, an incorrect ONCONFIG setting, invalid root database storage, unexpected file permissions, or a configuration issue elsewhere in the environment.

The most effective approach is to verify each layer systematically and use the actual error messages to guide the next step.

For reliable GBase Database (GBase 8s) deployment, treat software installation, instance initialization, database startup, and client connectivity as separate stages. Understanding those distinctions makes troubleshooting faster and production operations more predictable.

When your database instance refuses to start, which do you check first: the ONCONFIG file, ROOTPATH, file permissions, or the database logs?