História stránky

...

Note 1: If a script that executes an action, during which an error occurred, is in debug mode, the information about this error is sent to the script editor - Debug tab.

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 about its position is written up (see the begin beginning of the example).

Kotva
vypisy_akcii vypisy_akcii

Action listing

...

Detailed debug information is written to the log file if the option Debug is checked off in the configuration of the object of 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 period of 60 seconds:
09:00:27.786 Db TestDb WD: 5 (4/1/0) cons: avail- 3,normal- 2, handles- 4

The log informs the user that the database database TestDb has 5 connections - 4 non-transactional, 1 transactional, and 0 reserved for browsers. 3 connections are available (avail) and 2 are used (normal).

...

• table descriptorhandle can be opened from process D2000 HI through the list of database tables, in the Browser, or from a script by using the actions actions DB_CONNECT, PG_CONNECT, SQL_CONNECT, SQL_PREPARE as well as for a short period of time (during an action) by calling DBS_*.
• transaction descriptorhandle can be opened by the action DB_TRANS_OPEN.
• connection descriptor handle is opened by the SQL_CONNECT, if the first parameter of the action is connectString.
• database descriptor handle is opened by the action SQL_CONNECT, if the first parameter of the action (dbObjIdent) is of Database type.

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 begin beginning and end ending of the periodic deleting:

...

Kotva
show_handle show_handle

Tell command SHOW_HANDLE

...

Interactive An interactive query of open descriptors handles with the helpo help of the SHOW_HANDLE Tell command. The syntax of the command is:

SHOW_HANDLE [HOBJ] or [mask [INFO]]

...

• HOBJ of the object Database, the open descriptors handles of which are to be displayed.
• HOBJ of the object Database table, the open descriptors handles of which are to be displayed.
• HOBJ of the object Structure definition - the open descriptors handles of database tables whose tables whose structure definition matches the given HOBJ will be displayed.
• mask_of_the_name, the open descriptors handles of which are to be displayed.
• mask_of_information from where the descriptor handle has been opened, if the INFO keyword is used.

If the SHOW_HANDLE command is called with no parameters, information on all open descriptors handles will be written to the log file.
For each descriptorhandle, the log contains the database name, connection number, descriptor type, descriptor handle name, and information from where the descriptor handle was open.
Displayed The displayed type and name of descriptor the handle varies depending on descriptor handle types as the following table states:

...

D2000 DBManager has two open descriptors. The first one is on the connection nr. 1. It is a table descriptor, which is opened in the Browser MAT_GROUPopen. The descriptor is open from the picture S.Test_DBmanager in process D2000 HI running on the computer with the name of mycomp.
The second descriptor is on the connection nr. 2, a transaction descriptor that is open from the 220th script row of the picture script in the picture S.Test_DBmanager.

Kotva
show_connect show_connect

Tell command SHOW_CONNECT

...

Interactive query for open connection by using the SHOW_CONNECT Tell command. The syntax of the command is:

SHOW_CONNECT [HOBJ [ID]] or [mask [ID]] [DETAIL]

...

• HOBJ of the Database type object, its open connections are to be displayed
• mask (pattern) matched against the 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 a given connection, will be displayed (in the same format as as SHOW_HANDLE)

Log includes:

• name and number of open connections for every database matching the defined filter
• for every connection:
  • database name
  • connection number
  • connection status
  • number of open descriptors
  • time from the last operation performed on this connection (or a the word busy and information about the internal status of the connection if the 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)

...

Receive TELL Command : SHOW_CONNECT Te* DETAIL
===================================================================
->Db TestDB 2 cons
->Db TestDB con 1:normal, 1 handles, idle 04:24:682, non-transact
->Db TestDB con 1:table   MAT_GROUP: <HI mycomp,S.Test_DBmanager>
->Db TestDB con 2:normal, 2 handles, idle 20:037, transact 1053
->Db TestDB con 2:trans TestDB: <S.Test_DBmanager: 220>
->Db TestDB con 2:table   MAT_GROUP: <S.Test_DBmanager: 109>

Note: Information on whether the connection is transactional or non-transactional along with 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.

Kotva
set_watchdog set_watchdog

Tell command SET_WATCHDOG

...

SQL operations execution of which took a longer time can be monitored by a tell command command SET_WATCHDOG. The syntax of the command is:

SET_WATCHDOG database_mask seconds

...

• database_mask - mask of name of Database object which connections are to be monitored
• seconds - number of seconds to elapse before the database operation will be logged, if it is still executing.
  Value A value of 0 disables monitoring.

A tracing task is activated at the first run of the Tell command SET_WATCHDOG with nonzero parameter 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 log.

...

• 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).

...

• SQL_CONNECT / SQL_PREPARE / DB_TRANS_OPEN .. - performed database action
• TransactId - ID of D2000 transaction
• dbTransId - ID of 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

Note: Start The start-up of SQL operation monitoring is written in the DBManager log. The log contains the list of databases that match the specified mask mask database_mask. The log also contains the information on the start-up of the watchdog at first calling the tell command command SET_WATCHDOG.

16:45:27.735 24.11 ===================================================================
16:45:27.736 24.11 ->Db DBC_ROVE_OD 2 cons
16:45:27.737 24.11 ->Db DBC_KOMP_OD 3 cons
16:45:27.742 24.11 Starting performance watchdog task for database operations
16:45:27.743 24.11 ===================================================================

...

• database_mask - mask of name of Database object which connections are to be monitored
• seconds - minimum length of database actions to be monitored.
  Value A value of 0 disables monitoring.

The difference between SET_WATCHDOG and SET_WATCHDOG_QUEUE is this:
command SET_WATCHDOG monitors operations, the execution of which in a database lasted lasts 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.

After the database action is finished, a detailed info is written into the error log file. Examples:

...

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 total number of executed actionactions, 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:

...

For the database, saving the debug information into the file DBManager.log is enabled. After starting process the process  D2000 DBManager, there are to be precreated 10 connections to the database are to be created, maximal maximum number of connections is 120. A connection, that is not used, will be closed after 300 seconds, maximal number of automatic connections is 20, and the internal watchdog terminates process process  D2000 DBManager if some connections to the database is not functioning (is frozen) for more than 7 minutes.

• For reasons of the speed optimization and mutual client non-blocking, process D2000 DBManager creates more than one automatic connection to the database. Automatic connections can be created immediately after starting process 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 The number of the precreated 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 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.

• Kotva
  brc brc

  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.
  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.

• Kotva
  logovaci_subor logovaci_subor

  Debug and information logs: process D2000 DBManager enables to display several levels of debugging logs which are in closer detail described in this document.
• 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 A 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
  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 and is currently in use.
  Numbers in brackets give numbers of non-transactional, transactional and browser connections.

...

When increased load, there occurs such a state that there are more requests than connections, that which is why the requests are enqueued by their type. The structured variable "SV._System_DBMDbPerf" is specially used for monitoring of queue status.

Each row of a structured variable describes all three fronts by the three values that are updated each 10[s] (see see SV._System_DBMDbPerf).

• ConNr - number of connections within a group,
• CurrRq - current number of requests for a group,
• MaxRq - maximum number of requests for a group during the elapsed period.

The monitoring of requests in the queue enables one to find out whether the number of connections within the group is sufficient, how fast the group is able to service the requests, and whether it is necessary to increase the number of connections within the group (however, increasing of connections need not increase the number of requests processed per unit of time, for example, if the database server is overloaded,...).

...