Skip to main content
๐Ÿ““ Tibero Online Manual Click here ๐Ÿ““

Search

Welcome to Tibero GTS!

Tibero Operation Management

Document Type | Technical Information

Category | Security

Applicable Product Version | 7FS02PS 6FS07_CS_2005

Document Number | TSETI018

 

Overview

This document describes the necessary contents for operating Tibero. 

 

 

Method

1. Starting and Stopping Tibero

This section explains the commands used to start and stop Tibero and how to use them. 

 

1.1. Environment Setup

  • tbboot must be executed on the device where Tibero is installed. Also, before running tbboot, environment variables must be properly set. The environment variables related to this command are $TB_HOME and $TB_SID for Unix-like systems.
     
  • Furthermore, anyone with permission to execute the executable files can start Tibero using tbboot. Therefore, due to potential security issues, it is recommended by policy to set permissions so that only the user who installed Tibero can access Tibero's executable files.

 

[Example] How to Set File Permissions

$ cd TB_HOME/bin
$ chmod 700 tbsvr tblistener tbboot tbdown tbctl
$ ls -la
total 491232
... omitted ...
-rwx------ 1 tibero tibero      2557 Jan 24 17:29 tbboot 
-rwx------ 1 tibero tibero     13869 Jan 24 17:29 tbctl 
lrwxrwxrwx 1 tibero tibero        30 Jan 27 21:27 tbdown -> /home/tibero/tibero7/bin/tbsvr
-rwx------ 1 tibero tibero  19899671 Jan 24 17:54 tblistener 
-rwx------ 1 tibero tibero 200758410 Jan 24 17:55 tbsvr
... omitted ...

 

 

1.2. DBMS Stages

 

[Figure 9] DBMS Startup Stages

  • Stage 1: Database Nomount
    • NOMOUNT: Instance startup stage
    • Database creation possible
    • Control File creation possible
  • Stage 2: Database Mount
    • MOUNT: Control File open stage
    • Datafile renaming possible
    • Online Redo Log File and Archive options can be enabled/disabled
    • Full database recovery operations possible
  • Stage 3: Database Open
    • OPEN: All files defined in the Control File are opened

 

1.3. Starting Tibero

  • DB startup methods
    • The Tibero Start procedure uses tbboot under $TB_HOME/bin or, in the Windows version, additionally the Service Control method.
  • DB startup procedure
    • This explains the startup method using tbboot.

 

[Example] Using tbboot

$ tbboot (Start Tibero)

$ tbboot โ€“v (Check Tibero engine version)

$ tbboot โ€“h 
Usage: tbboot [-h] [-v] [-l] [-C] [-t BOOTMODE]
  -h: show this help.
  -v: show RDBMS version.
  -p: show applied patches.
  -l: show license information.
  -C: show available character set list.
  -c: No replication mode.
  -w: wallet auto-login mode.
  -d: redirecting stdout to outfile mode. (not supported in Windows)
  BOOTMODE: one of NOMOUNT MOUNT RECOVERY NORMAL RESETLOGS ALTERDD READONLY FAILOVER
  If no bootmode is set, default bootmode is 'NORMAL'.

[Table 2] tbboot Usage

OptionDescription
 If no option is given, Tibero boots in NORMAL boot mode.
-hShows a brief help for using tbboot.
-vShows version information. (Same as -version)
-tServer startup mode option; can be omitted.

Description of DB startup modes

  1. Run in NORMAL mode
     

    • This mode allows the full functionality of the database.

      [Example] tbboot NORMAL mode

      $ tbboot
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (NORMAL mode).

Note 

If the database was shut down abnormally, Tibero automatically performs crash recovery when starting up.

  1. Run in NOMOUNT mode
  • This mode only starts Tibero's processes. Generally, this mode is rarely used.
     

  • After Tibero starts, the only operation is to create a database using the CREATE DATABASE statement.

    [Example] tbboot NOMOUNT mode

     

    $ tbboot nomount
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (NOMOUNT mode).
  1. Run in MOUNT mode

  • This mode is used for media recovery. 

    [Example] tbboot MOUNT mode

    $ tbboot mount
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (MOUNT mode).
  1. Run in RESETLOGS mode

  • This mode initializes the log files during server startup and is used after media recovery. It is used for incomplete recovery.

    [Example] tbboot RESETLOGS mode

    $ tbboot mount
Change core dump dir to /sdiske/ps1/pjha/tibero7/bin/prof.
Listener port = 8629

Tibero 7

TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Tibero instance started up (NORMAL RESETLOGS mode).

 

1.4. Stopping Tibero

 

DB shutdown methods

  • The Tibero shutdown procedure uses tbdown under $TB_HOME/bin or, in the Windows OS version, additionally the Service Control method.

DB shutdown procedure

  • This explains the shutdown method using tbdown.

    [Example] DB shutdown method

    $ tbdown
$ tbdown -h
Usage: tbdown [-h] [-t DOWNMODE]
  DOWNMODE : NORMAL, POST_TX, IMMEDIATE, ABORT, SWITCHOVER, ABNORMAL

    [Table 3] tbdown Option Descriptions

    Option

    		Description

     

    		If no option is given, Tibero shuts down in normal mode.

    -h

    		Shows brief help for using tbdown.

    -t

    		Options for shutting down Tibero. This option can be omitted.

 

Note 

If Tibero is abnormally terminated by system internal commands such as kill, shared memory or semaphore resources used during operation
may not be released.

In such cases, restarting will fail, and after such abnormal server shutdown, you must first run "tbdown clean" to release existing resources before restarting.

