Guide Information

Guide Title: OwlDB User Guide

Publication Date: 2026-09-30

Software Version: OwlDB v.2.0.0

Guide Version: v.2.0.0

Overview

This guide is written for all users who wish to conveniently operate and manage databases using the features provided by OwlDB.​

Prerequisite Knowledge

• Understanding of databases

• Understanding of RDBMS

​

This document consists of a total of 5 chapters.

OwlDB is a managed database platform that installs databases in cloud and on-premises environments and registers, integrates, and manages them as DB Services. On this page, you can check OwlDB's operating environments, key features, and supported engines and topologies.

Operating Environment

Cloud Environment Support

This is a method of dynamically creating and operating databases by utilizing cloud infrastructure resources. Based on IaC (Infrastructure as Code), it automates infrastructure provisioning and database configuration, allowing users to build and scale database environments with the desired specifications from the console.

On-premises Environment Support

This is a method of operating databases based on physical infrastructure resources that the customer owns, such as servers, networks, and storage. It is designed to efficiently utilize fixed infrastructure resources and supports closed-network environments that are disconnected from external networks. Through OwlDB, you can install new databases on hosts or integrate databases already in operation as OwlDB management targets for unified control.

Scope of Provision by License

OwlDB differs in its provided environments and features depending on the license.

Based on common management features generally used in both environments, OwlDB provides dedicated features optimized for the infrastructure characteristics of cloud and on-premises respectively.

The relational database (RDBMS) engine specifications supported by OwlDB and the architecture configurations per environment are as follows.

On the Bootlog page, you can check status and error information related to the DB boot procedure and diagnose the causes of problems. You can view logs by boot and down event, and clicking each message lets you check the full detailed log in the right side panel.

Query period

At the top of the screen, set the period to query. Select from the last 1 day, 3 days, 7 days, or 1 month, or specify the start and end dates by direct input.

1. Click Monitoring > Log Monitoring > Bootlog.

2. Select the period to query.

3. Set the event, mode, and status filters to narrow the query range.

4. Click the message link of the log you want to check.

5. Check the detailed content of the log in the right side panel of the screen.

To provide real-time updates on the monitoring screen, an auto refresh feature is supported.

1. Click the ⚙️ icon at the top left.

2. Set the refresh interval.

This page explains the system, network, and database settings that must be prepared, and how to place the deployment files, before registering an existing Tibero in production with OwlDB.

System requirements

Disk (volume) requirements

Since the existing database is already configured, no separate preparation is required for the Data/Archive/Redo disks. Only the Backup disk needs to be checked.

The Backup disk must have the xfs filesystem created and mounted.

Network Requirements

Required port configuration for the database server

The ports below are required to register an existing database with OwlDB.

Firewall configuration is required for communication between the OwlDB server and the database server.

For databases operating in a TAC (Tibero Active Cluster) or DR configuration, please set the parameters below in advance.

DB parameter

CM parameter

• owldb dp binary (owldb-dp-installer-*.tar.gz)

• license file (license.xml)

Move to the path where the existing database is installed (hereinafter installation directory). (Example: /home/rocky/owldb)

Extract the DP binary at the same level as the TB_HOME of the existing database.

After preparation is complete, the $TB_HOME structure is as follows.

Then, proceed by moving to the .

This page gathers reference materials and troubleshooting guides that are helpful in addition to the user guide. If you encounter a problem during use, please check the relevant items below first.

This describes how to access the OwlDB UI and check the Agent connection status.

1. Verify Agent Connection

After accessing the OwlDB UI, click the Explore button to check the Agent connection status.

The connection address is http://<OwlDB server IP>:<UI_PORT>/owldb/#/auth/login.

Using OwlDB on-premises requires some preparation in the customer environment. This page first explains the configuration of OwlDB and then guides you through what preparation is needed for each component.

System configuration

OwlDB consists of two types of servers.

The OwlDB server and the database server communicate through the Agent installed on each server.

The Agent is installed on the database server, receives connections from the OwlDB server, and locally executes the tasks required for Tibero installation/startup/monitoring.

OwlDB on-premises supports two configurations depending on how the database is used.

• Installed DB: A method of installing and managing a new database through OwlDB.

• Registered DB: A method of registering an already operating database with OwlDB for management.

To use a database with OwlDB, the following patches are required.

