...
Process D2000 DBManager provides several debugging levels:
- Error logs
- Action listing
- Listing the actions, duration of which is longer than 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
| Kotva | ||||
|---|---|---|---|---|
|
...
Interactive query of open descriptors with the helpo of SHOW_HANDLE Tell command. The syntax of command is:
...
- HOBJ of the Database type object, its open connections are to be displayed
- mask (pattern) matched against Database object's name, the open connections of which are to be displayed
- ID - connection number or transaction number (returned by the DB_TRANS_OPEN action in the parameter handleIdent_Int) is to be displayed
- if parameter "DETAIL" is specified, also all descriptors, opened on given connection, will be displayed (in the same format as SHOW_HANDLE)
Log includes:
- name and number of open connections for every database matching defined filter
- for every connection:
- database name
- connection number
- connection status
- number of open descriptors
- time from last operation performed on this connection (or a word busy and information about the internal status of the connection if operation is currently in progress. Example: busy (U_EXECDIRECT1/D_EXECDIRECT2))
- information whether the connection is transactional, non-transactional or non-transactional reserved for browsers
- a transaction number (the parameter handleIdent_Int in the DB_TRANS_OPEN action) for transactional connection
- log in the format of SHOW_HANDLE for each descriptor (if parameter "DETAIL" is specified)
...
Note: Information whether the connection is transactional or non-transactional along with transaction number gives outdated value (transaction has already been finished) for connections in the Avail status . Such connections will be recycled in transactional or non-transactional mode if needed.
...
17:54:00.116 16.02 con 1:Query execution duration 00:00:01.103 SQL_CONNECT TransactId 10319, dbTransId 0, Handle 1104492764, connectString {}, DbTableId 1473 {DB.MATERIAL}, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 10864;BT_connect_OnClick: 248
}
17:54:18.926 16.02 con 1:Query execution duration 00:00:01.105 SQL_PREPARE TransactId 10320, dbTransId-1, Handle 10319, Statment {SELECT ID_MATERIAL FROM material }, bBindIn FALSE, FetchSize 1, colNr 17, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 10864;BT_prepare_OnClick: 279
}
17:55:59.113 16.02 con 2:Query execution duration 00:00:01.110 DB_TRANS_OPEN TransactId 10325, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 10864;BT_db_trans_open_OnClick: 543
}
Meaning of individual items:
...
- database_mask - mask of name of Database object which connections are to be monitored
- seconds - minimum length of database actions to be monitored.
Value of 0 disables monitoring.
The difference between SET_WATCHDOG and SET_WATCHDOG_QUEUE is this:
command SET_WATCHDOG monitors operations, execution of which in a database lasted longer than a specified time. But if several clients share the same automatic (non-transactional) connection, from client's point of view a database action can last long because it is waiting in a queue where it is preceded by other database actions by other clients. For that reason a tell command SET_WATCHDOG_QUEUE was implemented - to monitor the total execution time of database action from od insertion into a queue to the end of its execution.
...
18:01:21.579 16.02 con 1:Query total duration 00:00:01.130, execution 00:00:00.105 SQL_EXEC_PROC TransactId 10331, dbTransId-1, Statement {{ call TESTF_IN_OUT (?) }}, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 11332;BT_exec_proc_OnClick: 626
}
18:02:39.149 16.02 con 1:Query total duration 00:00:01.103, execution 00:00:00.202 SQL_CONNECT TransactId 10335, dbTransId 0, Handle 1104492765, connectString {}, DbTableId 1473 {DB.MATERIAL}, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 11453;BT_connect_OnClick: 248
}
18:02:42.437 16.02 con 1:Query total duration 00:00:01.103, execution 00:00:00.035 SQL_DISCONNECT TransactId 10335, dbTransId-1, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 11453;BT_connect_OnClick: 248
}
18:02:51.163 16.02 con 1:Query total duration 00:00:01.105, execution 00:00:00.654 SQL_PREPARE TransactId 10337, dbTransId-1, Handle 10336, Statement {SELECT ID_MATERIAL FROM material }, bBindIn FALSE, FetchSize 1, colNr 17, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 11453;BT_prepare_OnClick: 279
}
18:02:54.275 16.02 con 1:Query total duration 00:00:01.110, execution 00:00:00.239 SQL_FETCH TransactId 10338, dbTransId-1, Handle 10336, MaxRows 100, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 11453;BT_fetch_OnClick: 299
}
18:02:57.009 16.02 con 1:Query total duration 00:00:01.104, execution 00:00:00.109 SQL_FREE Handle 10336, Comment {NS1PHUM3_HI.HIS;S.sql_TEST( 9473) 11453;BT_free_OnClick: 325
}
Meaning of individual items: see a description in section SET_WATCHDOG.
| Kotva | ||||
|---|---|---|---|---|
|
...
- For reasons of the speed optimization and mutual client non-blocking, process D2000 DBManager creates more than one automatic connection to database. Automatic connections can be created immediately after starting 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 in ESL scripts). Number of the precreated 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 next call to create 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 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 execution of scripts. The available connections, that do not belong to prepared ones and are not used, will be terminated after expiration of the time defined in the parameter Close unused connections in seconds(precreated connections are not being terminated). Adjusting the parameter to a negative value will tell process 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 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. Default value 0 means 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 file. Unused connection will be closed up after 300 seconds.
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 and is currently in use.
Numbers in brackets give numbers of non-transactional, transactional and browser connections.
...