Even if terminated abnormally, if the initialization parameter โ€œBOOT_WITH_AUTO_TBDOWN_CLEANโ€ is set to Y, it automatically releases previously used resources and boots up. 

However, administrators may not properly recognize the abnormal server shutdown and continue server operation, 

which may cause exceptional situations where existing resources or processes are not properly cleaned up, leading to conflicts. Therefore, it is not recommended to enable the โ€œBOOT_WITH_AUTO_TBDOWN_CLEANโ€ option.

 

DB Shutdown Mode Descriptions

[Table 4] DB Shutdown Modes

Shutdown ModeDescription
NORMALStandard shutdown mode.
POST_TXWaits for all transactions to complete before shutting down Tibero.
IMMEDIATEForcibly terminates all ongoing operations, rolls back all transactions in progress, and shuts down Tibero.
ABORTForcibly terminates Tibero processes.
SWITCHOVERSynchronizes Standby DB with Primary DB and then shuts down Primary DB like NORMAL mode.

 

Run in NORMAL mode

  • This is the standard shutdown mode.

  • The SYS user connects to the RDBMS and then waits until all other sessions disconnect before shutting down the server. Once tbdown is executed, no user can connect to the database any longer. However, users already connected before tbdown was run can continue to use the database without restrictions until they disconnect themselves.

    [Example] tbdown NORMAL mode

    $ tbdown immediate

Tibero instance terminated (IMMEDIATE mode).

Run in POST_TX mode

  • Waits for all transactions to complete before shutting down Tibero.
  • In POST_TX, the SYS user connects to Tibero and waits until all transactions finish, then shuts down Tibero. Once tbdown starts, no new connections to the database are allowed, and no new transactions can start on already open sessions. However, ongoing transactions can continue until commit or rollback, at which point the connection is automatically terminated.

  • Also, when tbdown starts, it does not send a server shutdown message to connected clients immediately. Utilities like tbSQL will only detect that Tibero has shut down when the next command is executed.

    [Example] tbdown POST_TX mode execution

    $ tbsql admin/password123
tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. Connected to Tibero.
SQL> CREATE TABLE T1 (COL1 NUMBER);
Table โ€˜T1โ€™ created.
SQL> INSERT INTO T1 VALUES(10);
1 row inserted.
SQL> SELECT * FROM T1;
COL1
----
10
1 row selected.

  • At this point, execute tbdown POST_TX command.

     

  • tbdown waits for transactions to finish. 

     

    SQL> COMMIT; Commit completed.

     

  • At this point, the server actually shuts down and tbdown finishes.

     

    SQL> SELECT * FROM T1;
TBR-2069: I/O read error

     

  • Since the server is shut down, the tbSQL utility raises the TBR-2069 error.

Run in IMMEDIATE mode

  • Forcibly terminates all ongoing operations, rolls back all transactions in progress, and shuts down Tibero.
  • In IMMEDIATE, the SYS user connects to Tibero, forcibly terminates all ongoing operations, rolls back all transactions, and then shuts down Tibero. Clients are not immediately notified of the shutdown, similar to POST_TX mode.

  • If transactions are long-running, rollback may take some time.

    [Example] tbdown IMMEDIATE mode

    $ tbdown immediate

Tibero instance terminated (IMMEDIATE mode).

ABORT mode

  • Forcibly terminates Tibero processes.

  • ABORT sends SIGTERM signals to all Tibero processes without connecting to Tibero. This mode is used in emergencies and can only be run on the server, not remotely. 

    Recovery is required on the next startup.

    It is recommended to use ABORT only in limited cases such as:

    • When normal shutdown is impossible due to internal Tibero errors, e.g., when all sessions are busy and client connections increase.
    • When hardware problems or emergency situations such as hacking require immediate shutdown.
  • ABORT forcibly terminates Tibero without releasing system resources. Thus, shared memory, semaphores, and log or data files may remain after shutdown. Recovery may take longer on next startup.
     
  • ABORT is recommended only in cases such as:
    • Internal errors preventing normal shutdown.
      E.g., all sessions busy with increasing client connections.
    • Hardware failures or emergencies requiring immediate shutdown.

SWITCHOVER mode

  • SWITCHOVER is used in Tibero Standby Cluster (TSC) to synchronize Standby and Primary DBs, then shut down Primary DB in NORMAL mode.

 

2. Memory Management

  • Tibero sets a TSM area in memory for fast I/O processing. Larger TSM is better but limited by physical server memory. Excessive TSM size without sufficient physical memory causes paging at the OS level, degrading overall system performance.
     
  • Memory is broadly divided into System Memory (cf. Oracle's PGA) and Shared Memory (cf. Oracle's SGA).

 

[Figure 10] Overall Memory Structure

 

 

2.1. Memory Configuration Environment

  • The following figure shows the logical memory structure. 

    [Figure 11] Logical Memory Structure

  • The following figure shows memory parameters and areas. 

    [Figure 12] Memory Parameter (TSM) Structure

[Table 5] Current Memory Settings

CategoryLogical AreaParameterValue (Example)
Total MemoryTSM (Tibero Shared Memory)TOTAL_SHM_SIZE10240M
Database buffer cache sizeDatabase BufferDB_CACHE_SIZE6800M
Redo Log buffer sizeRedo Log BufferLOG_BUFFER10M
Shared cache sizeShared Cache TOTAL_SHM_SIZE - (DB_CACHE_SIZE + LOG_BUFFER + alpha)
PGA AreaPGAEX_MEMORY_HARD_LIMITSame as TOTAL_SHM_SIZE if not set

 

 