This guide proceeds in the following order. Preparation of the OwlDB server and the database server can be done in parallel, and the connection check is performed after both are ready.

📷 [Image] image

Before installation, prepare the following two types of distribution files.

From the Management > Data Space Management menu, you can view and manage databases belonging to an OpenSQL instance. In the database list, you can see each database's size, number of active sessions, and Tuple Health status at a glance, and create or delete databases. Clicking a database alias lets you also review detailed information such as Encoding, Connection Limit, and Bloat Ratio, along with trend metrics.

View database list

When you enter the Management > Data Space Management menu, the list of databases belonging to the current instance is displayed. A status summary for the entire instance is shown at the top of the page, and you can review the detailed status of each database in the central table.

Top summary information

The Tuple Health status is determined based on the Bloat Ratio and the last Vacuum execution time.

You can find a specific database by entering its alias in the search box. Clicking a column header sorts in ascending/descending order, and the default sort criterion is alias ascending. Clicking the 🔃 icon manually refreshes the page data.

1. Click the Management > Data Space Management menu.

2. Check the status in the top summary information and the database table.

3. To find a specific database, enter its alias in the search box.

Clicking the Create button opens the database creation drawer on the right side of the screen. After entering the required fields, clicking the Create button sends the creation request and closes the drawer. The result of the creation request and whether it is complete can be confirmed via the toast message displayed at the top of the screen.

The * notation indicates a required input item.

When Unlimited is checked, connections are unlimited within the instance's max_connections range. To limit the number of connections, uncheck the checkbox and enter the desired value.

1. On the Management > Data Space Management page, click the Create button.

2. In the database creation drawer, enter the Database Name and the required fields.

3. Click the Create button.

4. When the drawer closes, check the creation request result and completion status via the toast message.

Clicking a database alias in the list moves you to that database's detailed information page. The page consists of three areas: basic information (Info), Database Activity, and Trend Metrics.

Clicking the 🔃 icon manually refreshes the page data. Clicking the parent menu name in the breadcrumb at the top of the page returns you to the Data Space Management list.

1. On the Management > Data Space Management page, click the alias of the database you want to view from the database list.

2. Check the status and current state in the basic information, Database Activity, and Trend Metrics areas.

Basic information (Info)

Database Activity

Trend Metrics

A database can be deleted from two places: the list page and the detail page. Clicking the delete button opens a confirmation modal, and the deletion proceeds after final confirmation in the modal.

1. On the Management > Data Space Management page, go to the database you want to delete. [List Page] Select the database to delete using the radio button. [Detail Page] Click the alias of the database to delete to move to the detail page.

2. Click the Delete button.

3. In the delete confirmation modal, review the deletion target and the scope of impact.

Role switching is a feature that manually swaps the roles of the Primary DB and Standby DB in environments using a DR (Disaster Recovery) configuration. Administrators can perform role switching directly in various situations, such as failure response or regular maintenance, and the operation is performed on the Management > Overview page.

Role switching proceeds in one of two ways depending on the current status of the Primary DB. If the Primary DB is in a normal state, the role is switched safely without data loss using the Switchover method. If the Primary DB is in an abnormal state, the selected Standby DB is immediately promoted to the new Primary using the Failover method. The system automatically decides which method to use after checking the status of the Primary DB.

Role Switch

The role switching modal consists of two steps: Security Authentication and Switch Settings. In the first step, you verify administrator privileges by entering the password of the currently logged-in account, and in the second step, you select the new Primary DB.

1. Go to the Management > Overview page.

2. Click the Actions button, and then click Role Switching from the dropdown list.

3. In the Security Authentication Before Role Switching step, enter the password of the currently logged-in account and click Confirm.

• If the password does not match, the error message "Passwords do not match." appears.

1. Select the Standby DB to promote from the Select New Primary DB dropdown.

2. Enter Remarks if necessary.

3. Click Confirm.

After the switch request, the system automatically diagnoses the current status of the Primary DB to determine the switching method.

• Switchover: Performed when the Primary DB is in a normal state. It safely shuts down the current Primary and completes data synchronization, then promotes the selected Standby DB to the new Primary.

• Failover: Performed when the Primary DB is in an abnormal state. It immediately promotes the selected Standby DB to the new Primary to restore service.

Before installing OwlDB, check the system and network requirements that the server must meet and prepare the environment in advance.

