Document Type | Technical Information
Category | Monitoring/Inspection
Applicable Product Version | T7
Document Number | TMOTI053
Overview
This is a guide on how to check the original query that caused an error during SQL execution through memlog using information from syslog.
Method
Scenario
A large number of column constraint violation logs occurred in sys.log, but the corresponding query cannot be checked in sys.log.
It is necessary to retrieve the original query from the person in charge to modify the query.
Table Definition
Table Creation Statement
create table tibero.test (id number, name varchar(20), address varchar(20));
Checking the Error-Causing Query
Inducing the Error
insert into tibero.test values (1,'aaaaaaaaaaaaaaaaaaaaaaaaa','bbb');
Checking the memlog Path
memlog is a memory log file that records system logs for each session.
The location of memlog is defined by the mem_log_dest parameter.
SQL> show parameter mem_log_dest NAME TYPE VALUE ---------------- -------- ------------------------- MEM_LOG_DEST DIRNAME /tibero/tibero7/instance/tibero/log /memlog/
Checking the Error in sys.log
NAME TYPE VALUE ------------- -------- -------------------------------------------------- SLOG_DEST DIRNAME /tibero/bis/tibero7/instance/tibero/log/slog/
syslog is a system log file where important operations performed in the Tibero DBMS are recorded.
This file can be used to analyze the cause of server performance degradation or to resolve bugs in Tibero itself.
Queries other than DDL and DeadLock are not recorded in sys.log and can be checked through memlog.
The path to syslog is defined by the slog_dest parameter.
vi /tibero/bis/tibero7/instance/tibero/log/slog/sys.log ... [2025-12-11T15:08:04.085747] [FRM-94] [I] THROW. ec=ERROR_EXP_NOT_FIT_LEN(-11048) [ "TIBERO"."TEST"."NAME" The value is too large for the column. (Actual value: 25, Maximum value: 20) ] (sql_id:45xbx80kgxswd, sub_sql_id:45xbx80kgxswd, csr_id:33, user:SYS, ap_module:(null), program:tbsql, host:db01_mis) [dt.h:699:dtv_pad_space_or_check_fit_into] ...
Performing memlog Dump after Logging in as sys User
You can check the session ID and csr_id in the sys log, and in [FRM-94], 94 means the session ID and csr_id is 33.
Normally, memlog is not generated, but you can generate memlog using the session ID as in the query below.
SQL> alter system dump memlog 94; System altere
Checking the memlog Dumpfile
You can retrieve the problematic query from memlog using the session ID and csr_id.
[tibero@ memlog]$ pwd /tibero/tibero7/instance/tibero/log/memlog [tibero@ memlog]$ ls -alt total 108 drwxr-xr-x. 2 tibero dba 4096 Dec 11 15:40 . drwxr-xr-x. 10 tibero dba 4096 Dec 11 15:18 .. -rw-r--r--. 1 tibero dba 102399 Dec 11 15:18 sql_memlog.3864519.94.0
The file name is in the format sql_memlog.xxxxx.94.0, and it includes the session ID (94) confirmed above.
Therefore, you can check the relevant file by referring to the session ID and file creation time, etc.
If you search based on CSR_ID:33, you can check the related SQL.
[tibero@ memlog]$ cat sql_memlog.3864519.94.0 | grep CSR_ID:33 2025/12/11 15:08:04.082465 CSR_ID:33 insert into tibero.test values (1,'aaaaaaaaaaaaaaaaaaaaaaaaa','bbb')