Siebel SQLs Test
This test, executed by an internal agent, monitors the overall health of interactions between the Siebel server and its backend database.
Target of the test : A Siebel Application Server
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the Siebel server that is being monitored.
Parameter | Description |
---|---|
Test period |
How often should the test be executed. |
Host |
The host for which the test is to be configured. |
Port |
The port number at which the specified host listens to. By default, this is 1199. |
InstallDirectory |
Provide the full path to the install directory of the Siebel server. |
GatewayServer |
Provide the IP address/host name of the Gateway server. |
EnterpriseServer |
This refers to the name that was specified for the Enterprise server during a Siebel installation. An Enterprise server is a logical entity. It collectively represents the Siebel application servers and gateway server. |
UserName |
This test executes a command on the Siebel server to extract the statistics of interest; this command requires administrator privileges to execute. Therefore, enter the name of the Siebel administrator. |
Password |
Specify the administrator password. |
Confirm Password |
Confirm the Siebel Agent Password by retyping it here. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
SQL execute operations |
Indicates the total number of SQL execute operations. |
Number |
|
SQL fetch operations |
Indicates the total number of SQL fetch operations. |
Number |
A low value is indicative of low fetch- intensive Siebel queries on the Siebel database. |
SQL parses |
Indicates the total number of SQL parse operations. |
Number |
A low value is an indicative of low parse- intensive queries on the Siebel database. |
Total time taken by SQL executes |
Indicates the total 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:
|
Total time taken by SQL fetches |
Indicates 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 time taken by SQL parses |
Indicates 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 time for SQL executes |
Indicates 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:
|
Avg time for SQL fetches |
Indicates the average time for SQL fetch operations. |
Secs |
|
Avg time for SQL parses |
Indicates the average time for SQL parse operations. |
Secs |
|
Database connection retries |
Indicates the number of retries due to database connection loss. |
Number |
Ideally, this value should be 0. |