2.2. How to Set Memory

  • Memory settings are modified in the $TB_HOME/config/$TB_SID.tip file.
  • Modify the Parameter (TIP) file and restart, or adjust sizes dynamically.
    Dynamic application depends on parameters. Refer to the parameter manual for details.

 

2.3. Memory Operation Procedures

  • Dynamic memory size adjustment

    • Adjust PGA size โ€œEX_MEMORY_HARD_LIMITโ€
    • Modify via tbsql

    • Settings reset after Tibero restart, so if you want to keep the change, also apply it in the TIP file for persistence.

      • Syntax: alter system set EX_MEMORY_HARD_LIMIT=<new value>

      [Example] Dynamic PGA Memory Adjustment

      $ tbsql sys/tibero
tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
      SQL> show param EX_MEMORY_HARD_LIMIT

NAME                         TYPE     VALUE
---
EX_MEMORY_HARD_LIMIT         INT64    8589934592

1 row selected.
      SQL> alter system set EX_MEMORY_HARD_LIMIT=1073741824;

System altered.

SQL> show param EX_MEMORY_HARD_LIMIT

NAME                         TYPE     VALUE
---
EX_MEMORY_HARD_LIMIT         INT64    1073741824

1 row selected.

    Static memory size adjustment

    • Modify memory settings in $TB_HOME/config/$TB_SID.tip file. 

    • After modification, run tbdown > tbboot commands.

      [Example] Adjusting TOTAL_SHM_SIZE

      # RDBMS tip file generated from C:\Tibero\tibero7\config\tip.template(11 7 17:22:35 2023)
#---------------------------------------------------------------------
# RDBMS initialization parameter
#---------------------------------------------------------------------โ€ฆ โ€ฆ
...
TOTAL_SHM_SIZE=8192M
...

    How to execute memory dump

    • System Memory area (=PGA)
      • Dump files are created as ".trc" files under $TB_HOME/instance/$TB_SID/dump/tracedump directory.

      • Mainly used when TBR-3003 error (ERROR_OUT_OF_PHYSICAL_MEM) occurs. Dump data can be sent to Tibero for analysis.

        [Example] System Memory Dump

        SQL> alter system dump systemalloc;

System altered.

    Shared Pool area (=SGA)

    • Dump files are created as ".trc" files under $TB_HOME/$TB_SID/dump/tracedump directory.

    • Mainly used when TBR-3002 error (ERROR_OUT_OF_SHP) occurs. Dump data can be sent to Tibero vendor for analysis.

      [Example] Shared Pool Memory Dump

      SQL> alter system dump shared pool;

System altered.

    Flush execution

    • Flushing only the Library Cache can cause temporary waits due to rebuilding all query information. Avoid running during operation.

    • Use case: When resetting cached SQL execution plans

      [Example] Shared Pool Memory Flush

      $ tbsql sys/tibero

tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. 

Connected to Tibero.

SQL> alter system flush shared_pool;

System altered.

Note

 To initialize Buffer Cache, use the command alter system flush buffer_cache;.

 

2.4. Memory Operation Reference

 

System Memory Reference

  • cf. PGA in Oracle
  • Fixed area
    • Basic memory allocated from boot time via malloc.

    • The following parameters are allocated per WTHR (worker thread). 

      [Table 6] System Memory Related Parameters

      ParameterDescription
      SQL_LOG_ON_MEMORY_SIZEBuffer size per thread when using sql_log_on_memory. (Default 100k)
      LOG_ON_MEMORY_SIZEBuffer size per thread when using log_on_memory. (Not recommended for production)
  • Allocator + Free: Initially occupies _SYSTEM_MEMORY_RESERVED_SIZE, expands by _SYSTEM_MEMORY_EXPAND_SIZE (default 4MB) as needed, and releases when unnecessary. Can increase up to EX_MEMORY_HARD_LIMIT.
  • Allocator reserves _SYSTEM_MEMORY_RESERVED_SIZE at creation and mallocs _SYSTEM_MEMORY_EXPAND_SIZE when current memory is exhausted.

Shared Memory Reference

  • Fixed area: DB_CACHE_SIZE, LOG_BUFFER, alpha
  • Shared_pool area: Memory for TAC (cf. Oracle's RAC) (shp_for_ccc, shp_for_cws) and minimum shared_pool (_MIN_SHARED_POOL_SIZE) spare shared_pool
     
    1. Memory for TAC
      • CCC (Cluster Cache Control): Module controlling cluster access to database data blocks. Includes built-in DLM. Includes CR Block Server, Current Block Server, Global Dirty Image, Global Write services. Cache Layer accesses CCC via GCA. Background processes include LASC, LKDC, RCOC.
      • CWS (Cluster Wait-lock Service): Module enabling Wait-lock (Wlock) to operate in cluster. Built-in Distributed Lock Manager (DLM). Wlock accesses CWS via GWA. Background processes include LASW, LKDW, RCOW. Previous Tibero versions only protected single instance resources; TAC supports multi-instance synchronization via CWS.

      • Example calculation

        shp_for_ccc = 416 * CCC_RECL_MAX_RESOURCES (= 0.273 * DB_CACHE_SIZE )
= 416 * 5632K = 2288M

shp_for_cws = 368 * CWS_RECL_MAX_RESOURCES(= 89750 * WTHR_PROC_CNT *  WTHR_PER_PROC )
= 368 * 215K = 77M

        [Table 7] Memory for TAC

        ParameterDescription
        CCC_RECL_MAX_RESOURCESSets maximum number of CCC resource blocks maintained in memory.
        CWS_RECL_MAX_RESOURCESSets maximum number of CWS resource blocks maintained in memory.

Minimum shared_pool

  • Minimum shared pool calculation formula

    _MIN_SHARED_POOL_SIZE = 1M * WTHR_PROC_CNT * WTHR_PER_PROC
= 1M * 300 = 300M (theoretical value)
= Site _VT_PARAMETER set value = 300M

Note) Minimum bootable SHM
shared_pool > shp_for_ccc + shp_for_cws + _MIN_SHARED_POOL_SIZE
= shared_pool > 0 + 0 + 300M = 300M

  • Minimum DB_CACHE_SIZE at boot: The minimum cache size is set to accommodate simultaneous multi-block reads by all threads. The current DB Cache Size of 6800M can hold 870,400 blocks. One quarter of this area is used as the LRU victim area. If no victim is found in this area, blocks are evicted from LRU to secure victims. Therefore, within 217,600 blocks (870,400 / 4), all threads' multi-block reads must be possible.

    < Calculation for 300 Sessions >
