CUBRID Log Files
Table of Contents
The scope of this tutorial is to present some of the CUBRID built-in logging features. Logs related to restoring committed or uncommitted transactions when a system or media (disk) error occurs and neither the logs used to support the user-specified rollback(s) will be covered next time.
In this tutorial we will also show you how to use some of these logs from the CUBRID Manager, the default database administration tool for CUBRID.
Overview
There are 3 main types of CUBRID logs which are closely related to the CUBRID architecture:
- Broker logs
- CUBRID Manager logs
- Database logs
And based on the type of the operations recorded in the logs, we have separate logs for:
- Access
- Error
- Admin
This logs categorization is shown in the below image:

Let’s see now, for each log type, a brief description of what the log is intended for.
Broker Logs
- Access Log
The access log file records information about client access in a file named broker_name.access. - Error Log
The error log file records information about the errors that occurred during the client's request processing. - SQL Log
The SQL log file records SQL statements requested by the application client.
CUBRID Manager Logs
- Access Log
The access log files records information about the CUBRID Manager access. You can see in it user accounts, operation history, and the time when operations were performed. - Error Log
The error log file records information about errors that occurred while connecting in the CUBRID Manager.
Database/Server Logs
- Admin Log
This admin log records information about errors occurred while server is running.
You can access all these logs from within the CUBRID Manager:

Or, you can access them directly in the CUBRID installation folder:

In the next sections of this tutorial, we will go into more details regarding each log type.
Broker Logs
There are three types of logs that relate to the CUBRID Broker:
- Access log
- Error log
- SQL log
Each log can be found in the log directory under the installation directory.
You can change the directory where these logs are maintained by changing the:
- LOG_DIR
- ERROR_LOG_DIR,
... parameters of the broker environment configuration file (cubrid_broker.conf).
Access Log
The access log records information about the application client and is saved with the name broker_name.access.
If the LOG_BACKUP parameter is configured to ON in the Broker environment configuration file, when the Broker stops properly, the access log file is saved with the date and time when the Broker has stopped. For example, if broker1 stopped at 12:27 P.M. on June 17, 2008, an access file named broker1.access.20080617.1227 is generated in the log/broker directory.
The following is an example and description of access log file content:
1 192.168.1.203 - - 972523031.298 972523032.058 2008/06/17 12:27:46~2008/06/17 12:27:47 7118 - -1 2 192.168.1.203 - - 972523052.778 972523052.815 2008/06/17 12:27:47~2008/06/17 12:27:47 7119 ERR 1025 1 192.168.1.203 - - 972523052.778 972523052.815 2008/06/17 12:27:49~2008/06/17 12:27:49 7118 - -1
| Log Value | Explanation |
| 1 | ID assigned to the application server |
| 192.168.1.203 | IP address of the application client |
| 972523031.298 | UNIX timestamp value when the client's request processing started |
| 2008/06/17 12:46 | Time when the client's request processing started |
| 972523032.058 | Unix timestamp value when the client's request processing finished |
| 2008/06/17 12:47 | Time when the client's request processing finished |
| 7118 | Process ID of the application server |
| -1 | No error occurred during the request processing |
| ERR 1025 | Error occurred during the request processing. Error information exists in offset=1025 of the error log file |
Error Log
The error log file records information about errors that occurred during the client's request processing and is stored with the name broker_name_app_server_num.err.
The following is an example and description of error log content:
Time: 02/04/09 13:45:17.687 - SYNTAX ERROR *** ERROR CODE = -493, Tran = 1, EID = 38 Syntax: Unknown class "unknown_tbl". select * from unknown_tbl
| Time 02/04/09 13: 45:17.687 | Time when the error occurred |
| - SYNTAX ERROR | Type of error (e.g. SYNTAX ERROR, ERROR, etc.) |
| *** ERROR CODE = -493 | Error code |
| Tran = 1 | Transaction ID. -1 indicates that no transaction ID is assigned. |
| EID = 38 | Error ID. This ID is used to find the SQL log related to the server or client logs when an error occurs during SQL statement processing. |
| Syntax... | Error message (An ellipsis ( ... ) indicates omission.) |
SQL Log
The SQL log file records SQL statements requested by the application client and are stored with the name broker_name_app_server_num.sql.log.
The SQL log is generated in the log/broker/sql_log directory when the SQL_LOG parameter is set to ON. Note that the size of the SQL log file to be generated cannot exceed the value set for the SQL_LOG_MAX_SIZE parameter.
CUBRID provides the broker_log_top, broker_log_converter, and broker_log_runner utilities to manage SQL logs.
The following is an example and description of SQL log content:
02/04 13:45:17.687 (38) prepare 0 insert into unique_tbl values (1) 02/04 13:45:17.687 (38) prepare srv_h_id 1 02/04 13:45:17.687 (38) execute srv_h_id 1 insert into unique_tbl values (1) 02/04 13:45:17.687 (38) execute error:-670 tuple 0 time 0.000, EID = 39 02/04 13:45:17.687 (0) auto_rollback 02/04 13:45:17.687 (0) auto_rollback 0
| 02/04 13: 17.687:45 | Time when the application sent the request. |
| (39) | Sequence number of the SQL statement group. If prepared statement pooling is used, it is uniquely assigned to each SQL statement in the file. |
| prepare 0 | Whether or not it is a prepared statement. |
| prepare srv_h_id 1 | Prepares the SQL statement as srv_h_id 1. |
| (PC) | It is outputted if the data in the plan cache is used. |
| SELECT... | SQL statement to be executed. (An ellipsis ( ... ) indicates omission.) For statement pooling, the binding variable of the WHERE clause is represented as a question mark (?). |
| Execute 0 tuple 1 time 0.000 | One row is executed. The time spent is 0.000 second. |
| auto_commit/auto_rollback | Automatically committed or rolled back. The second auto_commit/auto_rollback is an error code. 0 indicates that the transaction has been completed without an error. |
The broker_log_top utility analyses the SQL logs which are generated for a specific period. As a result, the information of SQL statements and time execution are outputted in files by order of the longest execution time; the results of SQL statements are stored in log.top.q and those of execution time are stored in log.top.res, respectively.
The broker_log_top utility is useful to analyze long (in terms of execution time) queries.
The syntax is:
>broker_log_top [options] sql_log_file_list
options : {-t | -F from_date | -T to_date}
To store SQL logs created in log/broker/sql_log under the installation directory to a separate file, the broker_log_converter utility is executed.
The syntax of the broker_log_converter utility is:
>broker_log_converter SQL_log_file output_file
To re-execute queries saved in the query file which has been created by the broker_log_converter utility, the broker_log_runner utility can be used.
The syntax of the broker_log_runner utility
>broker_log_runner options input_file options : -I cas_ip -P cas_port -d dbname [-u dbuser [-p dbpasswd ]] [-t num_thread] [-r repeat_count] [ -o result_file]
CUBRID Manager Server Logs
CUBRID Manager Server-related logs are stored in the log/manager folder, under the CUBRID installation folder:

They are stored as one of the following four types of files, depending on the process of the Manager Server:
- cub_auto.access.log: Access log of a client that logged into and out of the Manager Server successfully.
- cub_auto.error.log: Access log of a client that failed to log into or out of the Manager Server.
- cub_js.access.log: Log of the jobs processed by the Manager Server:

- cub_js.error.log: Error log that occurred while the Manager Server is processing jobs.
Database/Server Logs
This admin log records information about errors that occurred while server is running. The format of output file is: <database_name>_<date>_<time>.err:

Logging-Related Parameters
The following are parameters related to logs used for database backup and restore. The type and the value range for each parameter is:
| Parameter Name | Type | Default Value | Min | Max |
| log_buffer_pages | int | 50 | 3 | |
| media_failure_support | bool | yes | ||
| log_max_archives | int | INT_MAX | 0 | |
| background_archiving | bool | yes | ||
| page_flush_interval_in_msecs | int | 0 | -1 | |
| checkpoint_interval_in_mins | int | 720 | 1 | |
| checkpoint_every_npages | int | 10000 | 10 | |
| adaptive_flush_control | bool | true | ||
| max_flush_pages_per_second | int | 10000 | 1 | INT_MAX |
| sync_on_nflush | int | 200 | 1 | INT_MAX |
And here below is a summary presentation of each parameter meaning and usage:
| Parameter Name | Description |
| log_buffer_pages | log_buffer_pages is a parameter that configures the number of log buffer pages to be cached in the memory. The default value is 50. If the value of the log_buffer_pages parameter is big, performance can be improved (due to the decrease in disk I/O) when transactions are long and numerous. |
| media_failure_support | media_failure_support is a parameter that specifies whether or not to store archive logs in case of storage media failure. If the parameter is configured to yes, which is the default value, all active logs are copied to archive logs when the active logs are full and the transaction is active. If it is configured to no, archive logs created after the active logs are full are deleted automatically. Note that archive logs are deleted automatically if the value of the parameter is configured to no. |
| log_max_archives | log_max_archives is a parameter that sets the maximum number of archive log files to record if media_failure_support is set to yes. The minimum value is set to zero, and the default is INT_MAX. For example, when log_max_archives=3 in cubrid.conf, the most recent three archive log files are recorded. If a fourth archiving log file is generated, the oldest archive log file is automatically deleted. |
| background_archiving | background_archiving is a parameter that generate a temporary archive log periodically at a specific time if media_failure_support is set to yes. This is useful when balancing disk I/O load due to the archive log process. The default is yes. |
| page_flush_interval_in_msecs | The parameter page_flush_interval_in_msecs specifies the interval in milliseconds (msec) at which dirty pages in a data buffer are flushed to a disk. Its default value is 0. If this parameter is set to -1 (the minimum value), dirty pages are flushed to the disk only at the checkpoint, or when pages are swapped. |
| checkpoint_interval_in_mins | checkpoint_interval_in_mins is a parameter that sets cycle (in minutes) for checkpoint to be executed. The default value is 720. Checkpoint flushes log files(dirty page) remained in data buffers to a disk. It can restore data back to the latest checkpoint if failure happens. If high volume of log files are stored in a disk due to a checkpoint, it may cause disk I/O. Therefore, you should set the checkpoint cycle properly to prevent database operation failure. |
| checkpoint_every_npages | checkpoint_every_npages is a parameter that sets the checkpoint cycle by log page. The default value is 10,000. You can distribute disk I/O overload at the checkpoint by specifying lower number in the checkpoint_every_npages parameter, especially in an environment where INSERT/UPDATE are heavily loaded at a specific time. |
| adaptive_flush_control | The parameter adaptive_flush_control automatically adjusts the flush capacity at every 50 ms depending on the current status of the flushing operation. Its default value is yes. That is, this capacity is increased if a large number of INSERT or UPDATE operations are concentrated at a certain point of time and the number of flushed pages reaches the max_flush_pages_per_second parameter value; and is decreased otherwise. In the same way, you can distribute the I/O load by adjusting the flush capacity on a regular basis depending on the workload. |
| max_flush_pages_per_second | The parameter max_flush_pages_per_second specifies the maximum flush capacity when the flushing operation is performed from a buffer to a disk. Its default value is 10,000. That is, you can prevent concentration of I/O load at a certain point of time by setting this parameter to control the maximum flush capacity per second. If a large number of INSERT or UPDATE operations are concentrated at a certain point of time, and the flush capacity reaches the maximum capacity set by this parameter, only log pages are flushed to the disk, and data pages are no longer flushed. Therefore, you must set an appropriate value for this parameter considering the workload of the service environment. |
| sync_on_nflush | The parameter sync_on_nflush sets the interval in pages between after data and log pages are flushed from buffer and before they are synchronized with FILE I/O of operating system. Its default value is 200. That is, the CUBRID Server performs synchronization with the FILE I/O of the operating system whenever 200 pages have been flushed. This |
Using Broker SQL Logs from CUBRID Manager Client
Remember: All the executed queries are stored in the log file when the SQL_LOG parameter of the Broker is ON – and you change this value easily from the CUBRID Manager client:

This broker log files can be viewed/analyzed/re-executed from CUBRID Manager client:

View Log
This function reads the SQL log stored in the selected file and displays 100 lines at a time. It also provides a function for selecting and copying a specific area of the log information.

Analyze Log
When Analyze Sql Log menu is selected, you can select which Broker's SQL log is to be analyzed:
- When the Transaction based analyze checkbox is selected, the log is analyzed for each transaction;
- Otherwise, they are analyzed for each query.

After selecting the SQL log file you want to analyze and then clicking OK, the results are displayed:

Execute Log
If you select Execute log, the Set Execution Information dialog box is displayed, in which you can configure the execution environment:

Log Property
By selecting the Log property menu, information about the selected log file is displayed:

See also
Getting Help
This concludes the CUBRID Logs tutorial. If you have any questions related the CUBRID Log files, you can tweet to @cubrid or post your message on the CUBRID Forum.
