Chapter 1. Introduction to Tibero

Table of Contents

1.1. Overview
1.2. Key Features
1.3. Basic Properties
1.4. Row Level Locking
1.5. Process Structure
1.5.1. Listener
1.5.2. Worker Process
1.5.3. Background Process
1.6. Directory Structure

This chapter will briefly explain the major features, process structures, and directory structures of Tibero.

These days, corporate businesses are rapidly expanding amid increasing amounts of data and business environments. With the influx of new business environments, it has become a prerequisite for business success to provide more efficient and flexible data service, information processing, and data management techniques.

As an enterprise database management system, Tibero meets those needs by supporting the database infrastructure, a foundation for corporate businesses, with high performance, availability, and scalability.

Tibero adopted and implemented Tibero Thread Architecture as a unique technology to make up for the weak points of existing DBs. This enables cost-effective usage of system resources such as CPU and memory within limited server processes, by providing excellent performance, stability, and scalability, as well as an easy to use development environment and management tools.

Tibero has been developed to differentiate itself from other DBMSs in terms of large-scale user and data processing, improved stability, and enhanced compatibility.

In short,Tibero is a superior DB that provides the optimal environment for enterprises.

Tibero RDBMS, which manages massive data and ensures stable business continuity, provides the following key features required for the RDBMS environment:

Tibero guarantees reliable database transactions, which are logical sets of SQL statements, by supporting the following four properties:

  • Atomicity

    Each transaction is all or nothing; all results of a transaction are applied or nothing is applied. To accomplish this, Tibero uses Undo data.

  • Consistency

    Every transaction complies with rules defined in the database regardless of its result, and the database is always consistent. There are many reasons why a transaction could break a database's consistency. For example, an inconsistency occurs when a table and an index have different data. To prevent this, Tibero does not allow applying only a part of a transaction. That is, even if a table has been modified and a related index has not yet been modified, other transactions can only see the unmodified data. The other transactions think that there is consistency between the table and the index.

  • Isolation

    A transaction is not interrupted by another transaction. When a transaction is handling data, other transactions wait to access the data and any operation in another transaction cannot use the data. However, an error does not occur. To accomplish this, Tibero uses two methods: multiversion concurrency control (MVCC) and row-level locking.

    When reading data, MVCC can be used without interrupting other transactions. When modifying data, row level fine-grained lock controls can be used to minimize conflicts and to make a transaction wait. That is, concurrency is guaranteed by locking a row, which is the smallest data unit. Even if multiple rows are modified, Data Manipulation Language (DML) can still be executed despite a table lock. With these methods, Tibero provides high performance in an OLTP environment.

  • Durability

    Once a transaction has been committed, it must be permanent even if there is a failure such as a loss of power or a breakdown. To accomplish this, Tibero uses Redo logs and write-ahead logging. When a transaction is committed, relevant Redo logs are written to disk to guarantee the transaction's durability. Before a block is loaded on a disk, the Redo logs are loaded first to guarantee that the database has consistency.

Tiberouses row level locking to guarantee fine-grained lock control. That is, it maximizes concurrency by locking a row, the smallest unit of data. Even if multiple rows are modified, concurrent DMLs can be performed because the table is not locked. Through this method, Tibero provides high performance in an OLTP environment.

Tibero has a multi-process and multi-thread based architecture, which allows access by a large amount of users.

The following figure shows the process structure of Tibero:

Tibero has the following three processes:

  • Listener

  • Worker process or foreground process

  • Background process

A worker process communicates with client processes and handles user requests. Tibero creates multiple working processes when a server starts to support connections from multiple client processes. The number of working processes can be adjusted with the initialization parameter WTHR_PROC_CNT. This number cannot be modified after Tibero RDBMS starts. If the number of working threads increases, more CPU and memory resources are used. Therefore, the proper number of working processes should be specified based on the number of concurrent users and the system environment. Starting in Tibero 6, worker processes are divided into two groups based on their purpose. A background worker process performs the batch jobs registered in an internal task or job scheduler, while a foreground worker process performs online requests sent through the listener. The groups can be adjusted using MAX_BG_SESSION_COUNT, an initialization parameter.


For more information on the initialization parameter, refer to Tibero Reference Guide.

Tibero handles jobs using threads to efficiently use resources. One worker process consists of one control thread and multiple worker threads. A working process contains one control thread and ten worker threads by default.

The number of worker threads per process can be set using the initialization parameter _WTHR_PER_PROC, and after Tibero begins, this number cannot be changed, like WTHR_PROC_CNT. Therefore, the proper number of worker processes should be set based on the number of concurrent users and the system environment.

It is recommended to use the initialization parameter MAX_SESSION_COUNT instead of WTHR_PROC_CNT and _WTHR_PER_PROC to specify the maximum number of sessions provided by a server. The values of WTHR_PROC_CNT and _WTHR_PER_PROC are automatically set depending on the value of MAX_SESSION_COUNT.

If WTHR_PROC_CNT and _WTHR_PER_PROC are manually set, the value of WTHR_PROC_CNTWTHR_PROC_CNT * _WTHR_PER_PROC must be identical to MAX_SESSION_COUNT.

The value of MAX_BG_SESSION_COUNT must be smaller than the value of MAX_SESSION_COUNT, and it must be a multiple of _WTHR_PER_PROC .