300(Session) * 64(DB_FILE_MULTIBLOCK_READ_COUNT) * 8192(One Block Size) 
* 4 (Space required for LRU method: 4 times) 
= 600M DB Cache size needed.

     

Note
LRU (Least Recently Used) method: Selects the cache line that has not been used for the longest time as the next victim.
Victim: Cache line selected for replacement.

 

3. Process Management

  • Describes how to manage background processes of the running DBMS.
     
  • Listener: Unlike Oracle, it is not an independent process but managed like a background process.
     
  • Foreground Process: Includes WTHR (Working Thread), CTHR (Control Thread), etc. They handle user requests and consume the most resources. Multiple threads exist within multiple processes, with a 1:1 session-to-thread mapping (Dedicated Server). Shared Server is not supported.
     
  • Background Process: Does not directly accept client connections but operates on requests from working threads or other background processes or at scheduled intervals, mainly handling long disk operations.
     
  • Background processes include MONP (monitor process), MGWP (manager worker process), AGNT (agent process), DBWR (database writer), RCWP (recover worker process).
     
  • The number of DBWR processes may vary depending on settings or CPU core count (parameter DBWR_CNT).

 

3.1. Process Configuration Environment

  • Tibero listener does not run as an independent process like Oracle. 

  • Check processes on Node1 (Active) server; Node (Standby) is down.

    [Example] Checking processes

    $ tbdown pid

1634: MONP 
1636: MGWP 
1637: FGWP0000 
1638: FGWP0001 
1639: PEWP0000 
1640: PEWP0001 
1641: PEWP0002 
1642: PEWP0003 
1643: AGNT 
1644: DBWR 
1645: RCWP
    $ ps โ€“ef | grep tbsvr

tibero   23948 23874  0 19:56 pts/18   00:00:00 tbsvr_MGWP     -t NORMAL -SVR_SID tibero
tibero   23949 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP000  -t NORMAL -SVR_SID tibero
tibero   23950 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP001  -t NORMAL -SVR_SID tibero
tibero   23951 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP002  -t NORMAL -SVR_SID tibero
tibero   23952 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP003  -t NORMAL -SVR_SID tibero
tibero   23953 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP004  -t NORMAL -SVR_SID tibero
tibero   23954 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP005  -t NORMAL -SVR_SID tibero
tibero   23955 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP006  -t NORMAL -SVR_SID tibero
tibero   23956 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP007  -t NORMAL -SVR_SID tibero
tibero   23957 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP008  -t NORMAL -SVR_SID tibero
tibero   23958 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP009  -t NORMAL -SVR_SID tibero
tibero   23959 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP010  -t NORMAL -SVR_SID tibero
tibero   23960 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP011  -t NORMAL -SVR_SID tibero
tibero   23961 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP012  -t NORMAL -SVR_SID tibero
tibero   23962 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP013  -t NORMAL -SVR_SID tibero
tibero   23963 23874  0 19:56 pts/18   00:00:00 tbsvr_FGWP014  -t NORMAL -SVR_SID tibero
tibero   23964 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP000  -t NORMAL -SVR_SID tibero
tibero   23965 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP001  -t NORMAL -SVR_SID tibero
tibero   23966 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP002  -t NORMAL -SVR_SID tibero
tibero   23967 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP003  -t NORMAL -SVR_SID tibero
tibero   23968 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP004  -t NORMAL -SVR_SID tibero
tibero   23969 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP005  -t NORMAL -SVR_SID tibero
tibero   23970 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP006  -t NORMAL -SVR_SID tibero
tibero   23971 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP007  -t NORMAL -SVR_SID tibero
tibero   23972 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP008  -t NORMAL -SVR_SID tibero
tibero   23973 23874  0 19:56 pts/18   00:00:00 tbsvr_PEWP009  -t NORMAL -SVR_SID tibero
tibero   23974 23874  3 19:56 pts/18   00:00:00 tbsvr_AGNT     -t NORMAL -SVR_SID tibero
tibero   23975 23874  6 19:56 pts/18   00:00:00 tbsvr_DBWR     -t NORMAL -SVR_SID tibero
tibero   23976 23874  1 19:56 pts/18   00:00:00 tbsvr_RCWP     -t NORMAL -SVR_SID tibero
tibero   24715 22408  0 19:56 pts/18   00:00:00 grep --color=auto tb

 

 

3.2. How to Configure Processes

  • Foreground Process: Depends on the number of sessions set in the TIP file (parameter MAX_SESSION_COUNT).
  • Background Process: For DBWR, the number of processes started can vary depending on TIP settings or CPU core count (parameter DBWR_CNT).

 

