This chapter describes the Oracle Enterprise Manager can be used to manage Oracle Adaptive Access Manager metrics that show the performance for Oracle Adaptive Access Manager 11g servers and OAAM server clusters.
This category of metrics provides information about the connection metrics.
For the selected datasource, this metric shows the number of database connections currently available (not in use).
This metrics shows the average number of database connections created for this data source per minute in the last 5 minutes.
This metric shows the number of data source connections that are currently in use by applications.
For the selected datasource, this metric shows the average number of JDBC connection leaks per minute over the last 5 minutes. A leaked connection is a connection that was reserved from the data source but was not returned to the data source when the connect was closed.
This metrics shows the average number of database connections created for this datasource per minute in the last 5 minutes.
This metric shows the average number of times per minute that the datasource attempted to refresh a database connection and failed over the past five minutes.
For the selected datasource, this metric shows the number of failed JDBC connection requests per minute, averaged over the past five minutes.
This metric shows the average number of requests for a connection from this datasource per minute over the last 5 minutes.
This metric shows the percentage of requests that successfully returned connections for this datasource over the last 5 minutes.
This metric shows the number of database connections that are currently unavailable (in use or being tested by the system) in this instance of the datasource.
For the selected datasource, this metric shows the number of JDBC connection wait successes per minute, averaged over the past five minutes. A wait success is a request for a connection from this datasource that had to wait before getting a connection and eventually succeeded in getting a connection.
For the current data source, this metric shows the average number of connection wait requests that failed per minute over the past five minutes. A connection wait request is a request for a database connection that had to wait before getting a connection. Connection wait requests can fail for a variety of reasons, including waiting for longer than the value of the ConnectionReserveTimeoutSeconds property.
For the selected datasource, this metric shows the average number of connection wait requests per minute in the last 5 minutes. A connection wait request is a request for a connection that had to wait before getting a connection. This metric includes those that eventually got a connection and those that did not get a connection.
For the current datasource, this metric shows the percentage of connection wait requests that successfully got a database connection during the last 5 minutes. A connection wait request is a request for a connection that had to wait before getting a connection. This metric includes those that eventually got a connection and those that did not get a connection.
For the selected datasource, this metric shows the number of JDBC connection wait successes per minute, averaged over the past five minutes. A wait success is a request for a connection from this data source that had to wait before getting a connection and eventually succeeded in getting a connection.
This metric shows the current state of the datasource.
This metric shows the number of statements per minute that were added to the statement cache for this data source in the last 5 minutes.
This metric shows the average number of statements per minute that were discarded from the cache over the past five minutes. Each connection in the connection pool has its own cache of statements. This number is the sum of the number of statements that were discarded from the caches for all connections in the connection pool.
For the selected data source, this metric shows the number of statements per minute not satisfied by the statement cache, averaged over the past five minutes.
This metric shows the percentage of statements satisfied by the statement cache during the last 5 minutes. Each connection in the connection pool has its own cache of statements.
This metric shows the average number of statements per minute satisfied by the data source statement cache in the last 5 minutes. Each connection in the connection pool has its own cache of statements.
For the current data source, this metric shows the number of prepared and callable JDBC statements currently cached in the connection pool. Each JDBC connection in the connection pool has its own cache of statements. This number is the sum of the number of statements in the caches for all connections in the connection pool.
These metrics provide information about the EJB home over the last 5 minutes.
This metric shows the total number of beans from this EJB Home that are currently in the EJB cache.
This metric shows the average number of beans per minute that have been activated from the EJB home over the last 5 minutes.
This metric shows the percentage of cache accesses that completed successfully in the last 5 minutes.
This metric shows the average number of cache misses per minute for this EJB module in the last 5 minutes.
For the current EJB module, this metric shows how many times the EJB pool has been accessed per minute. This is averaged over the last 5 minutes.
This metric shows the percentage of EJB pool accesses that were successful in the last 5 minutes.
This metric shows the current number of available EJB instances in the free pool.
This metric shows the average number of EJB destroys per minute for this EJB module over the last 5 minutes.
This metric shows the average number of times per minute that a failed attempt was made to get an instance from the free pool. This value is averaged over the past five minutes. An attempt to get a bean from the pool will fail if there are no available instances in the pool.
This metric shows the number of EJB instances currently being used from the free pool.
This metric shows the average number of EJB transaction commits per minute for this EJB Module over the last 5 minutes.
These metrics show the transaction information for this EJB over the last 5 minutes.
This metric shows the EJB transaction commits per minute, averaged over the past five minutes.
This metric shows the EJB transaction commits per minute, averaged over the past five minutes.
These metrics provide data on how the servlets and JSPs, EJBs, and Oracle WebLogic Server Work Manager for the selected application are currently performing.
This metric shows the average number of EJB cache access attempts per minute on the selected server in the last 5 minutes.
This metric shows the average number of Enterprise Java Beans activated per minute over the last 5 minutes.
This metrics indicates the percentage of cache accesses that completed successfully in the last 5 minutes.
This metric shows the number of EJB cache misses per minute in the last 5 minutes.
This metrics shows the average number of Pool accesses per minute for the selected server in the last 5 minutes.
For the selected server, this metric displays the percentage of EJB pool accesses that were successful in the last 5 minutes.
For the selected server, this metric indicates the current number of available Java bean instances in the free pool.
This metric shows the average number of EJB destroys per minute for the selected server in the last 5 minutes.
This metric shows the percentage of pool accesses to the server that were successful in the last 5 minutes.
This metric shows the number of EJB instances currently being used from the free pool.
For the selected server, this metric identifies the EJB transaction commits per minute for the last 5 minutes.
For the selected server, this metric identifies the EJB transaction commits per minute for the last 5 minutes.
For the selected server, this metric shows the number of transactions rolled back per minute, averaged over the past five minutes.
This metric shows the EJB transaction timeouts per minute for the last 5 minutes on the selected server.
For the selected server, this metric specifies the number of messages processed by message-driven beans (MDBs) per minute in the last 5 minutes.
This metric shows the number of requests processed per minute during the last 5 minutes on the selected server. If the request handling throughput is very low, either there is no activity on the server or a problem exists which prevents the server from processing requests.
This metric shows the average time (in milliseconds) spent to process a request during the last interval. The interval is the period specified as the collection frequency for this metric.
These metrics provide information about the selected servlet or JSP per minute over the last 5 minutes.
This metric shows the average number of reloads of the selected servlet or JSP per minute over the last 5 minutes.
These metrics provide information for the selected web module.
This metric shows the average number of servlet and JSP invocations per minute for this Web module in the last 5 minutes.
This category of metrics provides status and performance data related to OAAM server login requests.
This metric represents the percentage of login requests that are blocked by OAAM during the last 5 minute collection interval. Importance of this metric: This metric is used to give some indication of the percentage of login requests that were blocked. Login requests are usually blocked if OAAM policies detect unusual or fraudulent behavior.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If there is a high percentage of blocked login requests, review the rules and policies that are resulting in the BLOCK action. Check to see if BLOCK is the appropriate action.
This metric shows the number of login requests blocked by OAAM during the last 5 minute collection interval. Login requests are usually blocked if OAAM policies detect unusual or fraudulent behavior. Importance of this metric: This metric is used to give some indication of how many login requests are blocked. Login requests are usually blocked if OAAM policies detect unusual or fraudulent behavior.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when value is out of bound: If there are too many blocked login requests, review the rules and policies that are resulting in the BLOCK action. Check to see if BLOCK is the appropriate action for the situation.
This metric represents the percentage of login requests that were presented with challenge questions after authentication during the last 5 minute collection interval. Importance of this metric: This metric is used to give some indication of the percentage of login requests that were presented with challenge questions as a second factor authentication. A very high rate of this value indicates that login requests are occurring in a suspicious or risky environment.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If there are too many login requests that are being challenged, review the rules and policies that are resulting in the CHALLENGE action. Check to see if CHALLENGE is the appropriate action.
This metric shows the number of login requests that were presented with challenge questions after authentication. Importance of this metric: This metric is used to give some indication of how many login requests were presented with challenge questions as a second factor authentication. A very high rate of this value indicates that login requests are occurring in a suspicious/risky environment.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when this value is out of bound: If there are too many login requests that are being challenged, review the rules and policies that are resulting in the CHALLENGE action. Check to see if CHALLENGE is the appropriate action for the situation.
This metric shows the percentage of login requests that failed during the last 5 minute collection interval. Importance of this metric: This metric is used to give some indication of the percentage of login requests that have failed. A failed login request usually implies that authentication was not successful. A very high rate of failed login requests when compared with total login requests may indicate suspicious activity.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: Usually this percentage should be low. If most of the logins are failures then there might be suspicious activity. Consider further investigation of the device and location of the failed login requests.
Check the server logs to make sure the authentication subsystem is working and there are no errors from the authentication subsystem.
This metric shows the number of failed login requests per second since server startup. Importance of this metric: A failed login request usually implies that authentication was not successful. Usually the rate of failed logins should be low. A very high rate of failed login requests when compared with the total number of login requests may indicate suspicious activity.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when value is out of bound: Usually this count should be low. If most of the logins are failures, there might be suspicious activity. Consider further investigation into the device and location of the failed login requests. Check the server logs to make sure the authentication subsystem is working and that there are no errors from the authentication subsystem.
This metric shows the number of failed logins during the last collection interval. Importance of this metric: A failed login request usually implies that authentication was not successful. A very high rate of failed login requests when compared with the total number of login requests implies suspicious activity.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when value is out of bound: Usually this count should be low. If most of the logins are failures, there might be suspicious activity. Consider further investigation into the device and location of the failed login requests. Check the server logs to make sure the authentication subsystem is working and that there are no errors from it.
This metric shows the percentage of login requests that were successful. Importance of this metric: Usually most login requests are successful in normal scenarios. Very low rates of successful login requests when compared with total login requests indicate suspicious activity.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the percentage of successful logins is very low, consider further investigation into the device and location of the failed login requests.
This metric represents the number of successful login requests per second for the selected OAAM server since server startup. Importance of this metric: This metric is used to give some indication of how many login requests were successful. Usually most login requests are successful in normal scenarios. A very low rate of successful login requests when compared with total login requests may indicate suspicious activity.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: Usually most logins are successful unless there is suspicious activity. If the number of successful logins is very low when compared to the total number of logins, consider further investigation into the device and location of the failed login requests.
This metric shows the number of successful login requests during the last 5 minute collection interval. Importance of this metric: This metric is used to give some indication of how many login requests were successful. Usually most login requests are successful in normal scenarios. Very low rates of successful login requests when compared with total login requests may indicate suspicious activity.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: Usually most logins are successful unless there is suspicious activity. If the number of successful logins is very low when compared to the total number of logins, consider further investigation into the device and location of the failed login requests.
This metric shows the total number of login requests during the last 5 minute collection interval. Importance of this metric: This metric is used to give some indication of the login requests activity.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when this value is out of bound:
If the logins count is very high, but does not impact system performance, no action is necessary.
If the login count is very high and impacts performance, consider creating a cluster of OAAM servers so that the load can be shared across multiple servers.
When the login count is too high, look at the failed login count and see if there is any correlation. If most of the logins are failures, there might be suspicious activity. Consider further investigation into the device and location of the failed login requests.
These metrics provide statistics and performance information about policy execution. The time spent to process policies includes:
Time taken to execute a given policy. This metric value includes the time taken to execute ALL the rules associated to a policy.
Time to process the trigger combinations, rule results, and alerts.
This metric shows the average time (in milliseconds) spent to process all policies since server startup.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
This metric captures the total number of policies that completed processing.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
This metric captures the total number of policies processed at the end of the sampling interval.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
This metric captures the maximum time spent for any policy to complete processing since server startup (ms).
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
This metric shows the minimum time spent for any policy to complete processing since server startup (ms).
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
This metric shows the total time (in milliseconds) spent processing all policies associated with a checkpoint since server startup.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
The category of metrics that pertain to rule execution.
This metric shows the average time (in milliseconds) spent processing all rules associated with a policy since server startup.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the average time to process all rules associated with the policy is high, check to see if there are too many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
This metric captures the total number of rules processed.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the total number of rules processed is low, check to see if there are too many rules in the policy. If there are, consider splitting them into different policies. Also check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
This metric captures the total number of rules processed since the last sample.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the total number of rules processed since the last sample is low, check to see if there are too many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
This metric shows the maximum time (in milliseconds) spent processing any request since the server started.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the value of the metric is high, consider optimizing the underlying SQL queries or optimizing/tuning database.
This metric shows the minimum time (in milliseconds) spent processing any request since server startup.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the value of the metric is high, consider optimizing the underlying SQL queries or optimizing/tuning database.
This metric shows the total time (in milliseconds) spent processing all rules associated with a policy since server startup.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: A high value could be attributed to either too many rules associated to a policy or expensive rules. If there are too many rules, consider splitting them into different policies. If there are expensive rules, consider optimizing the underlying SQL queries or optimizing/tuning database.
This metric presents a summary of the time spent to execute all the policies in a checkpoint.
This metric shows the average time (in milliseconds) spent processing all policies associated with a checkpoint since the server started. Usually one or more policies are associated to a checkpoint. This metric value includes the value from the metric "Policy Execution."
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the metric value is high, perform the following steps:
Narrow down the cause to Rules Execution or Policy Execution.
Check to see if any SQL queries are taking too long to execute and appropriately tune and optimize the database.
For the Rule Execution metric: A high value could be attributed to either too many rules associated to a policy or more expensive rules. If the value for the time taken to process rules associated with a policy is a high value, check to see if there are too many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
For the Policy Execution metric: If the value for the time taken to process the policy is high, check to see if trigger combinations exist in the policy. If they do, consider not using trigger combinations. Check to see if nested policies exist in the policy. Review them and consider alternatives.
This metric captures the total number of checkpoints executed.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the number of checkpoints executed is low, perform the following steps:
Narrow down the cause to Rules Execution or Policy Execution.
Check to see if any SQL queries are taking too long to execute and appropriately tune and optimize the database.
For the Rule Execution metric: A high value could be attributed to either too many rules associated to a policy or more expensive rules. If the value for the time taken to process rules associated with a policy is a high value, check to see if there are many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
For the Policy Execution metric: If the value for the time taken to process the policy is high, check to see if trigger combinations exist in the policy. If they do, consider not using trigger combinations. Check to see if nested policies exist in the policy. Review them and consider alternatives.
This metric captures the total number of checkpoints where all associated policies were processed since the last sample.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the number of checkpoints executed is low, perform the following steps:
Narrow down the cause to Rules Execution or Policy Execution.
Check to see if any SQL queries are taking too long to execute and appropriately tune and optimize the database.
For the Rule Execution metric: A high value could be attributed to either too many rules associated to a policy or more expensive rules. If the value for the time taken to process rules associated with a policy is a high value, check to see if there are many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
For the Policy Execution metric: If the value for the time taken to process the policy is high, check to see if trigger combinations exist in the policy. If they do, consider not using trigger combinations. Check to see if nested policies exist in the policy. Review them and consider alternatives.
This metric shows the maximum time (in milliseconds) spent processing policies associated with any checkpoint since the server started.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the number of checkpoints executed is low, perform the following steps:
Narrow down the cause to Rules Execution or Policy Execution.
Check to see if any SQL queries are taking too long to execute and appropriately tune and optimize the database.
For the Rule Execution metric: A high value could be attributed to either too many rules associated to a policy or more expensive rules. If the value for the time taken to process rules associated with a policy is a high value, check to see if there are many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
For the Policy Execution metric: If the value for the time taken to process the policy is high, check to see if trigger combinations exist in the policy. If they do, consider not using trigger combinations. Check to see if nested policies exist in the policy. Review them and consider alternatives.
This metric shows the minimum time (in milliseconds) spent processing any checkpoint since the server started.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the number of checkpoints executed is low, perform the following steps:
Narrow down the cause to Rules Execution or Policy Execution.
Check to see if any SQL queries are taking too long to execute and appropriately tune and optimize the database.
For the Rule Execution metric: A high value could be attributed to either too many rules associated to a policy or more expensive rules. If the value for the time taken to process rules associated with a policy is a high value, check to see if there are many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
For the Policy Execution metric: If the value for the time taken to process the policy is high, check to see if trigger combinations exist in the policy. If they do, consider not using trigger combinations. Check to see if nested policies exist in the policy. Review them and consider alternatives.
This metric shows the total time (in milliseconds) spent processing all checkpoints since the server started.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the number of checkpoints executed is low, perform the following steps:
Narrow down the cause to Rules Execution or Policy Execution.
Check to see if any SQL queries are taking too long to execute and appropriately tune and optimize the database.
For the Rule Execution metric: A high value could be attributed to either too many rules associated to a policy or more expensive rules. If the value for the time taken to process rules associated with a policy is a high value, check to see if there are many rules in the policy. If there are, consider splitting them into different policies. Check to see if expensive rules exist in the policy. If they do, consider optimizing the underlying SQL queries or optimizing and tuning the database.
For the Policy Execution metric: If the value for the time taken to process the policy is high, check to see if trigger combinations exist in the policy. If they do, consider not using trigger combinations. Check to see if nested policies exist in the policy. Review them and consider alternatives.
This category of metrics provides information related to updates in user authorization status.
This metric shows the average time (in milliseconds) spent executing the updateAuthStatus() API call since the server started.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if SQL queries are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This metric shows the total time (in milliseconds) spent for the updateAuthStatus() API call to complete since server startup. This value indicates the total time taken for the API Call updateAuthStatus to complete. This API is called to update the authentication status of the user request.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if SQL queries are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This metric captures the total number of updateAuthStatus() API calls since the last sample.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
This metric shows the maximum time (in milliseconds) spent executing any updateAuthStatus() API call since the server started. This API is called to update the authentication status of the user request.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if SQL queries are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This metric shows the minimum time (in milliseconds) spent to execute the updateAuthStatus() API call since the server started. This updateAuthStatus() API is called to update the authentication status of the user request.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if SQL queries are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This metric shows the total time (in milliseconds) spent to execute all updateAuthStatus() API calls since the server started. This updateAuthStatus() API is called to update the authentication status of the user request.
The following table shows how often the metric's value is collected
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 5 Minutes |
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if SQL queries are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This category of metrics provides information concerning the updateLog API call. This API call captures the userId, IP Address and other details of the user request.
This metric shows the average execution time (in milliseconds) for the API call updateLog() since server startup. updateLog() is the data collection API that captures the user ID, IP address and other details of the user request.
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if the queries on VCRYPT_TRACKER_USERNODE_LOGS are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This metric captures the total number of times the "updateLog()" API Call was executed.
This metric captures the total number of times the updateLog API call was executed since the last sample. updateLog() is the data collection API that captures the user ID, IP address and other details of the user request.
This metric shows the maximum time (in milliseconds) spent executing any updateLog() API call since server startup. updateLog() is the data collection API that captures the user ID, IP address and other details of the user request.
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if the queries on VCRYPT_TRACKER_USERNODE_LOGS are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This metric shows the minimum execution time (in milliseconds) for any updateLog API call since server startup. updateLog() is the data collection API that captures the user ID, IP address and other details of the user request.
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if the queries on VCRYPT_TRACKER_USERNODE_LOGS are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This metric shows the cumulative amount of time (in milliseconds) that was spent executing updateLog() API calls. updateLog() is the data collection API that captures the user ID, IP address and other details of the user request.
User Action
Action when the value is out of bound: If the metric value is high, you may want to investigate this metric in more detail. Check to see if the database is performing optimally and if the queries on VCRYPT_TRACKER_USERNODE_LOGS are taking too long to execute. If query execution consumes significant time, consider adding relevant indexes or tuning the database and/or purging and archiving old, obsolete data from various OAAM tables.
For information about setting up archive and purge procedures, see the archive and purge appendix in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.