System requirements

Check whether the following requirements are met on the server where OwlDB will be installed.

1. Hardware requirements

Since OwlDB runs on Docker, the following software must be installed before installation.

Docker

At least 50GB of disk space is required to install OwlDB, and it is recommended to organize it by purpose as shown below.

The OwlDB server communicates with both users (web browsers) and each database server. Complete the following port configuration and communication allowance settings in advance.

The following ports must be open on the OwlDB server.

Based on the port configuration above, firewall allowance settings are required between the OwlDB server and the database server. Set inbound and outbound rules in accordance with the customer environment's firewall policy.

On the Management > Backup/Recovery > Recovery History page, you can view and manage the history of database recovery operations performed in the past.

The recovery history provides detailed information such as the start and end date and time of recovery operations attempted by the user and the progress status (success/failure). Recovery types are classified into Full Restore and Point-In-Time Recovery (PITR). It supports period-based queries from the last 1 day up to a maximum of 3 months as well as through direct input, and provides type and status filters and a name search function.

1. Navigate to the OwlDB console screen > Management > Backup/Recovery > Recovery History menu.

2. Click the DB Alias dropdown button to select the database whose recovery history you want to check.

OwlDB performs backup and recovery of the OpenSQL database using Barman (Backup and Recovery Manager), the OpenBackup. The OpenBackup server is the server that stores backup data and WAL (Write-Ahead Log), and it is installed on a separate server from OwlDB.

System requirements

1. Hardware requirements

Disk capacity is calculated by summing the following items.

When multiple databases are integrated into a single OpenBackup server, sum the capacity of each database.

Install the following packages on the OpenBackup server.

Configure the firewall to allow the following communications.

• The OpenBackup Agent Port is the value entered on the OwlDB screen during integration, and can be specified in the range 1024–65535. It has the same default as the OwlDB server port, but they are ports on different servers.

• Port 22 must be open in both directions. From the OpenBackup server to the database server, data files are transferred during recovery, and in the reverse direction, WAL archives are transferred. If only one direction is open, the backup or recovery will fail.

Users without an OwlDB account can request account creation directly on the Login page.

1. Click the Request Account Creation button on the Login page.

2. Enter the information below. ID Name Password Confirm Password Email

3. Click the Request button.

4. Click the Confirm button in the account creation request modal.

5. When you click the Confirm button, you are redirected to the Login page.

Once the administrator approves the account creation, the account is activated.

This section describes the components and features of each area of the console screen.

This page verifies the inter-node readiness (UID/GID match, SSH key authentication, key file consistency) required for OwlDB Agent connection and DR configuration.

1. Verify Agent Connection

After accessing the OwlDB UI, click the Explore button to check the Agent connection status.

http://[OwlDB server IP]:[UI_PORT]/owldb/#/auth/login

2. Verify UID/GID Match (when configuring DR)

Run the following command on each node to compare whether the UID/GID are identical down to the number.

# Run on each node
id tibero

Expected result (identical on all nodes):

uid=1100(tibero) gid=1100(dba) groups=1100(dba)

If the UID or GID number is output differently, recreate the user on that node following the OS user creation procedure in the database server common preparation requirements.

3. Verify SSH Key Authentication Operation (when configuring DR)

From each node, attempt SSH connection to all other nodes with the tibero account, and verify that the connection succeeds without a password.

# Run with the tibero account on Node1(10.10.0.11)
ssh -p 22 -i ~/.ssh/id_ed25519 -o BatchMode=yes tibero@10.10.0.12
ssh -p 22 -i ~/.ssh/id_ed25519 -o BatchMode=yes tibero@10.10.0.13

# Run with the tibero account on Node2(10.10.0.12)
ssh -p 22 -i ~/.ssh/id_ed25519 -o BatchMode=yes tibero@10.10.0.11
ssh -p 22 -i ~/.ssh/id_ed25519 -o BatchMode=yes tibero@10.10.0.13

# Run with the tibero account on Node3(10.10.0.13)
ssh -p 22 -i ~/.ssh/id_ed25519 -o BatchMode=yes tibero@10.10.0.11
ssh -p 22 -i ~/.ssh/id_ed25519 -o BatchMode=yes tibero@10.10.0.12

BatchMode=yes forces an immediate failure when a password prompt occurs, so key authentication failures can be clearly detected.