3.3. Process Operation Procedures

  1. Check processes using Tibero commands
     
    • Check by running โ€œtbdown pidโ€ in command prompt (Windows) or terminal (Unix, Linux). 
       
  2. Check processes registered in the system
     
    • On Unix, Linux systems
    • Command: ps -ef | grep tibero (tibero is the user who installed Tibero)
    • On Windows system

      • Command: tasklist /FI "IMAGENAME eq tb*"

        [Example] Task image check (Windows)

         C:\Tibero\tibero7\scripts>tasklist /FI "IMAGENAME eq tb*"
 
  Image Name                 PID Session Name              Session#  Memory Usage
  ====================== ======== ================ =========== ============   
  tbsvr.exe                 22580 Services                   0  1,417,104 K
  3. System reboot after process termination
    • If any background process other than Working Process is down, TIBERO DBMS shuts down automatically to maintain consistency.
    • Check processes
      • On Unix, Linux: use "ps -ef | grep tb*" or "tbdown pid" commands.
      • On Windows: use "tasklist /FI "IMAGENAME eq tb*" to check task images and "tbdown pid" for processes.
      • Actions per process
      • If abnormal termination due to process down, always run "tbdown clean" then "tbboot".

 

3.4. Process Related Reference

  • One Executable Binary

    [Figure 12] tbsvr Management Form

  • Monitor Thread forks Foreground and Background Processes.
  • If a background process dies, MTHR detects and kills the entire server. Behavior on foreground process failure depends on options.
  • Listener and Server relationship: Unlike Oracle, Tibero's listener is not an independent process but exists as a background process with the server.

 

Foreground Process

[Figure 13] Foreground Process

  • Tibero operates as multi-process with threads.
  • Process to thread ratio setting (WTHR_PROC_CNT : WTHR_PER_PROC)
  • Operational guide: Increasing process count increases memory usage and improves performance under load. Increasing thread count reduces memory usage but lowers performance under load. If memory resources are ample, increase process ratio for better performance. (WTHR_PER_PROC fixed at 10)
    *Note (for AIX older versions)
  • Note: Set WTHR_PER_PROC to 15 or less in TIP file
  • Reason: On AIX, sendmsg() system call supports up to 15 message queues; if more than 15 messages are requested simultaneously, connection fails may occur. Although rare, under high load with good hardware and network, connection failures may happen.
  • New client connection method
  • Connection method depends on HOST setting in tbdsn.tbr file.
  • General IP connects via TCP socket; localhost connects via domain socket.
  • If connection fails, check:
  • Listener logs to confirm requests; no logs if blocked by access control or firewall.
  • Verify TB_SID and TB_HOME environment variables.
  • Check network status with netstat.
  • Check listening or connected ports.
  • Tibero used ports
    • LISTENER_PORT(N): Default service port (mandatory)
    • _LSNR_SPECIAL_PORT(N+1): Special port used for tbdown and emergency actions (mandatory)
    • _LSNR_SSL_PORT(N+2): Used for SSL connections (when using secure communication)
       

Background process

  1. [Figure 14] Background Process Correlation

MONP (Monitor process)

  • From Tibero 6, the abbreviation changed from thread to process; it is an independent process. Created first on Tibero startup and terminates last on shutdown.
    Creates listener and other processes and periodically checks their status. Also checks for deadlocks.

MGWP (Tibero Manager Worker Process)

  • Process for system management. Accepts admin connections and assigns them to reserved worker threads. Functions like worker processes but connects directly via special port without listener. Only SYS account allowed.

AGNT (Agent Process)

  • Handles periodic internal Tibero maintenance tasks.
    Until Tibero 4 SP1, also saved sequence cache values to disk.
    From Tibero 5, each worker thread handles this. Previously called SEQW, renamed AGNT from Tibero 6 onwards. See "Tibero Administrator Guide" section 4.7.1 for sequence usage.

DBWR (Database Writer Process)

  • Handles threads related to writing changed data to disk. Includes threads that periodically write changed blocks and redo logs to disk, and checkpoint threads managing database checkpointing.

RCWP (Recovery Worker Process)

  • Handles recovery and backup. Raises boot stages after NOMOUNT, determines if recovery needed, reads redo logs to perform recovery. Also handles backup and media recovery via tbrmgr.

PEWP (Parallel Execution)

  • Parallel Execution Process (PEP) dedicated to parallel execution.
    Allocates WTHRs within one PEP for locality maximization. Separated from normal client session WTHRs for easier monitoring and management.

 

4. Tip File Management

  • Describes management methods for TIP files during operation. 

 

4.1. Tip File Configuration Environment

  • Tibero starts by reading a parameter file named $TB_SID.tip. 
    Unlike Oracle, which has PFILE (initSID.ora) and SPFILE (spfileSID.ora), Tibero has only the TIP file equivalent to PFILE.

    [Example] TIP File Settings

    # tip file generated from /home/tibero/tibero7/config/tip.template (TUE NOV 21 20:25:37 PDT 2023)
#-------------------------------------------------------------------------------
# RDBMS initialization parameter
#-------------------------------------------------------------------------------
DB_NAME=t7
LISTENER_PORT=9629
CONTROL_FILES="/home/tibero/tbdata7/c1.ctl" 
DB_CREATE_FILE_DEST="/home/tibero/tbdata7" 
LOG_ARCHIVE_DEST="/home/tibero/archive/t7" 

#CERTIFICATE_FILE="/home/tibero/tibero7/config/svr_wallet/t7.crt" 
#PRIVKEY_FILE="/home/tibero/tibero7/config/svr_wallet/t7.key" 
#WALLET_FILE="/home/tibero/tibero7/config/svr_wallet/WALLET"