A worker process performs jobs using the given control thread and worker threads.

Control Thread

Each worker process has one control thread, which plays the following roles:

Worker Thread

A worker thread communicates directly with a single client process. It receives and handles messages from a client process and returns the result. It handles most DBMS jobs such as SQL parsing and optimization. Because a worker thread connects to a single client, the number of clients that can simultaneously connect to Tibero RDBMS is equal to WTHR_PROC_CNT multiplied by _WTHR_PER_PROC. Because Tibero RDBMS does not support session multiplexing, a single client connection represents a single session. Therefore, the maximum number of sessions is also equal to WTHR_PROC_CNT multiplied by _WTHR_PER_PROC.

Even after a worker thread is disconnected from a client, it does not disappear. It is created when Tibero RDBMS starts and is removed when Tibero RDBMS terminates. This improves system performance as threads do not need to be created or removed even if connections to clients need to be made frequently.

However, a number of worker threads equal to the initialization parameter have to be created regardless of the number of clients. This unnecessarily uses OS resources, but is still practical for system operation because it takes few resources to maintain idle threads.many worker threads attempt to handle


If too many worker threads attempt to handle jobs at the same time without consideration for the CPU and memory resources, system performance may suffer due to heavy loads. Therefore, to build a massive scale system, it is recommended to install middleware between Tibero and application programs using a three-tier structure.

Background processes are independent processes that primarily perform time-consuming disk operations at specified intervals or at the request of a worker thread or another background process.

The following are the processes that belong to the background process group:

The following directory structure is created after installing Tibero.

    +- bin
    |   |
    |   +- update
    +- client
    |   |
    |   +- bin
    |   +- config
    |   +- include
    |   +- lib
    |   |   |
    |   |   +- jar
    |   |   +- php
    |   +- ssl
    |   |   |
    |   |   +- misc
    |   +- epa
    |   |   |
    |   |   +- java
    |   |       |
    |   |       +- config
    |   |       +- lib
    |   +- win32
    |   |   |
    |   |   +- bin
    |   |   +- lib
    |   +- win64
    |       |
    |       +- bin
    |       +- lib
    +- config
    +- database
    |   +- $TB_SID
    |       |
    |       +- java
    +- instance
    |   |
    |   +- $TB_SID
    |       |
    |       +- audit
    |       +- dump
    |       |  |
    |       |  +- act
    |       |  +- diag
    |       |  +- tracedump
    |       +- log
    |       |  +- dlog
    |       |  +- ilog
    |       |  +- lsnr
    |       |  +- slog
    |       |  +- sqltrace
    |       +- path
    +- lib
    +- license
    |  |
    |  +- oss_licenses
    +- nls
    |  |
    |  +- zoneinfo
    +- scripts
         +- pkg

The directories shown as $TB_SID in the previous directory structure is replaced by the server SID of the system environment.

The following are directories in Tibero.


Contains Tibero . The tbsvr and tblistener files are executables for creating the Tibero, and tbboot and tbdown are used to start up and shut down the Tibero.

The tbsvr and tblistener tbboot command.


Contains the following subdirectories.

  • bin

    Contains the following Tibero (utilities).

    tbSQLBasic client program for executing SQL queries and checking their results.
    T-UpUtility for migrating data to and checking compatibility with Tibero from another database.
    tbExportUtility for writing data to an external file for data migration or logical backup.
    tbImportUtility for importing data from an external file.
    tbLoaderUtility for loading a large amount of data into the database.
    tbpcUtility for converting embedded SQL in a C program to C so that the program can be compiled by a C compiler.

    For more information about the utilities, refer to Tibero Utility Guide. For the tbpc utility, refer to Tibero tbESQL/C Guide.

  • config

    Contains configuration file for executing a Tibero client program.

  • include

    Contains the header files for creating a Tibero client program.

  • lib

    Contains the library files for creating a Tibero . For more information, refer to Tibero Application Developer's Guide and TiberotbESQL/C Guide.

  • ssl

    Contains certificate and key files for server security.

  • epa

    Contains configuration and log files related to external procedures. For more information, refer to Tibero External Procedure Guide.

  • win32

    Contains the ODBC/OLE DB driver for 32-bit Windows.

  • win64

    Contains the ODBC/OLE DB driver for 64-bit Windows.


Contains the environment configuration files for Tibero. The $TB_SID.tip file in this directory contains the environment settings for Tibero.


Contains the following subdirectories.

  • $TB_SID

    Contains all database information unless it is configured separately. It includes the metadata and the following file types

    Control FileContains the location of all other files.
    Data FileContains the actual data.
    Log FileContains all data changes for use during data recovery.
  • $TB_SID/java

    Contains Java EPA class file unless JAVA_CLASS_PATH is defined.


Contains the following subdirectories.


Contains the spatial function library files for Tibero.


Contains the Tibero (license.xml). This XML file can be opened using a text editor to check its contents.

The following is the subdirectory.

oss_licensesContains the open license terms that must be complied with when using Tibero.

Contains the following subdirectory.

zoneinfoContains the time zone information file for Tibero.

Contains various SQL statements used when creating a database in Tibero. It also includes various view definitions that reflect the current state of Tibero.

The following is the subdirectory.

pkgContains the package creation statements for Tibero.