| Measurement |
Description |
Measurement
Unit |
Interpretation |
| No_SQL_execs |
The total number of SQL execute operations |
Number |
|
| No_SQL_fetches |
The total number of SQL fetch operations |
Number |
A low value is indicative of low fetch- intensive Siebel queries on the Siebel database. |
| No_SQL_parses |
The total number of SQL parse operations |
Number |
A low value is an indicative of low parse- intensive queries on the Siebel database. |
| Total_SQL_exec_time |
The time taken by SQL execute operations |
Secs |
Ideally, the value of this measure should be low. However, if you find that execution times are unreasonably long, look at the execution plan to determine how the data was accessed. The following can also be attributed to delays in SQL execution:
- I/O constraint on the disk where the table or index resides.
- Logical row lock contention (because of INSERT, DELETE, UPDATE and so on).
- DB2 connection on page latches.
- CPU constrained or storage constrained machine.
|
| Total_SQL_fetch_time |
The total time taken for SQL fetch operations |
Secs |
A query is request for data. Sometimes, various queries from the application do not fetch the entire result requested which forces the SQL server to hold shared key or page locks until the entire result set is fetched, or canceled (closed). Tracking this value helps you to determine the time taken for SQL fetch operations. If the time taken to fetch all result rows is high, then it will lock the tables, thereby blocking other users.
|
| Total_SQL_Parse_time |
The total time elapsed for SQL parse operations |
Secs |
The parse call - hard or soft - has overhead due to processing requirements i.e. actual CPU work needed by the database engine. During the hard parse, database engine has to lock several internal sources to make sure the structure of the tables involved does not change. Operations on the library cache also require locking of internal sources. These locks are taken for very short duration of time and have little effect on the applications supporting few users. However for applications that need to scale many concurrent users, any such lock will prevent scalability. A sudden increase in the value for this measure can affect other operations and increase the transaction response time.
|
| Avg_SQL_exec_time |
The average time taken by SQL execute operations |
Secs |
If the average elapsed time for SQL execution is high, it could be due to the following reasons:
- I/O constraint on the disk where the table or index resides.
- Logical row lock contention (because of INSERT, DELETE, UPDATE and so on).
- DB2 connection on page latches.
- CPU constrained or storage constrained machine.
|
| Avg_SQL_fetch_time |
The average time for SQL fetch operations |
Secs |
|
| Avg_SQL_parse_time |
The average time for SQL parse operations |
Secs |
|
| Num_DB_conn_retries |
The number of retries due to database connection loss |
Number |
Ideally, this value should be 0. |