Overview

Today’s enterprise business is rapidly expanding due to explosive data growth and the emergence of diverse environments and platforms. With the advent of new business environments, more efficient and flexible data services, information processing, and data management capabilities have become necessary.

Tibero supports the database infrastructure that forms the foundation of enterprise business implementation, addressing issues of high performance, high availability, and scalability. It is an enterprise database management system.

To overcome the shortcomings of existing databases, Tibero adopts and implements a proprietary Tibero Thread Architecture. This efficiently utilizes limited server process CPU, memory, and other system resources while ensuring excellent performance, stability, scalability, and providing a convenient development environment and management features.

From its initial design, Tibero was developed with differentiation from other DBMSs in mind, focusing on large-scale users, massive data volumes, enhanced stability, and improved compatibility.
Tibero is thus a representative database providing the optimal database environment desired by enterprises.

Method

Basic Functions as a Database

Tibero guarantees the persistence and consistency of the database through transactions, which are bundles of SQL statements, by ensuring the following four properties.

• Atomicity

  All-or-nothing. This means that either all the actions performed by a transaction are applied, or none are applied. Tibero uses undo data to ensure this.

   

• Consistency

  Transactions can violate database consistency in various ways.

  A simple example is when tables and indexes contain different data, breaking consistency.

  To prevent this, Tibero ensures that partial application of a transaction’s changes to itself or others is blocked.

  For example, even if only the table has been modified and the index not yet updated, other transactions will see the table and index in a consistent state by viewing the previous version.

   

• Isolation

  From the perspective of other transactions, a transaction appears to be running alone.

  While other transactions may wait to access data being modified, they do not receive errors stating that access is denied due to ongoing modification.

  To achieve this, Tibero uses Multi-Version Concurrency Control (MVCC) and row-level locking techniques.
  When reading data, MVCC allows references independent of other transactions.
  When modifying data, fine-grained row-level lock control minimizes conflicts, resolving access conflicts by waiting.

   

• Durability

  Tibero uses Redo logs and write-ahead logging techniques to ensure durability.
  When a transaction commits, the corresponding Redo log is written to disk, guaranteeing the transaction’s persistence.

  Also, before a block is written to disk, its Redo log is always written first to maintain overall database consistency.

Tibero Architecture

[Figure 1] Tibero Architecture

• Tibero is divided into Instance area and Database area.
• The Instance consists of the TSM (Tibero Shared Memory) area, Worker Process area,
  Background Process area, and Process Monitor.
• The Database area includes Log Data, Log File areas, and others.

Tibero Process Structure

[Figure 2] Tibero Process Structure

Tibero processes are broadly classified into three types.

• Listener Process:
  •  LSNR
• Worker Process:
  • CTHR (Control Thread)
  • WTHR (Worker Thread)
• Background Process:
  • MONP (Monitor Process)
  • DBWR (Database Write Process)
  • MGWP (Tibero Manager), AGENT (Agent)
  •  RCWP (Recovery Worker Process)
  • PEWP (Parallel Execution Worker Process)

Listener Process

• The Listener accepts new client connection requests and assigns them to idle Worker Processes.

  It acts as a relay between the client and WTHR, operating via a separate executable called tblistener.

  From Tibero 6 onward, it is created by MONP and will be restarted automatically if forcibly terminated externally.

   

• The sequence for handling new client connection requests is as follows:

  1. Client initiates connection request.

  2. Listener Process finds a Worker Process with an idle Worker Thread (WTHR) and assigns the client connection.

  3. The client is assigned along with a file descriptor at the moment of request, so it behaves as if connected directly to WTHR from the start, independent of internal server operations.

  4. The control thread (CTHR) that receives the listener request checks the status of its Worker Process and assigns the client connection to an idle WTHR.

  5. The assigned WTHR performs client authentication and starts the session.

Worker Process

[Figure 3] Worker Process Structure

• This process communicates directly with clients and handles user requests.
• The number of these processes can be controlled via the WTHR_PROC_CNT initialization parameter and cannot be changed after Tibero starts.
• From Tibero 7, Worker Processes are divided into two groups based on their purpose.
• Foreground Worker Process (FGWP) handles online requests coming through the listener.
• Background Worker Process (BGWP) executes internal tasks or batch jobs registered with the job scheduler.
  The group size can be adjusted with the MAX_BG_SESSION_COUNT initialization parameter.
• Tibero operates on a thread-based model for efficient resource utilization.
• By default, one Worker Process contains one CTHR and ten WTHRs.
• Worker Processes perform tasks via CTHR and WTHR.
• CTHR (Control Thread)
  • One is created per Worker Process, and at Tibero startup, the configured number of WTHRs are created.
  • Handles signal processing.
  • Assigns new client connection requests to idle WTHRs.
  • From Tibero 7, supports I/O multiplexing and can send or receive messages instead of WTHR when necessary.

