The JDBC Sensor captures information about typical JDBC calls. It provides the following data:
- The SQL string (by default, up to 4096 characters).
- The number of rows returned during the execution of the SQL statement.
- Optionally, the bind values for the SQL statements. If statement aggregation is enabled, capturing of bind values is automatically disabled.
The sensor is not eligible for Hot Sensor Placement.
To edit the System Profile specific settings, open the System Profile Preferences dialog box and select Agent Group/tier with Java technology > Sensor Configuration and then select the JDBC item in the Sensor Configuration list.
Here you can enable or disable aggregation and bind value capturing. You can also set the limit for SQL command length.
- No aggregation or bind value capturing: Each query displays separately. Bind values are not captured.
- Enable aggregation: If queries are equal, only one DB query statement displays per PurePath parent node, along with the number of executions. This makes PurePaths trees much more readable, but capturing of bind values is disabled. DB connection acquisitions are not aggregated.
- Enable bind value capturing (): Enables capture of SQL statement's bind values.
- Maximum size of captured SQL command strings: Limits the captured SQL statements to the specified length. The default is 512. All symbols, exceeding the limit, are cut.
Properties marked with are especially relevant for sensor overhead on the system under diagnosis (SUD). Use these properties with caution and check the impact on the SUD after setting these properties.
The settings are:
|optionJDBCAggregationThresholdJava||5000||Limit of distinct SQL statements counted individually on an instrumented node level.
After reaching the threshold, only the count of executions of the overflowing statements is counted on a [thresholded executions] summary counter.
|optionJDBCAggregationPoolThresholdJava||1000||Same limit, but on a pool level. So, if there are more distinct SQLs seen for one distinct connection pool, the overflowing statements are summarized in a [pool-thresholded executions] summary counter.|
|optionJDBCAggregationCacheEnabledJava||true||There is an LRU cache that remembers the last N seen statements, which reduces CPU overhead a lot. However, it can be turned off, for the lowest possible memory footprint of database aggregation.|
|optionJDBCAggregationCacheMaxEntriesJava||512||The size of the aforementioned LRU cache. Being LRU, it is guaranteed to never exceed this limit.|