The Internet Message Access Protocol (IMAP) target provides session-oriented access for Internet Standards Based mail clients. The metric categories provide statistical information on these IMAP servers.
This category contains metrics that provide information about the APPEND command. Mail clients use the IMAP APPEND command to copy messages into an Oracle Collaboration Suite Database from an external source. Mail clients commonly use this command to place a copy of sent messages into folders on the Oracle Collaboration Suite Database. Less frequently, a particular client that has two user accounts on two different Oracle Collaboration Suite Databases might use the APPEND command to copy messages across Oracle Collaboration Suite Databases.
The APPEND Average Time metric measures the latency, in milliseconds, involved from the time a message starts to be copied into a folder on the IMAP Server until its completion. Latencies will vary and are a function of the size of the message.
Trending increases in APPEND Average Time typically mean that the IMAP writes to the Oracle Collaboration Suite Database (mailstore) cannot keep up with the amount of traffic. An increase in APPEND latency is often accompanied by an increase in the latencies of the SMTP_IN process for that Oracle Collaboration Suite Database.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Review the Enterprise Manager metrics for the Oracle Collaboration Suite Database instance. Common reasons for increased latency include:
Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database. Try applying more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
Too many connections configured for the mail protocol servers. All mail protocol servers have a minimum, maximum, and increment value. The minimum number of connections is an aggregate of all server instance minimums. The maximum is an aggregate of all instance maximums. The servers grow and shrink their pools dynamically. A sustained jump in latency during peak loads followed by a return to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release 2 (9.0.4.1)).
Datasets have become too large. Consider partitioning the Oracle Collaboration Suite Database.
This metric measures the rate of APPEND failures per minute. APPEND failures occur when sufficient resources are not available to create a new message in the user's Oracle Collaboration Suite Database.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-1 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
300 |
500 |
1 |
The number of failed APPENDs are %value% |
Root causes of APPEND command failures could include:
Disk capacity. A failure will occur when an Oracle Collaboration Suite Database runs out of disk space or is unable to extend tablespaces.
Insufficient connection pool maximum for the Oracle Collaboration Suite Database. Oracle Email protocol servers share connection pools for all client connections into the Oracle Collaboration Suite Database, enabling a large number of mail client connections to share a smaller number of connections without contention issues. While the multiplier for connection pools varies based upon how the mail system is used, the maximum connect pool value is typically in the 10's to support a concurrent user base in the low thousands. If there is disk capacity, consider adding another IMAP instance on this host or increasing the maximum connection pool size.
This informational metric represents the rate of APPEND commands that occurred per minute during the period since the last capture of this information.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Use this value to better understand user email usage patterns. Use this information as a factor when deciding to alter the critical alert and warning alert thresholds to better suit system requirements.
IMAP Servers are session oriented. All mail clients must authenticate themselves with the IMAP Server at the start of the session before they are allowed to execute any other IMAP commands.
The LOGIN command and the AUTHENTICATE command are used by a client to start a session and have access to more capabilities. The LOGIN command supports basic username and password authentication. AUTHENTICATE supports basic username and password authentication as well as more sophisticated and complex authentication algorithms up to and including Simple Authentication and Security Layer (SASL: RFC 2222) support.
This metric is the latency period involved in logging into the IMAP Server (in tenths of a second). Each IMAP authentication requires the server to access the Oracle directory server as the "source of truth" for authentication. If your Oracle directory server configuration chains authentication to yet another Oracle directory server, the AUTHENTICATE Average Time includes the time to communicate with and receive information from that second Oracle directory server.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
The root cause for an unusually long time to authenticate is typically found in the network between the IMAP Server and the Oracle directory server or in resources for the Oracle directory server:
Network latency increases between servers. Check network latencies between your mail protocol servers (middle tier installations) and the instance of the Oracle directory server, which supports those servers. This includes any transit times through routers and firewalls.
Insufficient processor or memory or inefficient use of memory for the Oracle directory server database. For default installations, the Oracle directory server database is shared with the ÒinfrastructureÓ database instance. If the database or host do not have enough memory allocated to support the transaction load against the database, apply more resources to Oracle directory server or tune the Oracle directory server. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
This metric graphs a rate of AUTHENTICATE command failures. It is an aggregate value, counting failures for invalid user names or passwords and failures to validate an account against the Oracle directory server.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-2 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
300 |
500 |
1 |
The number of failed authentications are %value% |
Root causes of an increasing AUTHENTICATE Failure Rate can include:
Mandatory password changes. The AUTHENTICATE Failure Rate can increase if password policies require the users to change their password after a given length of time. If multiple people enter this state at the same time, sudden increases in authentication failures can occur.
The Oracle directory server is temporarily unavailable. If the Oracle directory server service is not available, authentications are not cached, preventing logins.
The IMAP Server and the Oracle directory server cannot communicate over the network. This could be caused by changes in DNS, routers, or firewalls.
Insufficient connection pools for Oracle directory server lookups. Oracle Email protocol servers share connection pools for all client connections into the Oracle directory server. If the authentication rate is high and the number of maximum connections into the Oracle directory server is small, contention issues could arise.
Check that the Oracle Collaboration Suite Database mail host is up and running and that the IMAP Server can connect to it. Also, check that the listener for Oracle Collaboration Suite Database (mailstore) is up and running.
This informational metric graphs the per minute rate at which sessions were instantiated since the last check was performed. This is not equivalent to the number of concurrent users, because:
Mail clients often open multiple sessions to their IMAP Server per mail client session
Mail clients often use the more basic LOGIN command
The number of concurrent users is a count and it does not take into account closed sessions
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
The COPY command is used by mail clients to copy (not move) a message into another mail folder.
This metric measures the average time it took the IMAP Server to respond to a COPY command. The latency includes the time it took the IMAP Server to communicate with an Oracle Collaboration Suite Database and the time required to update information in an Oracle Collaboration Suite Database.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Increases in the response times to the COPY command may indicate problems in your network or your Oracle Collaboration Suite Databases. When an increase in the latency of a command is detected, check the latency of commands to other mail protocol servers (POP and SMTP) for similar increases, as they are often related.
Review the Enterprise Manager metrics for the infrastructure database, the Oracle directory server, and the Oracle Collaboration Suite Database instance(s). Common issues include:
Network Latencies. Check the response time between this IMAP Server and the Oracle Collaboration Suite Database(s).
Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database. Apply more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
Too many connections are configured for the mail protocol servers. All mail protocol servers have a minimum, maximum and increment value. The minimum number of connections is an aggregate of all server instances minimums. The maximum is an aggregate of all instances maximums. The servers grow and shrink their pools dynamically. Sustained jumps in latency during peak loads followed by returns to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release 2 (9.0.4.1))
If a slow but gradual increase in response time is noted and one or more of your Oracle Collaboration Suite Databases is large, datasets may have become too large. Consider partitioning your Oracle Collaboration Suite Database.
This metric measures the rate of COPY commands that failed per minute.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-3 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
300 |
500 |
1 |
The number of failed COPY operations are %value% |
The COPY command fails if the IMAP Server is unable to contact an Oracle Collaboration Suite Database. A sudden increase in failures can also occur when an Oracle Collaboration Suite Database runs out of resources, such as disk space.
Check that the network between the IMAP Server and the Oracle Collaboration Suite Database is up and running
Check that the Oracle Collaboration Suite Database and the listener for the Oracle Collaboration Suite Database is up and running, and that the connect string is accurately registered in the infrastructure Oracle directory server
Check that your Oracle Collaboration Suite Database has enough available tablespace to copy the message
This metric measures the rate of COPY commands invoked per minute. This is an informational metric used to gain an understanding of the usage patterns and resource requirements of the mail system.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This category charts the rate of FETCH commands requested by all clients of IMAP Server instances on this target over the collection period. An IMAP client will use the FETCH command to get most types of message data from an Oracle Collaboration Suite Database, including message identifiers, header information, messages, and message body parts.
This metric graphs the average time (in milliseconds) required by an IMAP Server to respond to a FETCH command. This metric represents an aggregate average and can be used to identify the presence of long term trends in the latency of the FETCH command. Trending increases in average time typically mean that the IMAP reads from an Oracle Collaboration Suite Database cannot keep up with the number of requests received. An increase in FETCH latency is often accompanied by an increase in the latencies of other IMAP and SMTP process commands.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
When an increase in the latency of a command is detected, check the latency of other mail protocol server commands (POP and SMTP) for similar increases that could indicate degradation of one or more of a system's Oracle Collaboration Suite Databases. Review the Enterprise Manager metrics for the Oracle Collaboration Suite Database instance. Common reasons for latency increases include:
Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database may indicate that the database or host do not have enough memory allocated to support the transaction load against the database. Apply more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
Too many connections are configured for the mail protocol servers. All mail protocol servers have a minimum, maximum, and increment value. The minimum number of connections is an aggregate of all server instance minimums. The maximum is an aggregate of all instance maximums. The servers grow and shrink their pools dynamically. Sustained jumps in latency during peak loads followed by returns to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release 2 (9.0.4.1)
If a slow but gradual increase in response times is noted and one or more of your Oracle Collaboration Suite Databases is large, datasets may have become too large. Consider partitioning your Oracle Collaboration Suite Database.
This metric graphs the number of FETCH commands per minute that failed to return the message information requested by a client .
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-4 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
300 |
500 |
1 |
The number of failed FETCHes are %value% |
FETCH command failures are often a result of the IMAP Server not being able to connect to one or more of the Oracle Collaboration Suite Databases. Check the following:
Verify that the Oracle Collaboration Suite Database and the listener for the Oracle Collaboration Suite Database is up and running.
Verify that the connection pool maximum is sufficient for the Oracle Collaboration Suite Database. Email protocol servers share connection pools for all client connections to the Oracle Collaboration Suite Database. This enables a large number of mail client connections to share a smaller number of connections without contention issues. While the multiplier for connection pools will vary widely based upon how the mail system is used, the maximum connect pool value is typically in the 10's to support a concurrent user base in the low thousands. If there is capacity, consider adding another IMAP instance on this host or increasing the maximum connection pool size per IMAP instance.
This informational metric represents the rate of FETCH commands occurring over a period of time. This rate should vary proportionally to the number and type of mail clients concurrently connected. Changes in this value can be caused by a "rogue" client or by users changing from one type of mail client to another. The FETCH commands rate indicates the usage patterns and resource requirements of the mail system.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This category contains metrics that provide information about the LOGIN command. The IMAP protocol is a session-oriented protocol. Mail clients authenticate and log into an IMAP Server. A successful login results in a session that is maintained between the client and the server until the mail client disconnects or the session times out.
This metric represents the average time between an IMAP Server receiving a valid login command and responding successfully. The average login time is recorded in hundredths of a second. Processing of the LOGIN command includes an authentication between the IMAP and Oracle directory servers and a check to make sure there is an available connection into the user's default Oracle Collaboration Suite Database.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Increases in the response times to the login command may indicate problems in the Oracle directory server, your network, or Oracle Collaboration Suite Database. When an increase in the latency of a command is detected, check the latency of commands to other mail protocol servers (POP and SMTP) for similar increases.
Review the Enterprise Manager metrics for the infrastructure database, the Oracle directory server, and the Oracle Collaboration Suite Database instance(s). Common issues include:
(1) Network Latencies. Check the response time between this IMAP Server and the host where the Oracle directory server is running. Check the response time between this IMAP Server and the Oracle Collaboration Suite Database(s).
(2) Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database. Apply more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
(3) Too many connections are configured for the mail protocol servers. All mail protocol servers have a minimum, maximum and increment value. The minimum number of connection is an aggregate of all server instances minimums. The maximum is an aggregate of all instances maximums. The servers grow and shrink their pools dynamically. Sustained jumps in latency during peak loads followed by a return to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release 2 (9.0.4.1)
(4) If a slow but gradual increase in response times is noted and one or more of your Oracle Collaboration Suite Databases is quite large, datasets may have become too large. Consider partitioning your Oracle Collaboration Suite Database.
This metric graphs a rate of IMAP LOGIN command failures. It is an aggregate value, counting login failures due to invalid user names or passwords, account validatation failures against an Oracle directory server, and failures to access an Oracle Collaboration Suite Database after successfully validating the account.
To successfully process an IMAP LOGIN command, the IMAP Server first communicates with the Oracle directory server to authenticate the user. A successful authentication with the Oracle directory server returns an Oracle Collaboration Suite Database to which the client will need a connection. If the IMAP Server is not able to communicate with the default Oracle Collaboration Suite Database, the login returns a failure.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
When an increase in LOGIN command failures is noted, check for the following:
Connectivity to the Oracle directory server and the Oracle Collaboration Suite Database. Check that the Oracle Collaboration Suite Database is up and running, the listener for the Oracle Collaboration Suite Database is up and running, and the connect string is registered properly in the infrastructure Oracle directory server. Also, check whether a process on the target is able to connect to and log into the Oracle directory server for the installation.
Unusually large numbers of invalid user account and password pairs attempting to log in. You can test for these conditions on a test account for each Oracle Collaboration Suite Database. If you are able to log into the IMAP Server successfully with a test account and you still notice a large number of failures, this could indicate an attack on your IMAP Server.
Check the log files to make sure there are sufficient Oracle directory server resources for your valid clients. Use esd_logscan.pl to scan the server log files.
While the IMAP Server is running with a log level of "17" or higher, the IP addresses of clients trying to log in to the server are logged in the log files. Check the log files to find out the IP addresses of clients with large numbers of failed login requests. Use esd_logscan.pl to scan the server log files.
This informational metric graphs the rate of LOGIN commands per minute during the period since the last capture of the information. Login behavior is specific to the mail client. Some mail clients will log into an IMAP Server multiple times in order to gain performance advantages. Use the LOGIN command rate to better understand the usage patterns and resource requirements of the mail system.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This section contains metrics that provide information on network resources used by the IMAP Server. This includes the number of bytes transferred to and from this server and the number of client connections to this server.
This metric shows the number of new client sessions created per minute. Mail clients typically have two type of sessions. One is a "long running session", which is usually open indefinitely and is used to get new mails in a user's Inbox. The other is type is a "short lived" session used for other housekeeping work like "check for changes in all folders" or "put a copy of sent message on server".
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
An increasing trend in this metric may indicate one or more of following:
An increase in user population and a greater number of users currently using IMAP.
A possible change in the type of mail client used by the majority of the user population. Different mail clients behave differently and may need greater or fewer numbers of IMAP sessions for normal usage.
A possible denial-of-service attack on server. Check the IMAP Server log files for any rejected connections. Use esd_logscan.pl to scan the server log files. You can can decrease the number of connections allowed from a given IP address by tuning the native flood control mechanism.
This metric indicates the rate of sessions terminated per minute by the IMAP Server due to "timeout". IMAP clients typically keep a session alive by issuing another command on the session before the timeout occurs.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Configure the session timeout parameter of the IMAP Server as needed. It is generally not necessary to increase the session timeout parameter to more than 30 minutes.
This metric shows the number of client sessions currently open on the IMAP Server. Mail clients typically have two type of sessions. One is a "long running session", which is usually open indefinitely and is used to get new mails in a user's Inbox. The other is type is a "short lived" session used for other housekeeping work like "check for changes in all folders" or "put a copy of sent message on server".
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
An increasing trend in this metric may indicate one or more of following:
An increase in user population and a greater number of users currently using IMAP.
A possible change in the type of mail client used by the majority of the user population. Different mail clients behave differently and may need different numbers of IMAP sessions for normal usage.
A possible denial-of-service attack on server. Check the IMAP Server log files for any rejected connections. Use esd_logscan.pl to scan the server log files. A native flood control mechanism can be tuned to lower the number of connections allowed from a given IP address.
This informational metric measures the amount of data the IMAP Server received per minute from IMAP clients. It includes data related to normal IMAP commands and data due to messages appended back to the server, typically to the "Sent" or "Sent Items" folder.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This informational metric measures the amount of data sent to clients per minute by the IMAP Server. The data includes mail and IMAP responses.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This category provides information about IMAP Server's internal mechanism for detecting the arrival of new mail or any other changes to message metadata in a currently selected folder.
This metric shows the average time the IMAP Server took to respond to New Mail Check commands. The latency includes the time required for the IMAP Server to communicate with an Oracle Collaboration Suite Database to be alerted to new email messages or changes to metadata for existing email messages and the time required to update information in an Oracle Collaboration Suite Database.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Increases in the response times may indicate problems in your network or your Oracle Collaboration Suite Databases. When an increase in the latency of a command is detected, check the latency of commands to other mail protocol servers (POP and SMTP) for similar increases, as they are often related.
Review the Enterprise Manager metrics for the infrastructure database, the Oracle directory server, and the Oracle Collaboration Suite Database instance(s). Common issues include:
Network Latencies. Check the response time between this IMAP Server and the Oracle Collaboration Suite Database(s).
Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database. Apply more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
Too many connections are configured for the mail protocol servers. All mail protocol servers have a minimum, maximum and increment value. The minimum number of connections is an aggregate of all server instances minimums. The maximum is an aggregate of all instances maximums. The servers grow and shrink their pools dynamically. Sustained jumps in latency during peak loads followed by returns to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release 2 (9.0.4.1))
If a slow but gradual increase in response time is noted, it means that the average size of the mailboxes in your system is also growing. If datasets have become too large, consider partitioning your Oracle Collaboration Suite Database. Also, check the usage of the sort area in your Oracle Collaboration Suite Databases. The larger the mailbox size, the more sort space in required in the sort area for this New Mail Check.
This metric represents the rate at which the IAMP Server is actually performing a "New Mail Check" for clients. This can be controlled to some extent by the "New Mail Pool Interval" parameter for the IMAP Server. The higher the value for this parameter the fewer times the server will do a "New Mail Check". Doing this check more often will increase the load on your Oracle Collaboration Suite Database and doing it less often means users may see a longer delay in getting notification about new mails. The rate of New Mail Check is an informational metric used to gain an understanding of the usage patterns and resource requirements of the mail system
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This category measures the resource usage by the IMAP Server for resources like Oracle Collaboration Suite Databases and Oracle directory server connections used by the IMAP Server.
This metric indicates the number of times per minute that the IMAP Server failed to get a database connection from the pool of database connections. This value should ideally be zero. A connection failure count of greater than zero can occur when the Oracle Collaboration Suite Database receives too many user requests within a short time span. For example, this scenario can occur after the Oracle Collaboration Suite Database comes back online after being offline for some time and all the users try to reconnect to it. In this case, the pool of connections usually stablizes on its own within a few minutes.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
To prevent the Oracle Collaboration Suite Database from being overloaded with new connections in a short span of time, limit the number of new connections allowable per per minute or increase the maximum number of connections allowed to the Oracle Collaboration Suite Database. Increase the maximum number of connections allowed to the Oracle Collaboratin Suite Database if the current maximum is to small to handle user needs under ordinary circumstances.
This metric indicates the number of database connections currently in use by the IMAP Server. This does not represent the total number of connections in pool, but a subset consisting of database connections in the pool that are currently in use.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
An increase in the number of connections currently in use may indicate an increase in IMAP workload or a slowdown in database response time. Use standard database monitoring tools to resolve resource issues.
This metric represents the number of Service Provisioning System (SPS) threads busy in the IMAP Server right now. Each busy thread represents one currently active request on an IMAP session.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
An increase in SPS threads may indicate an increase in IMAP workload or a slowdown in database response time. Use standard database monitoring tools to resolve resource issues.
The IMAP Server Response category checks the IMAP Server process to see if the IMAP Server is running. Note that the IMAP Server response does not check the IMAP service. To see if a user can log into the IMAP Server and perform mail work, refer to the IMAP Service response metrics.
Status is checked by looking for one or more IMAP processes on the target. It does not check whether or not the process has all the required resources needed to support IMAP client connections.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-5 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 5 Minutes |
After Every Sample |
= |
0 |
Not Defined |
1 |
Failed to connect to IMAP Server |
You can restart the IMAP Server by selecting the target and clicking the Restart button on the Email home page in the Enterprise Manager. To investigate why the server is down, check for alerts that may have been generated. If the IMAP server does not restart, a probable cause is that the server cannot connect to at least one of the Oracle Collaboration Suite Databases or it cannot connect to the system's Oracle directory server.
Check that a process on the target is able to connect to and log into the system's Oracle directory server.
Make sure the Oracle Collaboration Suite Database is up and running and the connect string is correctly and accurately registered in the Oracle directory server.
This category contains metrics that provide information about IMAP service security.
This represents the rate of new connection requests rejected by IMAP Server per minute. A connection refusal occurs when a server detects that too many new connection requests are coming in a short period of time from any one IP address or there are too many concurrent connections from a given IP address. You can change the number of connections allowed or the time window in which the IMAP Server counts new connection requests.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Check the IMAP Server log files to find out the IP address from which "flooding" is detected. Use esd_logscan.pl to scan the server log files. Make sure only a reasonable number of mail clients are running on this machine. If the machine is running several mail clients for the same (or different) users, the IMAP Server may detect a "flooding". If required, either increase the number of connections allowed or decrease the amount of time in which flooding is detected to the values appropriate for your site and type of mail clients used.
This category contains metrics that provide information about the SELECT command. The SELECT command is used by mail clients to 'open' the desired mailbox to start downloading new mails arrived since the last time the mailbox was opened by this client.
This metric represents the average time the IMAP Server took to respond to a SELECT command. The latency would include the time it took the IMAP Server to communicate with an Oracle Collaboration Suite Database and the time required to update information in an Oracle Collaboration Suite Database. This latency is proportional to the average size of the mailboxes in the mail system. Larger mailboxes will take longer to open.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Increases in the response times to the SELECT command may indicate problems in your network or your Oracle Collaboration Suite Databases. When an increase in the latency of a command is detected, check the latency of commands to other mail protocol servers (POP and SMTP) for similar increases, as they are often related.
Review the Enterprise Manager metrics for the infrastructure database, the Oracle directory server, and the Oracle Collaboration Suite Database instance(s). Common issues include:
Network Latencies. Check the response time between this IMAP Server and the Oracle Collaboration Suite Database(s).
Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database. Apply more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
Too many connections are configured for the mail protocol servers. All mail protocol servers have a minimum, maximum and increment value. The minimum number of connections is an aggregate of all server instances minimums. The maximum is an aggregate of all instances maximums. The servers grow and shrink their pools dynamically. Sustained jumps in latency during peak loads followed by returns to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release 2 (9.0.4.1))
If a slow but gradual increase in response time is noted and one or more of your Oracle Collaboration Suite Databases is large, datasets may have become too large. Consider partitioning the Oracle Collaboration Suite Database.
In the case of a slow but gradual increase in response time, check the usage of sort area on your Oracle Collaboration Suite Database. The larger the mailbox size, the more sort space in the sort area is required to initially open the mailbox.
This metric measures the rate of SELECT commands that failed per minute.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-6 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
300 |
500 |
1 |
The number of failed SELECTs are %value% |
The SELECT command fails if the IMAP Server is unable to contact an Oracle Collaboration Suite Database. A sudden increase in failures could also occur when an Oracle Collaboration Suite Database runs out of resources, such as disk space.
Check that the network between the IMAP Server and the Oracle Collaboration Suite Database is up and running
Check that the Oracle Collaboration Suite Database and the listener for the Oracle Collaboration Suite Database is up and running, and that the connect string is accurately registered in the infrastructure Oracle directory server.
Check that the selected folders actually exist in the system. Some mail clients work off a "subscribed" folder list. Sometimes folders in this list get deleted by other mail clients but still remain in the "subscribed" folder list. The SELECT command for such folders will always fail. In these cases the issue can be fixed by asking users to refresh their "subscribed" folder list.
This metric represents the rate of SELECT commands invoked per minute. This an informational metric used to gain an understanding of the usage patterns and resource requirements of the mail system.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
This category contains metrics that provide information about the STATUS command. The STATUS command checks a mailbox for information including the number of messages in the folder, the next message ID that will be given, or the number of recent messages.
Some mail clients use the STATUS command on an Inbox as the mechanism to check for new mail.
This metric measures the average time the IMAP Server took to respond to a STATUS request. The latency includes the time it took the IMAP Server to communicate with an Oracle Collaboration Suite Database and the time required to find information in an Oracle Collaboration Suite Database.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Increases in the response times to the STATUS command may indicate problems in your network or your Oracle Collaboration Suite Datatbase(s). When an increase in the latency of a command is detected, check the latency of commands to other mail protocol servers (POP and SMTP) for similar increases, as they are often related.
Review the Enterprise Manager metrics for the infrastructure database, the Oracle directory server, and the Oracle Collaboration Suite Database instance(s). Common issues include:
Network Latencies. Check the response time between this IMAP Server and the Oracle Collaboration Suite Database(s).
Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database. Apply more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
Too many connections are configured for the mail protocol servers. All mail protocol servers have a minimum, maximum and increment value. The minimum number of connections is an aggregate of all server instances minimums. The maximum is an aggregate of all instances maximums. The servers grow and shrink their pools dynamically. Sustained jumps in latency during peak loads followed by returns to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release 2 (9.0.4.1))
If a slow but gradual increase in response time is noted and one or more of your Oracle Collaboration Suite Databases is large, datasets may have become too large. Consider partitioning your Oracle Collaboration Suite Database(s).
This metric represents the rate of STATUS commands that failed per minute.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-7 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
300 |
500 |
1 |
The number of failed STATUSes are %value% |
The STATUS command fails if the IMAP Server is unable to connect to or retrieve results from an Oracle Collaboration Suite Database.
Check that the network between the IMAP Server and the Oracle Collaboration Suite Databaseis up and running
Check that the Oracle Collaboration Suite Database is up and running, the listener for the Oracle Collaboration Suite Database is up and running, and the connect string is accurately registered in the infrastructure Oracle directory server
The STORE command is used by mail clients to change a message's flags (for example, from "unread" to "read") or to annotate a message with additional data.
This metric measures the average time the IMAP Server took to respond to a STORE command. The latency includes the time it took the IMAP Server to communicate with an Oracle Collaboration Suite Database and the time required to update information in an Oracle Collaboration Suite Database.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |
Increases in the response times to the STORE command may indicate problems in your network or your Oracle Collaboration Suite Database. When an increase in the latency of a command is detected, check the latency of commands to other mail protocol servers (POP and SMTP) for similar increases, as they are often related.
Review the Enterprise Manager metrics for the infrastructure database, the Oracle directory server, and the Oracle Collaboration Suite Database instance(s). Common issues include:
Network Latencies. Check the response time between this IMAP Server and the Oracle Collaboration Suite Database(s).
Insufficient processor or memory or inefficient use of memory for the Oracle Collaboration Suite Database. Apply more resources to the Oracle Collaboration Suite Database or tune the Oracle Collaboration Suite Database. For more information about an Enterprise Manager metric for a database, see the Oracle Enterprise Manager online help for that metric. For more information about tuning a database, see the Oracle Database Performance Tuning Guide or other associated manuals.
Too many connections are configured for the mail protocol servers. All mail protocol servers have a minimum, maximum and increment value. The minimum number of connections is an aggregate of all server instances minimums. The maximum is an aggregate of all instances maximums. The servers grow and shrink their pools dynamically. Sustained jumps in latency during peak loads followed by a return to normal could be caused by insufficient RAM on the database to process the number of connection requests. Increase the RAM or tune the number of instances and connection pool parameters. (For more information, see Oracle Email Administrator's Guide Release (9.0.4.1))
If a slow but gradual increase in response time is noted and one or more of your Oracle Collaboration Suite Databases is quite large, datasets may have become too large. Consider partitioning the Oracle Collaboration Suite Database.
This metric represents the rate of failed STORE commands per minute.
The following table shows how often the metric's value is collected and compared against the default thresholds. The Consecutive Number of Occurrences Preceding Notification column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Table 46-8 Metric Summary Table
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold' | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
|
All Versions |
Every 10 Minutes |
After Every Sample |
> |
300 |
500 |
1 |
The number of failed STOREs are %value% |
The STORE command fails if the IMAP Server is unable to connect to or retrieve results from an Oracle Collaboration Suite Database.
Check that the network between the IMAP Server and the Oracle Collaboration Suite Database is up and running
Check that the Oracle Collaboration Suite Database is up and running, the listener for the Oracle Collaboration Suite Database is up and running, and the connect string is accurately registered in the infrastructure Oracle directory server
This metric measures the rate of STORE commands invoked to this IMAP target per minute. The rate of STORE command is an informational metric used to gain an understanding of the usage patterns and resource requirements of the mail system.
The following table shows how often the metric's value is collected.
| Target Version | Evaluation and Collection Frequency |
|---|---|
| All Versions | Every 10 minutes |