4. Verify Key File Consistency (when configuring DR)

Verify with a hash whether the distributed key file is identical on all nodes.

If the hash is output differently between nodes, perform the of the database server common preparation requirements again.

Address

TmaxTower, 45 Jeongja-il-ro, Bundang-gu, Seongnam-si, Gyeonggi-do

Website

Technical Service Center

Tel : +82-1544-8629

E-Mail : docs@tibero.com

Restricted Rights Legend

The contents of this manual and the program described herein may be used only under a license agreement with TmaxTibero Co., Ltd., and the manual may be distributed or reproduced only within the scope of the license agreement.[^1] No part or whole of this manual may be transmitted, reproduced, distributed, or used to create derivative works by any means, electronic, mechanical, recording, or otherwise, without the prior written consent of TmaxTibero.

The license agreement for this software manual and program shall under no circumstances be construed as transferring any intellectual property rights (whether registered or not) related to the manual and program, and does not grant the right to use any brand, logo, or trademark. The manual is intended solely for the purpose of providing information, and TmaxTibero assumes no direct or indirect contractual liability arising therefrom, nor does the content of the manual guarantee that any specific legal or commercial conditions are satisfied. The contents of the manual may be changed without notice due to product upgrades or modifications, and no guarantee is made that the contents are free of errors.

Change detection is a feature that detects when a database configuration has been changed outside of OwlDB and reflects it in OwlDB.

When you click the Discover button at the top of the dashboard, any DB with detected changes is displayed on the dashboard. The change detection feature is provided only for registered DBs. Installed DBs are excluded from change detection.

Change detection is divided into the following two types.

On the Eventlog page, you can view event logs generated according to the rules defined by OwlDB.

In the Monitoring > Log Monitoring > Eventlog menu, you can check logs generated for a DB Service, and filter out only the events you want by combining the query period and filters. Results are displayed in descending order of received date.

1. Click the Monitoring > Log Monitoring > Eventlog menu.

2. Select the query period. To specify a particular range, select Direct input and then set the start and end dates.

The Overview page lets you check the entire overview of the selected database at a glance. You can view detailed information such as database information, instance information, and version information, and you can perform various operations such as starting, stopping, and deleting the database.

Under Management > Backup/Recovery > Backup, view the database backup list and perform creation, modification, deletion, and recovery. It supports Full/Incremental Backup, which can be generated automatically through the scheduler or created manually by the user.

Viewing the Backup List

When you enter the Management > Backup/Recovery > Backup menu, the backup list of the current database appears. Incremental Backups are displayed nested in a tree structure with Full Backup as the root.

The columns displayed in the list are as follows.

When you enter a name and retention period, a single backup image for the desired point in time is created. Tibero manages Full Backup units based on RMGR, and for OpenSQL the backup unit varies depending on whether the rsync or postgres method is selected.

1. Click the Create button on the Backup page.

2. Select the Type.

3. Enter the Name.

4. Select the end date of the retention period in the calendar. It is retained until the selected date and expires at 00:00:00 the next day.

When you select one backup from the backup list and click the Recover button, the recovery modal appears. Select a recovery type to recover the database to a specific point in time.

Backup and DR impact by recovery type

Recovery can take up to several hours, and you can check the progress in the recovery history.

1. Select one backup to recover.

2. Click the Recover button.

3. Select the recovery type.

4. If you select PITR, select the date and time to recover to. The selectable range is between the recoverable point of that backup and the current time.

Edit the name and retention period of the backup.

1. Select one backup to edit.

2. Click the Edit button.

3. Change the name or retention period.

4. Click the Save button.

Permanently delete the selected backup image.

1. Select one or more backups to delete.

2. Click the Delete button.

3. Confirm the deletion notice modal.

4. Click the Delete button.

If the agent.env value needs to be changed or the Agent fails to start for an unknown reason, you can restart the Agent with the command below.

sh tbagent_start.sh

Upon restart, a selection prompt like the following is displayed.

============================================
 DB Agent config.json generation script
============================================
▲ Warning: The config.json file already exists.
 1) Overwrite the existing config.json and continue
 ▲ Warning: If you perform this operation on a normally installed/registered host, the Agent starts
 with the new config.json, and OwlDB can no longer identify that host.
 2) Use the existing config.json as is and continue
 3) Cancel