MAX_SESSION_COUNT=96
TOTAL_SHM_SIZE=1024M DB_BLOCK_SIZE=8K
SQL_LOG_ON_MEMORY=Y

 

4.2. How to Set TIP File

Edit directly in the file and apply by running tbdown then tbboot.

 

4.3. TIP File Operation Procedure

To query: log in as sys with tbsql and run "show param" command. 

 

4.4. TIP File Related Reference

[Example] DB Parameter Query

tbSQL 7
TmaxTibero Corporation Copyright (c) 2020-. All rights reserved.
Connected to Tibero.
SQL> show param
NAME                         TYPE     VALUE
--------------------------  -------  --------
ACF_RCVR_CNT                 INT32    6
ACTIVE_SESSION_HISTORY       Y_N      NO
ACTIVE_SESSION_TIMEOUT       INT32    0
TPR_SNAPSHOT_RETENTION       INT32    7
TPR_SNAPSHOT_SAMPLING_INTERVAL INT32    60
TPR_SNAPSHOT_TOP_SQL_CNT   INT32    5
AUDIT_FILE_DEST              DIRNAME  /home/tibero/tibero7/instance/t7/audit/ AUDIT_FILE_SIZE              INT32    104857600
AUDIT_SYS_OPERATIONS         Y_N      NO
AUDIT_TRAIL                  STRING   NONE
.... omitted ...
USE_NET_KEEPALIVE            Y_N      NO
USE_PROFILE                  Y_N      YES
USE_RECYCLEBIN               Y_N      NO
USE_STORED_OUTLINES          Y_N      NO
USGMT_AUTO_SHRINK_INTERVAL   INT32    0
UTL_FILE_DIR                 DIRNAME  /home/tibero/tbdata7/psm/
WALLET_FILE                  STRING
WTHR_PROC_CNT                INT32    8 
WTHR_PROC_CNT_MAX            INT32    8
XA_MAX_BRANCH_CNT            INT32    1024
XA_TIMER_INTERVAL            UINT32   100
  • Among initialization parameters in the TIP file, there are static and dynamic parameters. Static parameters must be in the TIP file to apply, dynamic parameters can be changed during operation.

 

5. Control File Management

  • Describes how to manage Control files of the running DBMS.
     
  • Control files store the database's metadata in binary format.
     
  •  The initial control file is created when installing Tibero. Information about the initial control file is stored in $TB_SID.tip. Tibero can create and update control files.

 

5.1. Control File Configuration Environment

  • Control files are stored in binary and must be preserved by regular backups. 

 

5.2. How to Set Control File

  • DBAs can add or remove copies of control files. 
     
  • Control files are metadata of the DBMS; physical changes to control files are not possible while the database is running. 
     
  • Therefore, there are no SQL statements to add or remove control file copies. 
    You must shut down the database before changing control files.
     
  • Since there are no SQL statements for adding/removing control files, use OS commands to perform changes.
    Then update the changes in $TB_SID.tip file.

 

5.3. Control File Operation Procedure

  • Procedure: Copy the control file to another location for redundancy > tbdown > modify ${ServiceID}.tip file > tbboot
     
  • How to configure control file redundancy
     
    1. Tibero down (before/after TIP file modification)
      • Run tbdown to shut down Tibero DB.
    2. Copy control file
      • Example of copying control file on UNIX:
        $ cp /usr1/tibero/control01.ctl /usr3/tibero/control03.ctl
      • Example of copying control file on Windows:
        copy D:/tbdata/control01ctl D:/tbdata/control02.ctl
         
    3. Modify Control File parameter in TIP file

      • TIP file location: under $TB_HOME (current configuration basis) 

        CONTROL_FILES="/usr1/tibero/control01.ctl ","/usr3/tibero/control03.ctl"
         

    4. Start Tibero and verify

 

  • Control file backup method
    • Only logical backup is supported for control files. Backup the SQL statements that create control files. Especially after creating or changing tablespaces, datafiles, or redo logs, back up control files immediately for safety. Also back up control files when backing up the entire database.
       

    • Example of backing up Control File

      [Example] Control File Backup

      SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS
   '/tibero/DB/tibero7/backup/ctrlfile1.sql' REUSE NORESETLOGS;

 

5.4. Control File Related Reference

  • Tibero recommends maintaining two or more control files of the same size and content, similar to multiplexing redo log members.
     
  • Store copies of control files on different disks, like log members in the same log group. This is crucial for system performance and stability.
     
  • If copies exist on the same disk, failure of the disk renders control files unrecoverable. Hence, place control files alongside redo logs.
     

  • On each startup, Tibero reads control files to:
     

    a. Obtain tablespace and datafile information.
     

    b. Obtain data dictionary and schema object information stored in the database.

    c. Read necessary data.
     

  • Control file information query

    V$DATABASE: View showing ARCHIVELOG mode status and checkpoint info.

    V$CONTROLFILE: View showing control file names and statuses.

 

6. Redo Log File Management

Redo Logs

  • Describes how to manage Redo Log Files in the running DBMS.
     
  • Log files store redo logs.
  • Redo logs contain all changes made in the database and are critical for recovering committed transactions after fatal errors.
     

[Figure 15] Redo Log File Group Structure

  • Redo logs consist of two or more log groups.
     
  • Tibero uses these log groups in a circular manner.
    For example, with three log groups:
    1. Write logs to log group 1.
    2. When group 1 is full, write to groups 2 and 3.
    3. When group 3 is full, cycle back to group 1.

    Switching from one full log group to the next is called log switch.
     
  • Each redo log contains one or more log records with all changes, including old and new values.
     

