oracle-db-appdev-monitoring icon indicating copy to clipboard operation
oracle-db-appdev-monitoring copied to clipboard

Exporter Modification Request

Open priyanshishah-oracle opened this issue 1 year ago • 0 comments

1. Timeout granularity:

Some SQL statements will have longer runtimes or higher volatility in runtimes. These longer runtimes might be across the board, or just on a subset of host environments with certain characteristics (e.g. orders of magnitude more tablespaces on certain hosts/applications can impact tablespace infrastructure focused queries). As the number of queries in a config file grows, the current solution of increasing the timeout for every query in the config file has the potential issue of allowing the confg file to run very, very long. It is allowed to run up to the timeout value for every SQL statement. A few ways this could be dealt with include:

  • Timeout granularity per SQL statement
  • Timeout granularity per host
  • Increase the current limit of two config files

These potential solutions are not exclusionary and each provides different benefits.

2. Frequency of SQL statement execution:

Some SQL statements do not need to be executed as frequently as others. Many need to be run at the typical 3 minute scrape frequency. Others might need to be run only once every 30 minutes. Being able to account for these differences would reduce load on the hosts. Possible solutions include:

  • Allowing multiple config files and allowing adjustment of the call time for each one
  • Allowing some SQL statements to execute every x calls of the config file (run this statement on every 10th call of the config file)

priyanshishah-oracle avatar Jul 15 '24 19:07 priyanshishah-oracle