The following sets forth attribution notices for third party software that may be contained in this application. We thank the open source community for all of their contributions.

Noto is a trademark of Google Inc. Noto fonts are open source. All Noto fonts are published under the SIL Open Font License, version 1.1.

Some files or modules of this product comply with the following licenses.

During the database discovery process, there may be cases where the relationships between some nodes cannot be accurately identified. In this case, perform manual configuration using the method below.

1. Move to the Agent installation path of all related DB nodes.

2. Create the db_scan.info file on each node.

3. Enter the same TSC ID in the file.

tsc_id={unique numeric value}

For example, in the case of a TSC cluster consisting of 4 nodes, configure it as follows.

This is the common preparation procedure for database servers managed by OwlDB. For other procedures that differ depending on the configuration method, such as disk requirements, network settings, and deployment file configuration, refer to the and the respectively.

In a DR configuration, OwlDB transfers data files between nodes via SCP. For this, a dedicated OS user is created on each node, and a shared key pair is distributed to enable SSH access without a password.

The example values used in the procedure below are as follows. Please substitute them to match your actual environment.

• DB OS user: opensql

The initial ID and password for the Root account are as follows.

On the Data Space page, you can view and manage the data storage units of a DB service.

The screen layout and available features vary depending on the engine type of the connected DB service.

When Error: Environment variable 'OPENSQL_HOME' is not set. is output during installation

The environment variables required by the installation script are not set. Set all three — OPENSQL_HOME, PG_HOME, PG_DATA_DIR — and then run it again.

export OPENSQL_HOME=/opt/postgresql
export PG_HOME=/opt/postgresql
export PG_DATA_DIR=/opt/postgresql/data

When the server is not displayed in the backup server list

The OwlDB Agent is not registered with the OwlDB server.

systemctl is-active owldb-barman-agent.service owldb-barman-agent.timer
cat /var/lib/barman/owlagent_dist/owlagent.env

Check whether AGENT_TYPE is barman, and whether IP and PORT match the OwlDB server address. If you made changes, stop it with owlagent_stop.sh and then run owlagent_start.sh again.

There is no NOPASSWD sudo configuration for the barman account.

If OK is not output, check whether the sudo package is installed (rpm -q sudo) and whether the /etc/sudoers.d/barman file exists.

The WAL retention method was selected as archiver or archiver+streaming, but barman-cli is not installed on the database server. Install it by referring to 1-2.

The name of the systemd template unit or the configuration file path may differ from OwlDB's fixed value.

Check whether the unit name is barman-agent@.service and whether ExecStart reads /var/lib/barman/agent/%i.config.yml. Even if you set barman_home to a different path, this path is fixed.

You may not have run systemctl daemon-reload after creating the unit file. systemctl cat reads the file directly, so it still produces normal output in this case.

If WAL archive and continuous archiving among the barman check items fail, Health is displayed as not connected. This is a state where WAL is not being transmitted from the database server to the Barman server.

Check the failed items on the OpenBackup server.

If WAL archive: FAILED or continuous archiving: FAILED is output, check whether the database server can connect to the OpenBackup server. Run this as the OpenSQL account on the database server.

Also check the opposite direction (OpenBackup server → database server). This direction corresponds to the ssh item of barman check.

If the connection fails, check whether the private key file path matches BARMAN_SSH_KEYPATH in owlagent.env and whether the database server allows that key.

The database server remembers the host key of the previous OpenBackup server and refuses the connection. This occurs when the OpenBackup server is reinstalled with the same IP.

When you attempt to connect from the database server, the output is as follows.

Remove the relevant item on all database nodes and then integrate again.

The connection settings created by OwlDB automatically accept only the host key of the server on first connection, so when the host key has changed, you must clean it up manually as shown above.

path_prefix is not set in /etc/barman.conf. Set it to the PostgreSQL client executable path. Since cron re-reads the configuration file each time, you do not need to restart the service.

The barman version on the OpenBackup server differs from the barman-cli version on the database server. Check that both are 3.11.1.

In the Account Management menu, you can view and manage all accounts registered in OwlDB.

Account role guide

Root

A Root account can create, view, and edit Member accounts, and can grant or revoke access permissions for specific DB Services. It can also use the database installation, DB Service registration, and infrastructure discovery features.

When a user without an account (a sign-up applicant) requests account creation, the request is forwarded to Root, and once Root approves it, the account is activated.

