Configuration and Administration

glog.sql Properties

To control the behavior of Oracle Transportation Management, you can change settings in the glog.properties file or the appropriate property set.

Property

New In Version

Description

glog.sql.call.timeout.<use case>=<# of seconds>

6.3.6

Used to support caller-supplied timeouts for SQL queries, updates/inserts/deletes and stored procedure calls. A caller may specify a specific number of seconds for a timeout, or a use case string. Properties of the form:

  • glog.sql.query.timeout.<use case>=<# of seconds>
  • glog.sql.update.timeout.<use case>=<# of seconds>
  • glog.sql.call.timeout.<use case>=<# of seconds>

control the timeout for a given use case. Note that any timeout of 0 seconds is interpreted as an unbounded wait: the SQL will not time out.

The default limits may vary by scenario. Oracle strongly recommends not altering these times and instead tuning queries to run within the limit.

Currently, the code supports the following use cases:

Queries:

  • uiQuery, for any query using ListRetriever. This includes all UI Finder queries and most Manager queries.
  • agentQuery, for any saved query used in an agent condition or IF statement.
  • sqlSession, for selects made through the SQL servlet.
  • default, for all other SQL queries.

Updates:

  • directSqlUpdate, for all insert/update/delete calls made in a DIRECT SQL UPDATE action.
  • sqlSession, for inserts, updates, and deletes made through the SQL servlet.
  • default, for all SQL updates/inserts/deletes.

Stored Procedure Calls:

  • directSqlUpdate, for all stored procedure calls made in a DIRECT SQL UPDATE action.
  • sqlSession, for calls made through the SQL servlet.
  • default, for all other stored procedure calls.

Classification Index Builder:

- classificationIndexBuilder, for GTM.

glog.sql.clientInfo.enabled

6.3.7

If set to false, all CLIENT_INFO tracking is suppressed and no overhead is incurred. Default = false.

glog.sql.clientInfo.enabledUseCases
=<comma-delimited list of use cases>

6.3.7

Lists the use cases (identical to the SQL timeout use cases) that will trace context information in CLIENT_INFO. Valid use cases are:

agentQuery = saved queries run for agent conditions or IF actions

uiQuery = queries run as part of a UI finder or manager

queryDefault = all other queries

 

directSqlUpdate = DIRECT SQL UPDATE agent action DML statement

updateDefault = all other DML statements

 

directSqlCall = DIRECT SQL UPDATE agent action stored procedure call

 

callDefault = all other stored procedure calls

 

Note that use cases for CLIENT_INFO tracking and SQL timeout have been  coalesced.

Default = uiQuery, agentQuery, directSqlUpdate, directSqlCall

 

Therefore CLIENT_INFO is disabled by default. If turned on, it is enabled for finder queries, agent conditions and DIRECT SQL UPDATE statements.

glog.sql.clientInfo.pattern=<pattern>

6.3.7

A single pattern is used for all use cases with CLIENT_INFO. It is given by setting this property.

glog.sql.clientInfo.saveLastInfo

6.3.7

By default, a session's CLIENT_INFO is populated during an active query, DML or stored procedure call. When the SQL returns control to the application server, CLIENT_INFO is cleared. Some applications may need to see the last CLIENT_INFO run for a particular session. To suppress the clearing of CLIENT_INFO, set this to true.

glog.sql.clientInfo.separator=<char>

6.3.7

Controls what character is used to separate each field in CLIENT_INFO.

Default is a vertical line, |.

glog.sql.clientInfo.useXid

6.3.7

By default, user and saved queries are shown with their complete GIDs in CLIENT_INFO. To restrict them to XIDs, set this property.

glog.sql.logArgMaxLength

 

SQL Statements displayed when Sql logging is enabled show all bind variable parameters by default. For large VARCHAR or CLOB fields, this would produce excessive and illegible logging. This property limits the number of characters displayed for any single parameter.

If a parameter has unshown characters, the parameter is displayed with an ellipsis (...). Default = 250

glog.sql.logBindClasses

 

Includes the Java class type for every logged SQL bind variable. This can be useful for diagnosis if a SQL mismatched argument error occurs. Default = false

glog.sql.logCommits

 

When SQL logging is enabled, the system logs every select statement, DML statements and procedure call. If this property is set to true, the system also logs all commits and rollbacks. Default = false

glog.sql.logConnectionHash

 

This property assists in diagnosing potential connection problems. This property should not be used unless advised by Technical Support.

Default: false

glog.sql.query.fetch.default

 

This property defines the default fetch size for UI queries.

Default: 10

glog.sql.query.fetch.maximum

 

This property defines the maximum fetch size. At a certain size, the additional packet and memory overhead of a large fetch exceeds the performance advantage in reducing the round trips. If the desired fetch exceeds the maximum fetch, the maximum fetch is used. This maximum overrides pre-fetch settings that are embedded in the code.

Default: 250

glog.sql.query.fetch.minimum

 

This property defines the minimum fetch size.

Default: 10

glog.sql.query.fetch.on

 

This property enables SQL pre-fetch. Setting a fetch size on database queries can significantly reduce database round trips and improve query performance.

Default: true

glog.sql.query.timeout.<use case>=<# of seconds>

6.3.6

See glog.sql.call.timeout.

glog.sql.update.batch.on

 

If true, batch updating is allowed. Batch updating is an Oracle feature that allows multiple records to be inserted or updated in a single database call, providing an array of record values. This significantly improves performance at the cost of error recovery. When an error occurs in a batch update, all changes are rolled back and the statements are retried one-by-one to identify which record caused the error.

Default = true

glog.sql.update.maximum

 

The performance advantage of batch updating can be offset by the memory and serialization overhead in transferring multiple records of data in a single database call. This property allows batch updating to be tuned. If the number of records exceeds the maximum, the records will be broken into sub-batches, each sub-batch less than the maximum. Default = 30.

glog.sql.update.timeout.<use case>=<# of seconds>

6.3.6

See glog.sql.call.timeout.

Related Topics