The following is a summary of rules available out-of-the-box with the Oracle cartridge. Default threshold values can be changed or scoped to specific values, generally through registry variables. These rules can be copied, modified, disabled, or customized in a wide variety of ways.
This section describes the following rules:
Rules related to instance availability, monitoring agents, and connection status.
This alarm fires when the percentage of nodes available in the cluster falls below a predefined threshold (Fatal: 0.01%, Warning: 50%, Informational: 80%). When one or more nodes in the cluster are not running (down), the cluster load balance is affected, thereby decreasing the database’s overall survivability.
This alarm fires when the PDB is not opened (stopped or mount mode). In a single instance database environment, users will not be able to connect or retrieve any information from the database.
This alarm fires when the database instance is not running (down). In a single instance database environment, users will not be able to connect or retrieve any information from the database.
This alarm fires when the connection to the instance has failed (Threshold: 0). In a single instance database environment, users will not be able to connect or retrieve any information from the database.
This alarm fires when the average connection to the database instance exceeds a defined threshold (Fatal: 10000ms, Warning: 5000ms). High latency connections to the database instance could cause severe performance problems, especially for applications connecting to the database for each query and then disconnecting when done.
This alarm fires when the database’s average response time, in milliseconds, exceeds a predefined threshold (Fatal: 50ms, Warning: 10ms). Poor database response time can slow the information retrieval from the database, resulting in degraded user experience.
This alarm is invoked upon detecting that monitored instance configured with ASM while ASM agent is not configured. All ASM data collections are stopped until the ASM agent will be configured.
This alarm is invoked when Foglight data collection has failed.
This alarm is invoked when the monitored environment is a Real Application Cluster and the CRS agent is not configured. CRS is the infrastructure layer which manages cluster coordination in a RAC environment. When the CRS agent is not configured, alarms on CRS errors and offline resource will not be invoked.
This alarm fires when the connection to the Operating System has failed (Threshold: 0). The server could be down, overloaded or the server might be inaccessible from the network. When the database machine is unavailable the database is unavailable as well, either down or inaccessible, which would cause application failure.
This alarm is invoked upon detecting the unavailability of the instance listener (Threshold: 0%). When the listener is unavailable, new connections to the instance cannot be established, and the application usability can be affected.
Rules related to Data Guard, RAC cluster operations, and backup/recovery.
This alarm is invoked when the last applied log sequence# on the archive destination indicates a gap that exceeds a predefined threshold (Fatal: 5 logs, Warning: 3 logs). Ensuring that the gap between the standby and the primary instances is kept as small as possible is important in order to prevent failover to the standby from causing large amount of data losses in a crisis situation.
This alarm is invoked when the last received log sequence# on the archive destination indicates a gap that exceeds a predefined threshold (Fatal: 7 logs, Warning: 5 logs). Ensuring that the gap between the standby and the primary instances is kept as small as possible is important in order to prevent failover to the standby from causing large amount of data losses in a crisis situation.
This alarm fires when the total number of Data Guard errors exceeds a defined threshold. Errors generated from Dataguard status could indicate failure to synchronize the standby environment with the primary.
This alarm is invoked when the numbers of standby redo logs is equal or less than the number of online redo logs (Threshold: 1). Having a number of standby redo logs that is equal or less than the number of online redo logs increases the likelihood that the primary instance’s log writer (LGWR) process will be blocked.
This alarm fires whenever the database has performed a failure to another node in the OS cluster. This could happen due to a server failure (The server that hosted the database prior to the failover), loss of connectivity or high load.
This alarm is invoked upon detecting that the RAC One Node environment has had more than one node running (up) in the last 45 minutes. Such a state can indicate that the RAC One Node was converted to a RAC environment. All data collection is stopped until either the number of nodes running is again 1, or agent configuration is carried out.
This alarm fires whenever the database has performed a failure to another node in the OS cluster. This could happen due to a server failure (The server that hosted the database prior to the failover), loss of connectivity or high load.
This alarm is invoked if the percentage of corrupted blocks within the total number of consistent reads block requests exceeds a predefined threshold (Fatal: 1%). The GC corrupted blocks statistics refers to blocks that were corrupted during transfers. A high value of this metric can indicate an IPC, network, or hardware issue.
This alarm is invoked when the percentage of data blocks that were not found in the local cache, and were therefore requested from a remote instance, exceeds a predefined threshold (Fatal: 98%, Warning: 90%).
This alarm is invoked when the average time to convert a GCS resource from Null to Exclusive, Shared to Exclusive, or Null to Shared, exceeds a predefined threshold (Fatal: 60ms, Warning: 25ms).
This alarm is invoked when the average time to retrieve a block by using Global Cache Service exceeds a predefined threshold (Fatal: 200%, Warning: 100%).
This alarm is invoked when the average time to open a GES (Global Enqueue Services) resource exceeds a predefined threshold (Fatal: 120ms, Warning: 60ms).
This alarm is invoked when the elapsed time for submitting a block request, until the block is received from the interconnect, exceeds a predefined threshold (Fatal: 60ms, Warning: 40ms).
This alarm is invoked when workload distribution across cluster nodes is unbalanced.
This alarm is invoked when a backup has failed with an error. Backups are required in order to ensure the ability to restore the database, either prior to performing a point-in-time recovery or when a media failure has damaged a current datafile, control file, or archived log. Successful completion of the backup operation is critical to ensure having a valid backup.
This alarm fires when any RMAN backup operation has never been taken for database. If the database has never been backed up, you risk losing all data in the event of storage device (hardware) failure or mistaken deletion. Lack of backup also prevents recovering data to the requested restore point, before any unwanted changes took place.
This alarm fires when the number of days that have elapsed since the successful completion of the last full backup exceeds a predefined threshold (Warning: 7 days). Backups are required in order to ensure the ability to restore the database, either prior to performing a point-in-time recovery or when a media failure has damaged a current datafile, control file, or archived log.
This alarm fires when the number of days that have elapsed since the successful completion of the incremental level 0 backup exceeds a predefined threshold (Warning: 7 days). Backups are required in order to ensure the ability to restore the database, either prior to performing a point-in-time recovery or when a media failure has damaged a current datafile, control file, or archived log.
Rules related to data files utilization, tablespaces, filesystem, and archive storage.
This alarm fires when the percentage of a used tablespace exceeds a predefined threshold (Fatal: 90%, Warning: 80%). If at least one datafile in the tablespace is configured to extend automatically (Autoextend property is set to ON), this property is taken into account, and the alarm will take into account the available space in the file system or ASM. A tablespace is a set of datafiles that contain data. A tablespace whose storage place becomes full can no longer store additional data; as a result, the application’s functionality may be adversely affected. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when the estimated time before the filesystem runs out of space falls below a predefined threshold (Fatal: 2 days, Warning: 7 days). When a filesystem reaches full capacity, writing data into the said filesystem is no longer possible. This inability to add data is critical if the database’s datafiles or control files reside on this filesystem, in which case the database’s functionality will be affected.
This alarm fires when the defined archive destination is either invalid or inaccessible. Archive destinations are used for archiving redo logs filled with redo entries. A mandatory archive destination that cannot be used (is invalid) may result in a database failure, which can lead in turn to an application or service failure.
This alarm fires when the estimated time for a mandatory archive destination to run out of space exceeds a predefined threshold (Fatal: 48 hours, Warning: 168 hours). When a mandatory archive destination runs out of space, it will become invalid, thereby resulting in a database failure.
This alarm fires when the estimated time for an archive destination to run out of space exceeds a predefined threshold (Fatal: 48 hours). When a non-mandatory archive destination runs out of space, the archive destination become invalid; however, this will not result in database failure, as the database will only stop writing archives to this destination.
This alarm fires when multiple archive destinations are defined on the same filesystem. To allow for better redundancy, it is not advisable to define more than one archive destination on the same filesystem, as a filesystem failure can result in the loss of archives on both destinations.
This alarm fires when the database is not in archive log mode. Archive logging prevents the loss of transactions, which can be critical in production environments, as in the event of a disk failure, the database is rolled forward using archive logs. When not in an archive log mode, following a disk failure the database can only be restored to the last backup point in time. All databases in any production environment should be set to archive mode.
This alarm fires when the percentage of redo logs that are waiting to be archived exceeds a predefined threshold (Fatal: 90%, Warning: 80%). A situation where all redo logs are full and no log has yet been archived can lead to extensive wait events, as all transactions need to wait to commit until at least one redo log has been archived.
This alarm is invoked when the percentage of block requests resolved from the flash cache falls below a predefined threshold (Fatal: 70%, Warning: 90%). Block retrieval is carried out significantly faster by accessing the flash cache, as this cache resides on high-performance flash SSD. Low flash cache hit ratio indicates that many blocks are being retrieved from the regular disks, possibly resulting in performance issues.
This alarm is invoked when the ratio of writes to the flash cache that were skipped (insert skip) as a result of an overloaded DBWR, has exceeded a predefined threshold (Fatal: 20 buffers). Before a buffer is being flushed to the disk, the DBWR flushes the buffer into the flash cache, to allow quicker access in other operations. When the DBWR is overloaded with operations, it will skip flushing buffers to the flashcache.
This alarm is invoked when the percentage of non-reclaimable space in the flashback area exceeds a predefined threshold (Fatal: 95%, Warning: 85%). When the flashback area becomes full, Oracle automatically deletes eligible files to reclaim space. If the percentage of non-reclaimable space amounts to 100%, Oracle will no longer be able to write to the flashback area.
This alarm is invoked when the percentage of space utilized by the flashback area exceeds a predefined threshold (Fatal: 95%, Warning: 90%). If the flashback area utilization reaches the allocated size, old flashback logs might be purged within the DB_FLASHBACK_RETENTION_TARGET window, and flashback commands that require the purged data will fail.
This alarm is invoked when, upon requesting Undo space, no space was available in the UNDO tablespace. An undersized UNDO tablespace can affect the instance’s ability to maintain the defined undo retention period, thereby leading to “Snapshot Too Old” errors.
This alarm is invoked when the instance has generated a “Snapshot Too Old” error message. When update to data takes place, an image (snapshot) of the data block before the update took place is kept in the Undo segments, to provide a point-in-time picture of the data for read consistency.
Rules related to CPU, memory, and disk I/O performance.
This alarm is invoked when the value of Instance CPU has deviated from a predefined baseline.
This alarm is invoked when the percentage of Virtualization Overhead exceeds a predefined threshold (Fatal: 15%, Warning: 5%).
This alarm is invoked when the large pool’s utilization exceeds a predefined threshold (Fatal: 99%, Warning: 90%, Informational: 80%). The large pool is used for providing large memory allocations in many situations that arise during the operations of an Oracle database instance, such as session memory in shared server environment, parallel query activity, and RMAN backup and restore operations.
This alarm is invoked when the Data Dictionary cache hit ratio falls below a predefined threshold (Fatal: 70%, Warning: 90%). Ideally, the data dictionary should always hold the entire dictionary in the cache, as performing disk reads to access dictionary metadata is a slow, resource-consuming operation, which can affect the database performance.
This alarm is invoked when the Library cache hit ratio falls below a predefined threshold (Fatal: 70%, Warning: 90%). When a query cursor is not available in the library cache, the instance is forced to hard parse the query. A hard parse, which requires reloading the SQL query into the shared pool, is a time and resource-consuming operation.
This alarm is invoked when the utilization of the shared pool exceeds a predefined threshold (Fatal: 99%, Warning: 90%, Informational: 80%). The shared pool consists primarily of the library cache, which holds cursors for parsed statements and the dictionary cache for fast, in-memory access to dictionary metadata. If the shared pool is overloaded, excessive hard parsing and possibly instance failure may occur.
This alarm is invoked when the ratio between find and create operations on the result cache falls below a predefined threshold (Warning: 100%). Low values of this ratio indicate that the result cache is being underused.
This alarm fires when the average read time for a physical read operation exceeds a threshold (Fatal: 60ms, Warning: 20ms). Bad latency in physical write and read operation can often lead to I/O bottlenecks, which can affect application performance.
This alarm fires when the average write time for a physical write operation exceeds a threshold (Fatal: 60ms, Warning: 20ms). Bad latency in physical write and read operation can often lead to I/O bottlenecks, which can affect application performance.
This alarm is invoked when the average read time for a physical read operation on a certain datafile has exceeded a predefined threshold (Fatal: 40ms, Warning: 20ms). High latency values for a specific datafile can sometimes indicate that the accessed datafile resides on slow or malfunctioned physical disks. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm is invoked when the average write time for a physical write operation on certain datafile has exceeded a predefined threshold (Fatal: 40ms, Warning: 20ms). High latency values for a specific datafile can sometimes indicate that the accessed datafile resides on slow or malfunctioned physical disks. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when the average time (ms) required for writing a redo log entry exceeds a predefined threshold (Fatal: 60%, Warning: 20%). Slow write operations to the redo logs may require transactions to wait for a long time to be committed to the database, and the resulting wait events can in turn affect the overall application performance.
This alarm fires when the average time(ms) required for writing a redo log entry during a COMMIT exceeds a defined threshold (Fatal: 60ms, Warning: 20ms). Slow write operations to the redo logs may require transactions wait for a long time to be committed to the database, and the resulting wait events can in turn affect the overall application performance.
Rules related to jobs, database objects, and alert log monitoring.
This alarm is invoked when a job is either in Broken status or Disabled state (the Disabled state is relevant only for scheduler jobs). A job can become “broken” in one of the following conditions: • In case of a scheduler job – if the number of failed attempts to run exceeds a predefined threshold (max_failures attribute). • In case of a dbms_job - if the status is explicitly set to Broken by the user (using the DBMS_JOB.BROKEN procedure), or has been marked as Broken by Oracle. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when the number of jobs that are waiting in the queue exceeds a defined threshold (Fatal: 10 jobs, Warning: 2 jobs). Too few job queue process may lead to jobs delayed execution.
This alarm fires when invalid functions exist in a database schema (Threshold: 1 object). Functions in invalid state need to be compiled successfully before they are available to be queried against. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when invalid materialized views exist in a database schema (Threshold: 1 object). Materialized views in invalid state need to be compiled successfully before they are available to be queried against. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when invalid package bodies exist in a database schema (Threshold: 1 object). Package bodies in invalid state need to be compiled successfully before they are available to be queried against. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when invalid packages exist in a database schema (Threshold: 1 object). Packages in invalid state need to be compiled successfully before they are available for execution. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when invalid procedures exist in a database schema (Threshold: 1 object). Procedures in invalid state need to be compiled successfully before they are available to be queried against. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when invalid types exist in a database schema (Threshold: 1 object). Types in invalid state need to be compiled successfully before they are available to be queried against. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm fires when invalid views exist in a database schema (Threshold: 1 object). Views in invalid state need to be compiled successfully before they are available to be queried against. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm is invoked upon any modification of a parameter in the init.ora parameter file. The Init.ora parameter file controls instance configuration parameters such as memory allocations, behavior of processes, and writing destinations. Changing init.ora parameters can dramatically affect the instance activity, including the instance’s performance and availability. Therefore, any modification of the init.ora file should be considered carefully before being carried out. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm is invoked for received alert log messages, based on the alert’s severity. The alert log file keeps track of general information regarding the instance core activity, as well as the activity of its background processes. Errors associated with these two aspects can indicate availability, usability or performance issues that require immediate attention.
This alarm is invoked when the number of errors detected in the alert log exceeds a predefined threshold. The alert log file keeps track of general information regarding the instance core activity, as well as the activity of its background processes. Errors associated with these two aspects can indicate availability, usability or performance issues that require immediate attention.
Rules related to resource breakdown, workload, throughput, and session performance.
This alarm is invoked when the value of Cache Hit Ratio has deviated from a predefined baseline.
This alarm is invoked when the value of Chained Row Ratio has deviated from a predefined baseline.
This alarm is invoked when the value of Disk Sorts Ratio has deviated from a predefined baseline.
This alarm is invoked when the value of Full Scan Ratio has deviated from a predefined baseline.
This alarm is invoked when the value of Read Consistency Overhead has deviated from a predefined baseline.
This alarm is invoked when the value of Total IC Load has deviated from a predefined baseline.
This alarm is invoked when the value of Undo Generation Rate has deviated from a predefined baseline.
This alarm is invoked when the percentage of the SQL executions that required hard parsing exceeds a predefined threshold (Fatal: 70%). A hard parse, which requires reloading the SQL query into the shared pool, is a time and resource-consuming operation, due to the overhead involved in shared pool RAM allocation and memory management.
This alarm is invoked when inefficient use of the array fetch is detected as possibly resulting in wastage of up to a predefined percentage of network packets (Fatal: 50%). When the array size is too low, the roundtrips required to fetch large number of rows increases, this creating overhead on fetching data.
This alarm is invoked when the percentage of time spent by sessions waiting on a cache buffer chain latch exceeds a predefined threshold (Fatal: 15%, Warning: 5%). Cache buffer chain latch protects a buffer list in the buffer cache. These latches are used when searching for, adding, or removing a buffer from the buffer cache. Contention on this latch can indicate the presence of a highly contended-for block (known as a hot block).
This alarm is invoked when the percentage of time spent by sessions waiting on a cache buffer LRU chain latch exceeds a predefined threshold (Fatal: 15%, Warning: 5%). Cache buffer LRU chain latch is used for scanning the LRU (least recently used) chain, which contains all of the blocks in the buffer cache. Excessive cache buffer LRU chain-related wait events can result from various causes, such as a small buffer cache, excessive buffer cache throughput, a large number of cache-based sorts, and DBWR that does not keep up with the workload.
This alarm is invoked when the percentage of time spent by sessions due to latch free wait events exceeds a predefined threshold (Fatal: 15%, Warning: 5%). Latch free wait events take place when a session that needs a latch fails to acquire the latch because it is being held by another process. As a result, the session sets an interval, after which a new attempt to acquire the latch will take place. This interval is the “latch free” wait event. There is no ordered queue for the processes waiting on a latch, so the first to grab the latch acquires it. High values of latch free wait percentage can result in severe performance issues.
This alarm is invoked when the percentage of time spent by sessions waiting on a library cache latch exceeds a predefined threshold (Fatal: 15%, Warning: 5%). Library cache latch is used for accessing library cache objects, for the purposes of cursor parsing and execution. High percentage of the library cache latch wait event can indicate that excessive hard parsing is being carried out, resulting in CPU overhead and performance issues.
This alarm is invoked when the percentage of time spent by sessions waiting on a library cache pin latch exceeds a predefined threshold (Fatal: 15%, Warning: 5%). Library cache pin latch is used when a process needs to pin an object in memory in the library cache for examination, ensuring no other processes can update the object at the same time. The library cache pin wait event usually takes place when compiling or parsing a PL/SQL object or a view. Library cache pins must be acquired in exclusive mode, to ensure that the object is not being modified. As a result, the process can spend time waiting for the execution.
When a redo buffer has been allocated, and the size of the redo is larger than log_small_entry_max_size, the kernel will allocate a redo copy latch. The number of redo copy latches is controlled by the init.ora parameter log_simultaneous_copies (Fatal: 15%, Warning: 5%). The LGWR will get all the redo copy latches before it will write redo, to ensure that no other process is writing to the currently modified redo buffers. High percentage of this latch can indicate that checkpoints and commits are being carried out too frequently, thereby possibly resulting in performance issues.
When a redo buffer has been allocated, and the size of the redo is larger than log_small_entry_max_size, the kernel will allocate a redo copy latch. The number of redo copy latches is controlled by the init.ora parameter log_simultaneous_copies (Fatal: 15%, Warning: 5%). The LGWR will get all the redo copy latches before it will write redo, to ensure that no other process is writing to the currently modified redo buffers. High percentage of this latch can indicate that checkpoints and commits are being carried out too frequently, thereby possibly resulting in performance issues.
This alarm is invoked when the percentage of time spent by sessions waiting on a shared pool latch exceeds a predefined threshold (Fatal: 15%, Warning: 5%). Shared pool latch protects the allocation of memory from the shared pool. Shared pool latch contention often indicates that too much hard parsing is being carried out, resulting in CPU overhead and performance issues.
This alarm is invoked when the value of Physical Reads has deviated from a predefined baseline.
This alarm is invoked when the value of Physical Writes has deviated from a predefined baseline.
This alarm is invoked when the value of Redo Writes has deviated from a predefined baseline.
This alarm is invoked when the value of Execute Count has deviated from a predefined baseline.
This alarm is invoked when the value of Logons Current has deviated from a predefined baseline.
This alarm is invoked when the value of commits has deviated from a predefined baseline.
This alarm monitors the retrieve throughput of the Oracle instance.
This alarm is invoked when the percentage of running processes, within the total number of processes limit, exceeds a predefined threshold (Fatal: 99%, Warning: 95%, Informational: 90%). When the number of processes running on the database reaches the processes limit, as defined in the PROCESSES init.ora parameter, new connections to the database will not be allowed and more parallel slaves will not be able to spawn. Listener connections to the instance will be denied even before reaching the actual limit, because the listener would detect that the limit is about to be reached.
This alarm fires when the number of sessions currently connected to the database is about to exceed the value defined in the init.ora parameter file (Fatal: 99%, Warning: 95%, Informational: 90%). Upon reaching the number of currently connected sessions, the database will refuse new connections, which can result in an application failure. In Oracle12C and higher versions this alarm can also be invoked at the PDB level.
This alarm is invoked when the length of a lock, which was detected during the most recent lock tree snapshot, has exceeded a predefined threshold (Warning: 30 seconds). Long running locks can lead to a queue of sessions waiting to update the locked object, and in extreme cases, can cause applications to hang.
This alarm is invoked when a session’s execution time exceeds a predefined threshold (Fatal: 123 seconds, Warning: 600 seconds, Informational: 300 seconds). This alarm can be active only when PI is installed and activated.
This alarm is invoked when the number of requested parallel queries that downgraded due to lack of resources exceeds a defined threshold (Warning: 10 operations). When the number of available parallel servers is insufficient, queries that are supposed to be executed in parallel can run slower than usual, as the query’s amount of data remains unchanged, yet fewer servers are available to handle it.
This alarm fires when the number of requested parallel queries that serialized due to lack of resources exceeds a defined threshold (Fatal: 5 operations, Warning: 1 operation). Lack of parallel servers may lead to parallel queries being slower than usual, due to serialization of the query.
This alarm fires when the percentage of busy parallel servers exceeds a threshold (Fatal: 99%, Warning: 90%). When there are not enough parallel servers available, queries that suppose to be executed in parallel might be downgrade to lower degree of parallelism or even be serialized completely.
This alarm is invoked when the value of Wait Active Total has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Administrative has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Application has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Cluster has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Commit has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Concurrency has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Configuration has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Network has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Other has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Queueing has deviated from a predefined baseline.
This alarm is invoked when the value of Wait Scheduler has deviated from a predefined baseline.
This alarm is invoked when the value of Wait System I/O has deviated from a predefined baseline.
This alarm is invoked when the value of Wait User I/O has deviated from a predefined baseline.
This alarm is invoked when the length of a lock, which was detected during the most recent lock tree snapshot, has exceeded a predefined threshold (Warning: 90 seconds). Long running locks can lead to a queue of sessions waiting to update the locked object, and in extreme cases can cause applications to hang.
This alarm is invoked when the number of PI sessions in the monitored database instance has exceeded a predefined threshold. Large number of PI sessions can cause the monitored database instance to hang.
This alarm is invoked when data has not been inserted to the performance repository for more than 10 minutes. This is a rare situation that may occur if there is a problem connecting to the monitored instance or to the performance repository.
This alarm is invoked when agent not working properly and data is not updated in the repository.