Member

A Member can use the operation and management features provided by OwlDB (monitoring, backup/recovery, parameter management, etc.) only for the DB Services to which Root has granted them access. A user without an account (a sign-up applicant) can request the creation of their own account from Root.

Permission matrix by role

When you enter the Account Management menu, you can view the list of all accounts registered in OwlDB. You can filter by account status, or search by ID, name, or email.

Account status

You can directly create a new Member account.

1. In the Account Management menu, click the Create button.

2. Enter the account information (ID, name, password, etc.).

3. If necessary, you can also grant DB Service access permissions at the same time.

4. Clicking the Create button completes the account creation.

When the account is created, a permission grant notification is sent to that Member.

Clicking a user ID in the account list lets you view the detailed information of that account. You can view and edit the detailed information of all accounts, including your own.

The items you can view are as follows.

• ID, name, role, email

• Granted DB Service permissions

• Account status, creation date, last access date, modification date

To edit, click the Edit button on the detail page.

When a user without an account requests account creation, the request appears in the Account Management menu with the Account Requested status.

When Root changes the account to the Active status, the account is activated.

1. In the Account Management menu, select the account to delete.

2. Click the Delete button.

3. In the confirmation modal, clicking the Delete button immediately blocks access for that account.

In My Page > Manage My Information, you can view and manage the basic profile and permission status of the currently logged-in account.

Through My Information lookup, users can check in real time not only their basic information such as ID, name, and email, but also their currently assigned role (Root/Member) and the list of DB Service permissions they belong to.

View my account information

View the detailed information of your own account.

Edit the detailed information of your own account. The ID, role, and permissions are shown for reference only and cannot be edited.

The * notation indicates a required input item.

On the Backup Settings page, configure the automatic backup scheduler and check its operational status. In an On-Premise environment, Full Backup and Incremental Backup are configured independently.

Clicking Management > Backup Settings displays the current automatic backup configuration information. In an On-Premise environment, Full Backup and Incremental Backup are displayed separately.

1. Click Management > Backup Settings.

2. Click Edit.

OwlDB can restart a database in a single-instance or multi-instance configuration.

Menu path

The database restart feature can be accessed from the following menu paths.

• OwlDB console screen > Dashboard

• OwlDB console screen > Overview > Instance tab

• OwlDB console screen > Overview > Instance details

Restart button

The Restart button is enabled according to the DB Service's Status. The detailed enablement and selection conditions based on Status and Health are described below in 'Restart conditions'.

When you click the Restart button, the restart options modal appears.

The database restart behaves differently depending on the state of the selected instance.

The Restart button is enabled when the DB Service's Status is one of Running, Degraded, Down, Updating, or Failover. However, the list of instances selectable in the modal is limited according to each instance's Health status.

In the following Status states, the Restart button is disabled.

• Provisioning

• Stopped

• Terminating

• When all instances are selected: Status changes to Updating - In Progress

• When some instances are selected: Status changes to Degraded - In Progress

The way to restart a database is as follows.

1. Go to the OwlDB console screen > Dashboard menu.

2. Select the database to restart.

3. Click the Restart button. You can also restart from the Overview > Instance tab or Overview > Instance details menu.

4. When the "Do you want to restart {instance alias}

1. Click the Restart button.

Once the restart operation begins, you can check the progress by clicking the notification icon at the top right of the console screen. After the restart is complete, verify that the DB Service's Status has changed normally.

When you click the Discover button on the OwlDB screen, the OwlDB Agent automatically collects the configuration information of the customer infrastructure where it is installed, allowing you to grasp the status on the dashboard.

1. Go to OwlDB Console screen > Dashboard.

2. Click the Discover button.

3. The discovery results are retrieved as a total of 4 items, and for details on each item, refer to the Discovery Results

This page prepares the server environment for OpenSQL-based database installation. It downloads the distribution files and places them in the installation directory, installs the required packages and owlagent, and then performs environment validation.

1. List of required files

• owldb dp binary (owldb_dp_installer_owl_x.x.x.tar.gz)

• OpenSQL binary (Tmax_OpenSQL_*.tar.gz)

• license file (license.xml)

Create the path where the database will be installed (hereafter the installation directory). (Example: /home/rocky/owldb)

The {installation directory}/opensql path is used as $OPENSQL_HOME in subsequent procedures.