Multiplexing of log members

  • Tibero uses only one log group at a time, called the active log group.

  • One log group can have multiple log members, a configuration called multiplexing.

    All log members in the same group must be the same size and store the same data, updated simultaneously. Different log groups can have different numbers and sizes of log members.

    [Figure 16] Multiplexing of Log Members

  • Log members within a group should be stored on different disks for performance. All members store the same log records simultaneously.

Multiplexing of log members and log groups
 

  • When setting log group size and count, consider archive operations. Size should allow fast transfer to third-party storage and efficient space use. Number should prevent waiting for archive of log groups.

 

6.2. Redo Log File Configuration Environment

Managed using Tibero DBMS commands. 

 

6.3. Redo Log File Operation Procedures

Log Switch

  • Connect as sys via tbsql or tbAdmin and execute. 

    [Example] log switch

    SQL>
   GROUP# STATUS
   ---
   0 CURRENT    
   1 INACTIVE  
   2 INACTIVE
   
   3 rows selected.
   
   SQL> alter system switch logfile;

   System altered.
   
   SQL> select GROUP#, STATUS FROM v$log;
   
   GROUP# STATUS
   ---
   0 INACTIVE    
   1 CURRENT    
   2 INACTIVE
   
   3 rows selected.

 

Checkpoint

  • Sends signals to DBWR and LGWR processes to write dirty buffers in DB CACHE to datafiles on disk.

    [Example] Manual Checkpoint command

    SQL> alter system checkpoint;

System altered.

 

Add Log Group

  • You can specify the log group number with GROUP option in ADD LOGFILE clause. This allows referring to specific log groups when adding log members (example for file system).

Add Log Member

  • To add a new log member to an existing log group, insert ADD LOGFILE MEMBER clause. Must specify the server process assigned to the log file (example for file system).
  • Delete Log Member
    • To remove a log member from a log group, insert DROP LOGFILE MEMBER clause. Must specify the server assigned to the log group; log group need not be specified. If removing leaves no members in the group, an error occurs. Active or unarchived log members in ARCHIVELOG mode cannot be removed.

 

6.4. Redo Log File Related Reference

  • Tibero provides dynamic views to assist redo log management, showing log group info, multiplexing, update dates, etc. Available to DBAs and users.
  • Redo log dynamic views
    • V$LOG: Queries log group information.
    • V$LOGFILE: Queries log file information.

 

7. Archive File Management

  • Describes archive file management methods in operation.
  • Archive mode must be set for online backup and complete recovery. 

 

7.1. Archive File Configuration Environment

  • To perform complete recovery, operate DB in archive log mode. In archive log mode, redo logs are copied to a separate archive log directory on log switch. When running in archive log mode, LGWR process synchronizes archive log copying during log switch.
  • Ensure sufficient disk space for archive log backups. If space is limited, consider online full backup frequency and delete archive logs already applied after backup.

 

7.2. How to Set Archive File

Modify TIP file and set archive log mode using tbsql. 

 

7.3. Archive File Operation Procedure

  1. Modify TIP file
    • Set LOG_ARCHIVE_DEST parameter path to generate archive log files. 
  2. Change to Archive Mode
    • Use "tbsql" to change to Archive Mode
    • tbdown > tbboot mount > login as sys > change to archive mode > open
    • After changing to Archive Mode, force a log switch to verify archive files are generated. If not, check if the archive path in TIP file has write permissions.

 

7.4. Archive Mode Change

Related Parameters

  • Archive-related Parameters
    • LOG_ARCHIVE_DEST: Specifies archive log file location.
    • LOG_ARCHIVE_FORMAT: Archive log file name format (log-t%t-r%r-s%s.arc)
    • LOG_ARCHIVE_OVERWRITE: Determines whether to overwrite existing archive log files.
  • Related dynamic View Tables
    • V$ARCHIVE_DEST_FILES: Shows archive log file information.
    • V$DATABASE: Check Archive Mode in LOG_MODE column.

 

8. Listener Management

Describes how to manage the Listener in the running DBMS. 

 

8.1. Listener Configuration Environment

  • Tibero Listener is not an independent process like Oracle's Listener but managed by the Monitor Thread. It starts and stops together with the database.
     
  •  Only one Listener port and connected DBMS exist in Tibero (multi-instance possible).
     

  • Listener cannot exist as a standalone process; connected DBMS and port settings are managed together in the TIP file. (Listener starts with tbboot and stops with tbdown.)

    [Example] Listener Port Management

    # tip file generated from C:\TIBERO\tibero7\config\tibero.template(8 22 15:8:19 2023) #-------------------------------------------------------------------------------
#
# tibero initialization parameter
#
#-------------------------------------------------------------------------------
...
DB_NAME=TIBERO_SID 
LISTENER_PORT=8629
...

 

8.2 Listener Operation Procedure

  • Listener Port Change Procedure
    • Steps: tbdown > Modify TIP file > Modify Client DSN > tbboot
      1. tbdown
        • Run "tbdown" in command prompt to shut down. In Windows, stopping as a service does not show progress, so command prompt shutdown is recommended.
      2. Modify TIP file

        • File location: $TB_HOME/config/$TB_SID.tip

          [Example] Change Listener Port in TIP file

          # tip file generated from /home/tibero/tibero7/config/tip.template (Mon Sep 10 23:25:37 PDT 2012) #-------------------------------------------------------------------------------#
# tibero initialization parameter
# #-------------------------------------------------------------------------------
... ...
LISTENER_PORT=8629 โ† changed
... ...

           

      3. Modify Client DSN
        • Edit only the port using vi or any editor. 
        • File location: $TB_HOME/client/tbdsn.tbr
           
      4. tbboot
        • Run "tbboot" in command prompt.
           
      5. Check in tbsql

 

