Debug information and error information of process process D2000 DBManager is are shown in the process text console and written to the log file in the subdirectory TRACE of the application directory as well. If the process D2000 DBManager is started as SELF.DBM, it creates the DBManager.log and DBManager_ERR.log files. If this process is started as a name.DBM, it creates the DBManager_name.log and DBManager_meno_ERR.log.
If the size of log file reaches the predefined value of 10 MB, it will be renamed to DBManager_name_prev.log (DBManager_meno_ERR_prev.log) and a new log file will be created. Previous DBManager_name_prev.log (DBManager_meno_ERR_prev.log) will be deleted.
If the parameter Size of the log file is set to a non-zero value in the object of of Database type, both the debug and error information, generated by action performed in this database, will be written to a separate log file of the database. The name of this log file is name_of_database.log, while dots in the name of the Database object will be replaced by "_" (e.g. if the object of the Database type is named DB.Test, its log file will be DB_Test.log). For error information, the file name is name_of_database_ERR.log.
If the size of the log file reaches a size equal to the value of the parameter Size of the log file, it will be renamed to name_of_database_prev.log and the a new log file will be created. Previous Previous name_of_database_name_prev.log will be deleted. It is the same for the file name_of_database_ERR.log.
Process D2000 DBManager provides several debugging levels:
- Error logs
- Action listing
- Listing the actions, the duration of which is longer than the entered number of seconds
- Logs with DBG.DBMANAGER debug category enabled
- Logs with DBG.DBMANAGER.DATA debug category enabled
- Logs with DBG.DBMANAGER.DBCTX debug category enabled
- Logs with DBG.DBMANAGER.DBCTX.CSV debug category enabled
- Logs with DBG.DBMANAGER.SQL_CONNECT debug category enabled
- Logs with startup parameter /DBD<number_of_requests>
- Tell command SHOW_HANDLE
- Tell command SHOW_CONNECT
- Tell command SET_WATCHDOG
- Tell command SET_WATCHDOG_QUEUE
- Tell command TIME_STATISTICS
- Optimization and debugging
Note: Starting with D2000 version 23, a DbManager Diagnostic Pack is available that can visualize the information provided by tell commands in the D2000 Cnf or D2000 GrEditor environment.
...
Note 2: Each ESL action for work with the database (through D2000 DBManager) saves the information about the position in the ESL code from which it was called. If some error occurs, both the information about the found error and its position is are written up (see the beginning of the example).
...
Detailed debug information is written to the log file if the option Debug is checked off in the configuration of the object of Database type. The log includes the information on individual ESL actions (action name, begin and end), database, and connection that the action uses.
...
Watchdog message (WD) and information database logs are written to the log file with the a period of 60 seconds:
09:00:27.786 Db TestDb WD: 5 (4/1/0) cons: avail- 3,normal- 2, handles- 4
...
| Status | Description |
|---|---|
| Init | Connection is in the initial phase (it is being created). Transient status. |
| Avail | Connection is free (available). |
| Normal | Connection is used. |
| Live | Connection is passing from Avail status to Normal status. Transient status. |
| Die | The connection is being closed. Transient status. |
| Zombie | The connection is closed, and the service thread is finished. Transient status. |
...
If the database table has the parameter Time depth defined in its configuration and process D2000 DBManager periodically deletes old data from it, the log file will also include the information about the beginning and ending end of the periodic deleting:
10:29:32.068 11.08 Db TestDB table Time_Test periodic delete BEG
10:29:32.162 11.08 Db TestDB table Time_Test periodic delete END
| Kotva | ||||
|---|---|---|---|---|
|
...
Debug information about operations, the duration of which is longer than the entered number of seconds, is written to the log file after setting the parameter parameter Log operations longer than (sec) to a nonzero value in the configuration Databaze configuration Database object. Log The log contains the information about connection, on which the action was executed, localization of the action in ESL script, the calling message from DbManager, and the duration of the action in milliseconds.
Example:
...
Detailed debug information is written to the log file after enabling the DBG.DBMANAGER debug category in the process D2000 System Console - Debug info window. Each log of action also contains also information on procedures called in process D2000 DBManager (that may be useful for developers) and texts of executed SQL commands.
Example shows the log on of execution of the SQL_PREPARE action:
...
The examples of logs with differences between ODBC and OCI version versions of D2000 DBManager are in the chapter Example - logs for process D2000 DBManager.
...
Detailed debug information is written in the log file after enabling the DBG.DBMANAGER.DATA debug category through the process D2000 System Console - Debug info window. Each log of action contains also a list of values that were written to or read from the database.
Example shows the action for displaying the first page of the table MAT_GROUP in the displayer of Browser type opened in process D2000 HI:
...
The examples of logs with differences between ODBC and OCI version versions of D2000 DBManager are in the chapter Example - logs for process D2000 DBManager.
...
Detailed debug information is written into the log file after enabling the DBG.DBMANAGER.DBCTX debug category through the process process D2000 System Console - Debug info window.
After modifying the context of the process that is bound in D2000 DBManager (by ESL action DB_SET_PROCESS_PARAMS), the information is written to the main log of the given D2000 DBManager process, which are is useful for developers. The following logs are independent of parameter the parameter Debug in the configuration of the object of of Database type (they are not recorded into in the Trace directory).
This example shows a log after executing the action DB_SET_PROCESS_PARAMS when setting the parameter:
...
To write the detailed information to the log file, enable the parameter Debug in the configuration of the Database object. The log contains the information about the parameters that are set in the context of a given client process, which starts DB actions through through D2000 DBManager.
This example shows a log after executing the action SQL_SELECT, if the parameters of process context have been already set by action DB_SET_PROCESS_PARAMS:
...
| Kotva | ||||
|---|---|---|---|---|
|
...
Detailed CSV information is written into the log file after enabling the DBG.DBMANAGER.DBCTX.CSV debug category by the process D2000 System Console - Debug info window. This information is written after enabling the parameter Debug in the configuration of the Database object. Log The log contains the structured CVS information about single parameters that are set in the context of a given client which starts DB actions through through D2000 DBManager.
CSV header:
...
Note: The DBG.DBMANAGER.SQL_CONNECT debug category has no effect on the SQL_CONNECT actions which contain the reference to an object of Database or Database Table types, because these actions are influenced by the parameter parameter Debug in the configuration dialog box of respective the respective Database type object. The category affects only the SQL_CONNECT actions using the parameter connectString for their connection, i.e. the text connect string, debugging of which cannot be enabled in process D2000 CNF and it needs to be enabled by inserting the DEBUG parameter into the connectString parameter.
...
If a number of requests queued for any of the automatic connections exceeds the value number_of_requests, this information will be recorded in the log file (i.e. the log file of the database if the value Size of the log file is configured, otherwise the log file of DBManager). The log will contain the performance warning, connection number, and number of queued requests:
10:32:12.983 14.02 con 1:performance warning: 2 requests
This warning means that incoming non-transactional request will have to wait till the queued requests are processed. If these warnings are more frequent, you might consider the increasing the value of of automatic connections to increase request throughput. Recommended The recommended value of <number_of_requests> is 1, i.e. running DBManager with parameter /DBD1.
Note 1: If the parameter Debug is checked off, the processing of requests is slower due to writing the debug information to the log file. We recommend to increase increasing the number of automatic connections or the value of <number_of_requests> to /DBD2 to avoid the performance warnings.
Note 2: Transactional connection does not need this kind of performance tuning, because it is currently being used only sequentially from one event.
...
Note: Information on whether the connection is transactional or non-transactional along with the transaction number gives outdated value (transaction has already been finished) for connections in the the Avail status. Such connections will be recycled in transactional or non-transactional mode if needed.
...
- database_mask - mask of name of Database object which connections are to be monitored
- seconds - the number of seconds to elapse before the database operation will be logged, if it is still executing.
A value of 0 disables monitoring.
A tracing task is activated at the first run of the Tell command SET_WATCHDOG with nonzero parameter seconds (at least one database must match the specified mask). This task checks in every second if the connection to the monitored database , did not exceed the set time of performing (parameter seconds). If this time is exceeded, this information is written into the log.
The log contains:
- database name (if a dedicated log is not configured for this Database),
- number of connections,
- duration of the operation,
- information on the internal status of the connection (for developers of D2000).
...
After the SQL operation is finished, a detailed info is written into the error log file. Examples:
...
- SQL_CONNECT / SQL_PREPARE / DB_TRANS_OPEN .. - performed database action
- TransactId - ID of D2000 transaction
- dbTransId - ID of a database transaction. If it is greater than 0, the database action is transactional (executed inside DB_TRANS_OPEN). If it is zero or less, the database action is non-transactional.
- Handle - ID of the handle in the context of DBManager
- DbTableId - HOBJ and name of D2000 object Table
- Comment - sequence of procedure calls in ESL scripts (call chain)
- connectString, Statement, bBindIn, FetchSize, colNr, MaxRows .. parameters specific for individual database actions
...
If value of parameter seconds is 0 in all databases, the watchdog stops database monitoring and the following information appears in the log:
17:37:41.588 24.11 Performance watchdog: going to sleep (no more databases to monitor)
The watchdog is running so it is not necessary to start it up at the next activating of the monitoring and only information about activation appears in the log:
18:45:28.749 24.11 Performance watchdog: starting monitoring
...
Database actions execution of which - including time spent in queues of DBManager - took a longer time can be monitored by a tell command SET_WATCHDOG_QUEUE. The syntax of the command is:
SET_WATCHDOG_QUEUE database_mask seconds
...
Tell command displays statistics of execution of individual database action types per-database or per-table (if a parameter DETAIL is specified). For every type of database action (browser open, transaction start, DB_* and DBS_* actions, etc) printout contains the total number of executed actions, total and average duration, and duration of the longest action together with a comment (ESL call chain).
Statistics with zero execution counts are discarded.
If a parameter DETAIL is specified, after the printout of database statistics there follows a printout of per-table statistics of all child tables.
Example of a printout:
...
| Parameter name in CNF | Parameter name in connect string |
|---|---|
| Precreated connections | PRE=... |
| Maximum connections | MAX=... |
| Maximum automatic connections | NTC=... |
| Reserved browser connections | BRC=... |
| Close unused connections after (sec) | CLOSE=... |
| Close DBManager after timeout (min) | WDC=... |
| Debug | DEBUG |
| Off | OFF |
| Maximum returned rows | MR=... |
| Empty operations after an inactivity period | EO=... |
Example: settings of database additional parameters in its connect string:
DEBUG;PRE=10;MAX=120;CLOSE=300;NTC=20;WDC=7;MR=1000
For the database, saving the debug information into the file DBManager.log is enabled. After starting the process process D2000 DBManager, 10 connections to the database are to be created, maximum number of connections is 120. A connection, that is not used, will be closed after 300 seconds, the maximal number of automatic connections is 20, and the internal watchdog terminates process the process D2000 DBManager if some connections to the database is are not functioning (is frozen) for more than 7 minutes.
- For reasons of the speed optimization and mutual client non-blocking, process process D2000 DBManager creates more than one automatic connection to the database. Automatic connections can be created immediately after starting process the process D2000 DBManager, so they are prepared to be used (e.g. creating a connection in case of the database of Oracle type may take 1 second or more and it causes delaying delays in ESL scripts). The number of the pre-created connections can be adjusted in process D2000 CNF the object of Database type using the parameter Precreated connections. Maximal number of connections can be limited by parameter Maximum connections, while the value 0 disables the limitation. If process D2000 DBManager uses all connections, then the next call to create a connection (DB_TRANS_OPEN) will return the error DBM_MAX_CONNECTIONS.
- Using the parameter Maximum automatic connections allows to set a maximum number of connections created automatically. When the parameter is not set, then:
- at most 1/4 of Max connections will be used for automatic connections
- if Max<4, only 1 automatic connection will be created
- if Max=0, at most 5 automatic connections will be created (default value)
If process D2000 DBManager uses the maximum number of automatic connections, then a new connection will not be created as a result of the next request (e.g. non-transactional SQL_CONNECT, PG_CONNECT, or DB_CONNECT), but one of the existing will be used. The parameter Maximum automatic connections is important for the database to not exceed the defined number of connections. - For time optimalisation optimisation reasons the process D2000 DBManager "recycles" existing connections. If a connection is closed (e.g. DB_TRANS_CLOSE) or is not used (it is the result of SQL_CONNECT and SQL_DISCONNECT performed), then it is signed as available. Available connections can be repeatedly used; it saves time to connect to the database and accelerates the execution of scripts. The available connections, that do not belong to prepared ones and are not used, will be terminated after the expiration of the time defined in the parameter Close unused connections in seconds(precreated pre-created connections are not being terminated). Adjusting the parameter to a negative value will tell the process D2000 D2000 DBManager not to terminate available connections - in this case, their number will increase and it will reflect the status of D2000 DBManager during the maximum system load.
To speed up the operations of browser the Browser displayer it is possible to reserve a pool of connections for these operations (browser opening, changing pages, and the action DB_REFRESH_TABLE) using the parameter BRC - Reserved browser connections. This feature is supported starting with D2000 version 8.00.009.Kotva brc brc
The advantage is that no other non-transactional operations (which can last several seconds or more) will be executed by these reserved connections and the action DB_REFRESH_TABLE as well as changing pages can be faster than in default configuration when the browser operations are executed by automatic connections.
Note: if the value of parameter BRC - Reserved browser connections is zero, the browser operations are executed by automatic connections, which was default before this parameter was implemented.
Debug and information logs: process D2000 DBManager enables to display several levels of debugging logs which are in closer detail described in this document.Kotva logovaci_subor logovaci_subor - Termination of process D2000 DBManager in consequence of "frozen " connections: D2000 DBManager contains the internal watchdog, which detects every minute, whether some connection to the database is not "frozen" (i.e. service thread did not return from calling of ODBC interface). In this case, process D2000 DBManager will write into a log file. If the watchdog detects such a situation n-times in a consecutive sequence (while n can be adjusted in the parameter Close DBManager after timeout), it will terminate process D2000 DBManager. A default value of 0 means that that D2000 DBManager will not be terminated.
- Parameters for the connections created by means of the command SQL_CONNECT using so-called connect string: as these connections are not related to objects of Database type, but DSN is directly defined in the connect string, setting of the parameters can be performed directly in the connect string.
Example:
UID=name;PWD=user's password;DSN=DSN name;ACD;Debug;CLOSE=300
Debug information for the created connection will be written to the file. Unused An unused connection will be closed up after 300 seconds.
The available connection can be "recycled" if its connect string is the same as the connect string of the connection being created.
Debug and information logs of these connections that are "independent" on the object of Database type:
08:59:45.710 Indep# 3 DSN=TestX:SQL_FETCH BEG
08:59:45.710 Indep# 3 DSN=TestX:SQL_FETCH END
the log informs us that "independent" connection no. 3, DSN of which is "TestX", performed the action SQL_FETCH.
If parameter Debug is set on at least one independent connection, then the log also contains periodical information about the independent connections (written to log once a minute):
09:14:27.752 Db Independent connects WD: 1 (1/0/0) cons:normal- 1
the log informs us that there exists only one independent connection exists and it is currently in use.
Numbers in brackets give numbers of non-transactional, transactional, and browser connections.
| Kotva | ||||
|---|---|---|---|---|
|
...
From the above mentioned, it results that there exist three groups of connections exist (database connections along with the service tasks) for each object of of Database type in every at any time, but their quantity within a group is limited in some way (or it is not according to settings).
...