• WTHR (Worker Thread)

  • Communicates one-to-one with clients, receives client messages, processes them, and returns results.
  • Handles most DBMS tasks such as SQL parsing and optimization.
  • Remains alive even if the client disconnects, existing from Tibero startup until shutdown.
  • This design reduces system resource consumption and improves performance by avoiding frequent thread creation or removal during client connections.

   

   

  Background Process

   [Figure 4] Background Processes

  

  • They do not directly accept user requests but operate upon requests from WTHR or other background processes or on a scheduled basis, mainly handling time-consuming disk operations.
  • They operate asynchronously as independent processes relative to user requests.
     
  • Monitor Process (MONP)
    • From Tibero 6, the abbreviation changed from thread to process; it is an actual independent process.
    • Created first when Tibero starts and terminates last when Tibero shuts down.
    • Creates other processes including the listener at server startup.
    • Periodically checks the status of all processes.
    • Detects deadlocks.
       
  • Database Write Process (DBWR)
    • Periodically writes dirty blocks from the Database Buffer to disk.
    • A process containing threads related to writing database changes to disk.

    • Includes threads that periodically write user-modified blocks to disk, write Redo logs to disk, and a checkpoint thread that manages the checkpoint process.

       

  • Tibero Manager Process (MGWP)
    • A process for system management.
    • Accepts administrator connection requests and assigns them to WTHRs reserved for system management.
      It performs roles similar to Worker Processes but connects directly via a special port without going through the listener.

    • Only SYS account connections are allowed, and only from LOCAL.

       

    • Agent Process (AGNT)
      • Handles internal Tibero tasks that need periodic processing for system maintenance.

      • Operates in a multi-threaded structure, with threads assigned to different tasks.

         

  • Recovery Dedicated Process
    • Handles recovery and backup.
    • Responsible for advancing the boot phase after NOMOUNT during startup and determining if recovery is needed; if so, reads redo logs and performs recovery.
    • Also manages backup operations using tbrmgr or media recovery using backup copies.

[Example] Checking Tibero Processes on Linux

[Example] Checking Tibero Processes on Windows

Tibero Memory Structure

[Figure 5] Tibero Memory Structure

• A shared memory area holding data and control information for the instance.
• Composed of Database Buffer, Redo Log Buffer, SQL Cache, and Data Dictionary Cache.
• Background Processes allocate the TSM area when the instance starts and release it upon instance shutdown. The total size of the TSM is fixed at instance startup.
   
• SQL Cache
  • Stores and shares SQL statements, parse trees, and execution plans when users execute statements.
  • Loads compiled procedures or packages stored in the database when called by users.
• Data Dictionary Cache
• A part of the Shared Pool that holds Data Dictionary information stored in System Tablespaces.
• It loads system tables that store all objects and related information in the database.
• Since it is referenced and shared during SQL parsing for syntax and access checks, it is stored in the Shared Pool area.

•  If the Database Buffer hit ratio (next item) is below 95%, it indicates insufficient Shared Pool size and expansion should be considered.

   

• Database Buffer
  • The Database Buffer Cache loads data blocks from datafiles into memory during user SQL execution and shares them.
  • May contain modified data (Dirty Buffers) not yet fully written to disk.
  • All User Processes connected to the Tibero Instance share access to the Database Buffer Cache.
     
  • LRU List (Least Recently Used)
    • Manages buffers by storing the most recently used data in memory and writing the least recently used to disk, reducing disk I/O and improving database system performance. It includes Free Buffer, Pinned Buffer, and Dirty Buffer.
      • Free Buffer: An empty buffer used to read data from disk.
      • Pinned Buffer: Buffers currently in use by users.
      • Dirty Buffer: Buffers with modified data; when found during Free Buffer search, moved to the Dirty List.

• Dirty Buffer

  A buffer with data changed and needing to be written to data files by the DBWR process.

  If a server process fails to find a Free buffer of the desired size, it stops searching the LRU and signals the background DBWR process to write Dirty buffers to disk, freeing buffer space.

   

  • Process of reading data into the buffer cache

    The LRU list places frequently used data at the front and less frequently used data at the back.

    Starting from the front, it searches for the desired data; if not found, it frees buffers starting from the least recently used to make space for reading from disk.

    During the search for Free buffers, if Dirty buffers are found, they are moved to the Dirty list. Once a Free buffer of the desired size is found, data is read from disk into it.

     

  • Logical vs. Physical Reads

    Logical reads occur when data is read directly from memory (TSM), while physical reads happen when data is not in TSM and must be read from disk.

    Therefore, higher logical read rates yield faster performance. For OLTP systems, if the logical read hit ratio is below 90%, appropriate action should be considered.
     

    Hit Ratio = ( 1 – (Physical Reads / (DB Block Gets + Consistent Gets) ) ) * 100

Tibero Logical/Physical Structure

[Figure 6] Logical/Physical Structure

Tibero’s data storage structure is divided into two areas as follows:

• Logical Storage Area
  • Stores database schema objects.

  • The logical storage area has the following hierarchy:

    Database > Tablespace > Segment > Extent

  • Tablespaces consist of Segments, Extents, and Blocks.

[Figure 7] Physical Structure

Physical Storage Area

• Stores files related to the operating system.

• The physical storage area has the following hierarchy:

  Data File > Operating System Data Blocks

• DataFile: One tablespace links to one or more physical files (.dtf).
• Log File: Stores Redo Logs, which include all changes made in the database. Redo logs are critical for recovering committed transactions after fatal errors.
  • Redo logs consist of at least two or more log groups.

  • Tibero uses these log groups in a circular manner.
    For example, with three log groups:

    1. Logs are stored in Log Group 1.

    2. When Log Group 1 fills, logging continues in Log Group 2, then 3.

    3. After Log Group 3 fills, logging cycles back to Log Group 1.

    This switch from one log group to the next is called a Log Switch.

     

  • Each Redo Log contains one or more Log Records, which include all database changes, storing both previous and new values.
  • Tibero uses only one active log group at a time.
  • A log group may consist of one or more log members, a configuration called multiplexing.
    All log members in the same group must be the same size, store identical data, and be updated simultaneously.
    However, different log groups may have different numbers of log members and sizes.

Reference - TAC Structure

[Figure 8] TAC Structure Diagram

• Diagram of TAC for availability features.
• Heartbeat checks can be installed in network configurations and shared disk-based concurrent environments.