CUBRID Log Files http://www.cubrid.org/?mid=cubrid_log_files CUBRID Log Files en Fri, 28 Jan 2011 10:45:11 -0800 Sun, 04 Nov 2012 01:39:37 -0800 XpressEngine 1.4.4.1 CUBRID Log Files... CUBRID http://www.cubrid.org/cubrid_log_files http://www.cubrid.org/cubrid_log_files CUBRID Log Files
⇐Tutorials Download this document in PDF

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:

CUBRID Logs

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:

CUBRID Manager Logs

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

CUBRID Log Directory

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:

CUBRID Manager Server Logs

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.access.log file contents
  • 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:

cubrid-manager-server-log-file-contents.png

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:

cubrid-broker-sql-logs.png

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

cubrid-broker-sql-logs-menu.png

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.

cubrid-view-logs.png

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.

cubrid-analyze-logs.png

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

cubrid-analyze-logs-results.png

Execute Log

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

cubrid-set-execution-info.png

Log Property

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

cubrid-log-property.png

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.

]]> Fri, 28 Jan 2011 10:07:20 -0800