8.3 Listener Related Reference

Related Parameters

  • [Table] Listener Related Parameters

    ParameterDescription
    LOG_LVL_LISListener log level. Higher value means more logs.
    LSNR_LOG_DESTListener log location.
    LSNR_DENIED_IPList of IPs denied access to Listener. If set together with LSNR_INVITED_IP, this setting is ignored.
    LSNR_DENIED_IP_FILEFile path listing IPs blocked from Listener access. Ignored if set with LSNR_INVITED_IP_FILE.
    LSNR_INVITED_IPList of IPs allowed to access Listener.
    LSNR_INVITED_IP_FILEFile path listing IPs allowed to access Listener.
    LISTENER_PORTPort number used by Listener.

 

 

9. tbdsn.tbr File Management

  • The tbdsn.tbr file contains environment settings required for clients to connect to Tibero database. It includes SID, host, port, and other information.
     
  • It serves the same role as Oracleโ€™s tnsnames.ora file.

 

9.1. tbdsn.tbr File Configuration Environment

Set DSN file on Tibero server

  • Use default editor on Windows (e.g., notepad).
  • On Unix, use vi or vim.

[Example] tbdsn.tbr configuration file

 

#-------------------------------------------------
# /tibero/tibero7/client/config/tbdsn.tbr
# Network Configuration File.
# Generated by gen_tip.sh at Fri Sep 14 22:04:36 KST 2023
TIBERO_SID=(
   (INSTANCE=(HOST=localhost)
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
   (INSTANCE=(HOST=123.45.67.11)              
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
   (LOAD_BALANCE=Y)
   (USE_FAILOVER=Y)
)
TIBERO_SID_SP=( 
   (INSTANCE=(HOST=123.45.67.10)
             (PORT=8630)
             (DB_NAME=TIBERO_SID)   
   )
)
TIBERO_SID_2=(
   (INSTANCE=(HOST=localhost)
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
)
TIBERO_SID_1=(
   (INSTANCE=(HOST=123.45.67.11)              
             (PORT=8629)
             (DB_NAME=TIBERO_SID)    
   )
)

 

9.2. tbdsn.tbr File Operation Procedure

  • The tbdsn.tbr file has the following structure. 

    [Example] tbdsn.tbr Structure

    SID_1=(
           (INSTANCE=(item1=value1)            
           (item2=value2)
               ...
       )
   )
SID_2=(
           (INSTANCE=(item1=value1)            
           (item2=value2)
               ...
       )
   )

TB_NLS_LANG=MSWIN949 
TBCLI_LOG_LVL=TRACE
  • Standard characters allowed in SID are letters (A-Z, a-z), digits (0-9), and hyphen (-). SID details are as follows.

  • Basic item descriptions

    [Table] DSN Basic Item Descriptions

    ItemDescription
    HOSTServer IP address (e.g., HOST=168.1.1.33)
    PORTTarget server listen port (e.g., PORT=8629)
    DB_NAMETarget database name (e.g., DB_NAME=tibero)
  • Client environment settings can also be configured besides SID info. These can be set as environment variables; if both are set, tbdsn.tbr settings take precedence.
  • DSN management items
    • TB_NLS_LANG: Specifies client character set (e.g., TB_NLS_LANG=UTF8)
    • TBCLI_LOG_LVL: Specifies CLI log level, used only when logging is needed for troubleshooting (e.g., TBCLI_LOG_LVL=TRACE)

 

9.3. tbdsn.tbr File Related Reference

Redundant Server Settings

  • Redundant servers (Replication servers) are physically independent servers replicated identically. Clients can connect to any server, and if one server stops, others can take over seamlessly.
  • To configure redundant servers in tbdsn.tbr, set multiple INSTANCE entries under one SID.

  • Example>

    [Example] DSN Redundant Server Settings

    tb=( 
(INSTANCE=(HOST=168.1.1.33)
          (PORT=8629)
          (DB_NAME=tibero)
    ) 
(INSTANCE=(HOST=192.168.1.25)          
          (PORT=8629)
          (DB_NAME=tibero2)
    ) 
(INSTANCE=(HOST=localhost)
          (PORT=8629)
          (DB_NAME=tibero)
    )
)

 

Load Balancing Settings

  • Tibero supports load balancing to prevent concentrated connections to a specific redundant server, distributing load and improving connection environment.

  • To enable load balancing in tbdsn.tbr:

    [Example] DSN Load Balancing Settings

    tb=( 
(INSTANCE=(HOST=168.1.1.33)
          (PORT=8629)
          (DB_NAME=tibero)
    ) 
(INSTANCE=(HOST=192.168.1.25)          
          (PORT=8629)
          (DB_NAME=tibero2)
    ) 
(INSTANCE=(HOST=localhost)
          (PORT=8629)
          (DB_NAME=tibero)
    )
    (LOAD_BALANCE=Y)
)

 

Failover Settings

  • When Tibero is set as TAC or redundant servers, if a failure occurs, the CLI module automatically reconnects to another instance or redundant server, restoring the session.

    [Example] DSN FAILOVER Settings

    tb=( 
(INSTANCE=(HOST=168.1.1.33)
          (PORT=8629)
          (DB_NAME=tibero)
    ) 
(INSTANCE=(HOST=192.168.1.25)          
          (PORT=8629)
          (DB_NAME=tibero2)
    ) 
(INSTANCE=(HOST=localhost)
          (PORT=8629)
          (DB_NAME=tibero)
    )
    (USE_FAILOVER=Y)
)

 

 

Related to