Database - Built-in Checks
Here you will find detailed information about Built-in checks for Database monitored objects.
Built-in checks are deployed automatically for a monitored object type. Once Avantra has detected a specific monitored object, each of the relevant built-in checks will be auto-deployed to the agent to begin check execution and status reporting. Built-in checks can be configured using Monitoring Parameters (e.g. to set threshold values) and can also be disabled if they are not relevant to your landscape.
ADA_BACKUP
Checks the end date / time of the most recent backup required for complete recovery of the Database.
If it's older than a configured period of time, a Warning or a Critical message is generated.
The maximum allowed age can be defined generally by using parameters BackupAgeCrit and BackupAgeWarn and the corresponding Monitoring Exception Parameters.
Additionally, the check displays an overview of all backups required for the most recent complete Database recovery.
Reference Data
| Managed System | MaxDB Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | BackupAgeWarn, and BackupAgeCrit |
ADA_DATAAREA
An alarm is raised if the data area usage exceeds some configurable threshold, or if the predicted data area exhaustion is within a configurable period of time.
Reference Data
| Managed System | MaxDB Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | ADADataUsageCrit, ADADataUsageWarn, ADADataExCrit, ADADataExWarn, and ADADataForecast |
ADA_LOGAREA
An alarm is raised if the log area usage exceeds some configurable threshold, or if the predicted log area exhaustion is within a configurable time period.
Reference Data
| Managed System | MaxDB Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ADALogUsageCrit, ADALogUsageWarn, ADALogForecast, ADALogExCrit, and ADALogExWarn |
ANY_Backup
Checks for backup maintenance plans and verifies if they were successfully executed.
If no backup maintenance plan for full backup is found, the check status will be Critical and there will be no further check evaluation.
If there is a full backup maintenance plan, the reports of this plan will be evaluated. ANY_Backup collector will select reports of the last ANYBackupSelectRange days. For the backup check to be Ok, a successful report must be found, and the finished time of the last full backup must be below thresholds ANYBackupFullWarnAge and ANYBackupFullCritAge.
Additionally, the age of the last successful backup must be below BackupAgeWarn and BackupAgeCrit, but it's not required that the last successful backup is a full backup. If the latest backup was unsuccessful, the check status will be Warning unless Critical thresholds are exceeded.
Reference Data
| Managed System | SAP SQL Anywhere Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | BackupAgeWarn, and BackupAgeCrit |
ANY_Connections
An alert is raised if the number of database connections exceeds some configurable threshold. In case the number defined in Avantra threshold ANYConnectionsNumCrit is above the number of connections allowed (SAP SQL Anywhere database option max_connections), the defined thresholds ANYConnectionsNumCrit and ANYConnectionsNumWarn will be automatically adapted to 95% and 80% of the max_connections value.
The table showing the connections details shows a selection out of hundreds of connection properties.
Reference Data
| Managed System | SAP SQL Anywhere Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ANYConnectionsNumWarn, and ANYConnectionsNumCrit |
ANY_DBSpaces
An alert is raised if dbspace usage exceeds some configurable threshold, or if the predicted dbspace exhaustion is within a configurable period of time. Exceptions to the general Warning and Critical thresholds may be defined on a per dbspace level.
Reference Data
| Managed System | SAP SQL Anywhere Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ANYDBUsageCrit, ANYDBUsageWarn, ANYDBForecast, ANYDBExCrit, and ANYDBExWarn |
ANY_Messages
The check queries for server messages within the last day. If Monitoring Parameter RunDailyCheckOnWE is false, the check queries for server messages for the last 3 days on Mondays, to make sure you do not miss any entries.
The check status is Ok if only INFO messages are found or the number of ERR and WARN messages is below ANYMessagesNumWarn. If the number of both, ERR and WARN messages is above ANYMessagesNumWarn the check status is Warning, unless the number of ERR messages is exceeding ANYMessagesNumCrit which will result in Critical check status.
If only INFO messages are found, the latest 100 INFO messages will be displayed. If ERR or WARN messages are found, INFO messages will not be displayed. The maximum number of ERR or WARN messages displayed is limited to a total number of 500 messages.
It is possible to exclude messages from being counted as WARN or ERR messages. To do so, please use Monitoring Parameter ANYMessagesExclude, see the parameterʼs documentation for the syntax details.
Reference Data
| Managed System | SAP SQL Anywhere Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | ANYMessagesNumWarn, ANYMessagesNumCrit, and ANYMessagesExclude |
ANY_MessagesStat
ANY_MessagesStat does the same as ANY_Messages — monitoring the SAP SQL Anywhere server messages, but queries it for entries within last ANYMessagesStatTimespan minutes only and reports to RealTime Monitoring.
Reference Data
| Managed System | SAP SQL Anywhere Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ANYMessagesStatTimespan, ANYMessagesStatNumWarn, ANYMessagesStatNumCrit, and ANYMessagesStatExclude |
ANY_TransLog
Determines the databaseʼs transaction and possible mirror transaction log and checks the usage of the same. An alert is raised if log usage exceeds some configurable threshold, or if the predicted transaction log exhaustion is within a configurable period of time.
Reference Data
| Managed System | SAP SQL Anywhere Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | None |
DB2_BACKUP
Checks the last full database backup and shows its start, end and runtime.
If it was not successful a Warning or Critical status is reported, depending on the exit state of the latest backup command.
Additionally, the age of the last successful backup is checked. If the last successful backup is too old a Warning is reported. The maximum age can be defined using BackupAgeCrit and BackupAgeWarn. There is also the option to define a Monitoring Parameter Exception.
The backup granularity (i.e. tablespace or database) is not considered. Tablespace backups are therefore considered in the same way as full database backups. If you use tablespace backups, you need to take care of an appropriate backup strategy. However, the granularity is displayed with the Check Result for your information.
Reference Data
| Managed System | DB2 Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | BackupAgeWarn, and BackupAgeCrit |
DB2_BACKUPSTAT
The return code of the latest backup is evaluated.
If the return code is 0, the check status will be OK, in case the value is 1, the status will be Warning. Otherwise, the status is set to Critical.
This check reports to the RealTime Monitoring. BackupResetRTMTime can be used to reset the check status back to OK automatically after a certain period of time.
Reference Data
| Managed System | DB2 Database |
| Check Cycle | Basicmp:db2backupstatwaittime |
| Depends on | DBCONNECT |
| Monitoring Parameters | BackupResetRTMTime |
DB2_CBO_STATS
Counts the number of tables/indexes with statistics not older than DB2CBOMaxAge days.
If the number of tables/indexes with up-to-date statistics is below threshold DB2CBONumEntriesUpdCrit or DB2CBONumEntriesUpdWarn the check will return a Critical or a Warning message.
ABAPDBSchema is used if you need to override the schema name for this check.
Reference Data
| Managed System | DB2 Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | DB2CBONumEntriesUpdCrit, DB2CBONumEntriesUpdWarn, and DB2CBOMaxAge |
DB2_DIAGLOG
An alert is raised if a certain number of entries with a Warning, Error, or Severe value in the Level property are found during a configurable period of time.
DB2_DIAGLOG can be configured in a very flexible way. The log parsing engine allows you to access any field of a DB2 diagnostics log entry, and you have the option to define virtually any Boolean expression in order to consider certain entries as Warning or Critical.
The check evaluation rule is: If there are more than DB2DiagLogCountCrit entries found during the past DB2DiagLogTimeSpan minutes matching the expression DB2DiagLogExprCrit, the check status will be Critical. Otherwise, if there are more than DB2DiagLogCountWarn entries during the same time span matching the expression DB2DiagLogExprWarn, the check status will be Warning. Otherwise, it will be OK.
The location of the DB2 diagnostics log file is determined by the diagpath DB2 Database parameter. In case diagpath is not set, the check returns a Warning.
DB2_DIAGLOG is not supported for systems using a remote database (i.e. if DB2DBRemote is set to 1)!
Reference Data
| Managed System | DB2 Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | AGENTALIVE |
| Monitoring Parameters | DB2DBRemote, DB2DiagLogTimeSpan, DB2DiagLogExprCrit, DB2DiagLogExprWarn, DB2DiagLogCountCrit, and DB2DiagLogCountWarn |
DB2_ExpSQL
Reports expensive SQL statements considering the I/O of all statements in query cache.
An SQL statement is considered expensive if the amount of logical and/or physical reads for the particular statement exceeds a certain amount of all logical and physical reads.
Warning and Critical thresholds can be defined for the logical and physical reads, and statements can be excluded from the check.
Reference Data
| Managed System | DB2 Database |
| Check Cycle | Full |
| Depends on | DBCONNECT |
| Monitoring Parameters | DB2ExpSQLPhysicalReadWarn, DB2ExpSQLPhysicalReadCrit, DB2ExpSQLLogicalReadWarn, DB2ExpSQLLogicalReadCrit, DB2ExpSQLExclude, and DB2ExpSQLExcludeShow |
DB2_FSLOGARCH
The check execution depends on the configuration of your DB2 UDB Database.
- The usage of the filesystem holding the active transaction log directory (as defined in the DB2 parameter logpath) is monitored using DB2FSLogActiveCrit and DB2FSLogActiveWarn. Forecasting is enabled as well, and configured using DB2FSLogArchExCrit, DB2FSLogArchExWarn, and DB2FSLogArchForecast.
Additionally, the filesystem holding the directory mirrorlogpath (if defined) will be checked as well. - The Avantra Agent will figure out the DB2 log management method in place by examining the DB2 parameters logarchmeth1 and
userexit.
If the database is running in log retention mode (also called archive logging mode) and it's configured to archive transaction log files to disk, the file systems holding the archived transaction log files are monitored using the following monitoring parameters: DB2FSLogArchWarn, DB2FSLogArchCrit, DB2FSLogArchExWarn, DB2FSLogArchExCrit, and DB2FSLogArchForecast. - If the DB2 parameter failarchpath is set, the Avantra Agent will verify if transaction log files have been archived to this location.
- Such a situation occurs in case your DB2 UDB Database was not able to archive to the primary and the secondary (if set) archive destinations, for instance, if destinations like
TSMorVENDORare used. The existence of files in failarchpath indicates a serious issue. Therefore the Avantra Agent will not monitor the amount of used space on the corresponding file system, but only count the number of transaction log files found. It raises an alert if either DB2NumFailArchLogsWarn or DB2NumFailArchLogsCrit thresholds are exceeded.
The DB2_FSLOGARCH check is not supported for systems using a remote database (e.g. DB2DBRemote is set to 1).
Reference Data
| Managed System | DB2 Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | AGENTALIVE |
| Monitoring Parameters | DB2DBRemote, DB2FSLogArchExCrit, DB2FSLogArchExWarn, DB2FSLogArchCrit, DB2FSLogArchWarn, DB2FSLogActiveCrit, DB2FSLogActiveWarn, DB2NumFailArchLogsCrit, DB2FSLogArchForecast, DB2NumFailArchLogsWarn, FSTypeLocal, FSTypeRemote, and FSMonitorNetwork |
DB2_LOGUSAGE
An alert is raised if the log space of the DB2 UDB Database exceeds some configurable threshold, or if the predicted log space exhaustion is within a configurable period of time.
Reference Data
| Managed System | DB2 Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | DB2LogForecast, DB2LogExCrit, DB2LogExWarn, DB2LogUsageCrit, and DB2LogUsageWarn |
DB2_TABLESPACES
An alert is raised if tablespace usage exceeds some configurable threshold, or if the predicted tablespace exhaustion is within a configurable period of time. Exceptions to the general Warning and Critical thresholds may be defined on a per tablespace level.
Auto-resize tablespaces are supported as well. The check considers the space available assuming that the tablespace can be resized to its limit regardless of any underlying file system limitations. If a tablespace is configured with the "unlimited" maximum size (i.e. tablespace_max_size is -1), the architectural size limit of the tablespace is considered (see also DB2 Linux, UNIX and Windows (LUW) SQL and XML Limits).
You can distinguish auto-resized tablespaces from other ones in the Check Result. If a tablespace is configured using auto-resize, you will get the following result in case of a Warning or Critical check status:
'PSAPBTABD' is used by 96.6 % (17.51 GB free, 17.51 GB auto-resize free)
Since — in the example above — the amount of actual free space in the tablespace is identical to the maximum available auto-resize free space the tablespace will not extend any further and it might be time to reorganize or to upgrade to large tablespaces.
The following example shows the situation where a tablespace still can be auto-resized:
'PA3#ODSI' is used by 9.7 % (25.61 GB free, 231.27 GB auto-resize free)
The Avantra Agent does not check if there is enough space on the filesystem to actually resize a tablespace. You need to monitor the file systems as well using FILESYSTEMS.
Reference Data
| Managed System | DB2 Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | DB2TableSpaceUsageCrit, DB2TableSpaceUsageWarn, DB2TableSpaceForecast, DB2TableSpaceExCrit, and DB2TableSpaceExWarn |
DBCONNECT
Verifies the connection to a Database. If the Database connection has been established successfully, the check will provide some additional information in its result.
If the Database connection fails, the Check Result will be Warning and after DBConnectErrsCrit subsequent connection attempts without success, the result will be Critical.
Additionally, the check serves as a overview check for all other checks executed on a Database, so if the connection fails, all the other dependent checks will return Unknown.
The DBCONNECT check therefore is the most important check for a Database.
SAP Systems with Oracle Database only: The Avantra Agent by default tries to connect the Oracle database using TNS lookup with the SAP System's Real SAP SID as TNS alias.
If this fails (for example because the TNS admin directory could not be determined) you can make use of the Parameter Set ORATNSAdminDir and ORATNSAlias.
Oracle Databases in conjunction with SAP BR*Tools only: If there is a running off-line backup, the check will return a Warning. If the elapsed time (since backup start) is ORABrbackupOfflineDelayCrit percent longer than the average total backup runtime of the last 5 full backups, a Critical alert is raised. If there are less than 2 full backups available a backup time of 4 hours is assumed.
Reference Data
| Managed Object | Database |
| Check Cycle | Daily |
| Depends on | AGENTALIVE |
| Monitoring Parameters | DBConnectErrsCrit, MSSUseNTLMv2, ORABrbackupOfflineDelayCrit, ORAHomeDir, ORATNSAdminDir, ORATNSAlias, TimeOutDBMonitor |
FULLCHECK
Returns the overall status of all Checks executed during the Daily Check on a particular SAP Instance or Database.
For instance, if the connection attempt (to the SAP Instance or Database) failed, this check type returns a Critical message. If this check fails, all other dependent checks will have status Unknown.
In the OK status, the check explains what checks were executed for a particular SAP Instance or Database, which profiles were collected, etc.
You may want to skip the execution of Daily Checks on the weekend using RunDailyCheckOnWE.
Reference Data
| Managed System | FULLCHECK Database |
| Check Cycle | Daily |
| Depends on | None |
| Monitoring Parameters | None |
HDB_Admission
Verifies that no entries have been written to M_ADMISSION_CONTROL_EVENTS during the last HDBAdmissionTimeSpan minutes. For more information on Admission Control see SAP Note 2222250.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBAdmissionTimeSpan, HDBAdmissionMaxRows, and HDBAdmissionStatus |
HDB_Alerts
Monitors the alerts generated by the statistics server. The alerts are counted according to their priority: Error, High, Medium, and Low.
The check status is set to Warning if at least one alert with priority Error or High is found within the timespan defined by HDBAlertsTimeSpan. If the number of Error alerts is above HDBAlertsErrorCountCrit or the number of High alerts is above HDBAlertsHighCountCrit the check status is set to Critical.
Since the default values for HDBAlertsErrorCountCrit and HDBAlertsHighCountCrit are both configured to 1, by default the check status is Critical starting from one Error or High alert.
The check turns to Warning if the number of alerts with rating Medium found within the timespan defined by HDBAlertsTimeSpan is equal to or above HDBAlertsMediumCountWarn, or if the number of alerts with rating Low found within the timespan defined by HDBAlertsTimeSpan is equal to or above HDBAlertsLowCountWarn.
The status for HDB_Alerts will be OK if no alerts with priority above Medium are found, and the number of Medium priority alerts is below the HDBAlertsMediumCountWarn threshold and the number of Low priority alerts is below the HDBAlertsLowCountWarn threshold.
Finally, you can exclude alerts from contributing to the check status by specifying the alert's ID using parameter HDBAlertsExcludeIDs. Multiple entries must be separated by spaces, comma, or semicolon. HDBAlertsExcludeIDs' syntax is forgiving, i. e. leading, trailing or multiple spaces will not harm and the right alerts will still be excluded as long as numeric values are found.
Excluded alerts will still be reported in the check result's overview table. They will be marked with string (Excluded) in the Alert ID column and will not be colored.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBAlertsTimeSpan, HDBAlertsErrorCountCrit, HDBAlertsHighCountCrit, HDBAlertsMediumCountWarn, HDBAlertsLowCountWarn, and HDBAlertsExcludeIDs |
HDB_Backup
This check verifies the status of the latest backup. If the latest successful backup (of any type) is older than BackupAgeCrit, a Critical check status is generated. If the backup is older than BackupAgeWarn, the check status will be Warning.
If the latest backup was not successful a Warning check status is generated.
If no backups are found in the time range defined by HDBBackupSelectRange the check status will be Critical.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | HDBBackupCompleteSelectRange, BackupAgeWarn, and BackupAgeCrit |
HDB_Certificates
This check monitors in-database certificate collections, and returns Warning or Critical check status alerts if the expiration date of a certificate, or numerous certificates, are due to expire within defined time periods.
The check can be configure to only include certain certificate collection purposes and/or certificate usages.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Full |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBCertificateValidityWarn, HDBCertificateValidityCrit, HDBCertificateValidityIgnore, HDBCertificatePurposes, and HDBCertificateUsages |
HDB_CPULoad
This Check returns the average host CPU over the last time interval configured by monitoring parameter HDBCPULoadAverageTime and compares it against the threshold parameters set. It also returns the Process CPU Load, but this is not used in the check logic.
In the Avantra Enterprise Edition this check supports Predictive Analytics.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBCPULoadAverageTime, HDBCPULoadWarn, and HDBCPULoadCrit |
HDB_DeltaMerges
This Check monitors the duration of Delta Merges. The check status turns to Warning or Critical if there is a certain number of delta merges exceeding the corresponding runtime thresholds.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | HDBDeltaMergesTimeWarn, HDBDeltaMergesTimeCrit, HDBDeltaMergesNumWarn, and HDBDeltaMergesNumCrit |
HDB_Disks
This Check verifies the usage of the filesystems (disks) used to store the HANA Database data (i.e. storage devices). You may exclude storage devices by using the exclude parameters listed below. For example, log backup storage devices might be reported with zero size since they are backed up by a 3rd party backup solution.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBDisksUsageWarn, HDBDisksUsageCrit, HDBExcludeStorageIDs, HDBExcludeStorageDeviceIDs, and HDBExcludeStorageTypes |
HDB_DisksLog
A special case of HDB_Disks, for the SAP HANA Log Areas with more restrictive thresholds.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBDisksLogExCrit, HDBDisksLogExWarn, HDBExcludeStorageIDs, HDBExcludeStorageDeviceIDs, HDBExcludeStorageTypes, HDBDisksLogUsageWarn, and HDBDisksLogUsageCrit |
HDB_DisksLogBackup
A special case of HDB_Disks, the SAP HANA Log Backups with more restrictive thresholds.
If you use a third-party tool to backup your log segments this check can be disabled.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBDisksLogBackupUsageWarn, HDBDisksLogBackupUsageCrit, HDBExcludeStorageIDs, HDBExcludeStorageDeviceIDs, and HDBExcludeStorageTypes |
HDB_ExpSQL
An SQL statement is considered expensive if its total execution time compared to the total execution time of all SQL statements exceeds a given threshold.
If you need to reset the SAP HANA internal statistics on which this check is based, you can do so by executing the following SQL statement:
ALTER SYSTEM RESET MONITORING VIEW SYS.M_SQL_PLAN_CACHE_RESET
This check ignores SYS_STATISTICS queries on the SAP HANA system DB.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | HDBExpSQLTimePctWarn, HDBExpSQLTimePctCrit, and HDBExpSQLExclude |
HDB_JobRuntime
This check monitors the duration of jobs running on SAP HANA. If jobs are found which are running longer than HDBJobRuntimeCrit minutes, the status of the check will be Critical. If jobs are found, which are running longer than HDBJobRuntimeWarn but still not longer than HDBJobRuntimeCrit minutes, the status will be Warning.
You may exclude jobs from being verified by using HDBJobNameExclude. Per default jobs with name Backup are excluded.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBJobNameExclude, HDBJobRuntimeWarn, and HDBJobRuntimeCrit |
HDB_Landscape
This Check monitors the status of the different SAP HANA hosts. It is specially useful in scale-out environments to detect switchover situations to the standby host.
The Check Result is OK as long as all hosts are active and all host's status is either OK or IGNORE. Otherwise, the Check will turn to the check status defined in HDBLandscapeSeverity.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBLandscapeSeverity |
HDB_License
The check verifies the type of the installed license. As long as a temporary license is installed, the check is Critical and the customer is pleased to install a real license. It verifies the validity of the license. If a valid license is found, the expiration is monitored. Furthermore, the difference between the peak memory usage and the licensed memory amount is monitored as well.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | HDBLicenseExpireTimeWarn, HDBLicenseExpireTimeCrit, HDBLicenseMemoryConsumWarn, and HDBLicenseMemoryConsumCrit |
HDB_LicenseCompliance
Verifies whether the SAP HANA database is being used in compliance when the license type is a Runtime License, such as a license that is used only for backing SAP applications and not to be used as a regular database by third party or custom applications.
The check will have a Warning status if Avantra is unable to determine the license type of the SAP HANA database. This will be due to the HANA parameter license_type not being set. See SAP Note 2779499 - SAP HANA Runtime License for more information.
The check will have a Critical status if the license type is a Runtime License and the monitoring user has excess roles compared to the baseline monitoring user for Avantra.
The check will have an OK status if the license type is a Runtime License and the monitoring user does not have excess roles, or if the license type is a non-runtime one.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Daily |
| Depends on | DBCONNECT |
| Monitoring Parameters | None |
HDB_LogBackup
Checks for successful/failed log backups in the past hour or a time span configurable by HDBLogBackupTimeSpan. The check will become Critical when there are only failed backups found during the time span, otherwise, it will be Warning. If there are at least one successful and no failed backups found during the time span, the check will be OK.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBLogBackupTimeSpan, and HDBLogBackupConsecutiveFailedThreshold |
HDB_LogFiles
Various reasons may cause a HANA log file to be locked. This check verifies the number of locked log files and raises an alert if there are too many locked log files.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBLogFilesWarnCount, and HDBLogFilesCritCount |
HDB_MemoryPeak
Compares the database peak memory usage (since the last restart) to the allocation limit.
:::
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBMemoryPeakUsageWarn, and HDBMemoryPeakUsageCrit |
HDB_MemoryPhysical
Monitors the physical memory usage on each host.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBMemoryPhysicalUsageWarn, and HDBMemoryPhysicalUsageCrit |
HDB_MemoryServices
Monitors the service memory usage. Compares the memory used against the effective allocation limit.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBMemoryServicesUsageWarn, and HDBMemoryServicesUsageCrit |
HDB_Services
Verifies the SAP HANA operational status i.e. if all services are started.
The check status is OK if all services are active.
The check turns to Critical if no services are found or if at least one service is not active.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | None |
HDB_SystemReplDelay
In a HANA replication scenario, this check checks the replication delay between the primary and secondary sides.
The check will not be present on HANA systems without a replication scenario.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBSystemReplDelayCrit, and HDBSystemReplDelayWarn |
HDB_SystemReplication
Verifies, if the HANA database has replicated services and if yes, checks if all secondary services are active, fully recoverable, and the replication status is active.
If the HANA database is not configured for system replication, the status of HDB_SystemReplication is OK per default. You can change this behavior by using HDBSystemReplNotFoundStatus, which allows you to define another status if system replication is not found.
If there are replicated services found, the check status is OK if all the following conditions are met:
- All secondary services must report
YESas active status. - All secondary services must be fully recoverable, i.e. must report
TRUEin column 2nd Fully Recoverable. - The replication status of all services must be reported
ACTIVE.
The check turns to Critical if one of the upper conditions is not met. In this case, please observe possible detailed information in column Repl. Status Details.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBSystemReplNotFoundStatus |
HDB_SystemUser
This check verifies the status of the user SYSTEM in the HANA database. If the user SYSTEM is deactivated, the check is OK. As long as the user SYSTEM is active (usable), the check is Warning. In case the user SYSTEM is deleted, the check is Critical.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Full |
| Depends on | DBCONNECT |
| Monitoring Parameters | None |
HDB_TableAllocationUse
Monitors the behavior of the total memory pools listed below in relation to the global allocation limit:
- ROW store
- COLUMN store
- Pool allocator: Livecache
- PERSISTENT MEMORY
This check verifies how much memory in % these pool sizes use from the defined global allocation limit. According to the parameters, the check turns to Warning or even to Critical.
This check is only available for HANA 2.00 SPS3 and later.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBTableAllocationWarn, and HDBTableAllocationCrit |
HDB_TableRowCount
Identify tables partition approaching the upper limit of the 2 billion rows. As long as the amount of the partitioned table rows is low enough, the check is OK. According to the parameters, the check turns to Warning or even Critical.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | Full |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBTableRowCountWarn, HDBTableRowCountCrit, HDBTableRowCountTopTables, and HDBTableRowCountExclude |
HDB_TenantMemoryPeak
Compares the database tenant peak memory usage (since the last reset) to the allocation limit.
Reference Data
| Managed System | SAP HANA Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | HDBTenantMemoryPeakUsageWarn, and HDBTenantMemoryPeakUsageCrit |
MSS_DBBACKUP
Checks the latest backup date/time of the SAP SID, master and msdb Database.
If the latest backup is older than a configured period of time, a Warning message is generated. For the SAP SID Database this period of time can be configured separately for each weekday.
Reference Data
| Managed System | MSSQL Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | MSSBackupAgeMsdbCrit, MSSBackupAgeMasterWarn, MSSBackupAgeMasterCrit, BackupAgeWarn, BackupAgeCrit, and MSSBackupAgeMsdbWarn |
MSS_DBUSAGE
Calculates the amount of used space in the managed Database. An alert is raised if the used space exceeds some configurable threshold, or if the predicted space exhaustion is within a configurable period of time.
Reference Data
| Managed System | MSSQL Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | MSSDBForecast, MSSDBRemote, MSSDBUsageWarn, MSSDBUsageCrit, MSSDBExCrit, and MSSDBExWarn |
MSS_EXPSQL
Reports expensive SQL statements considering the I/O of all statements in query cache.
An SQL statement is considered expensive if the amount of logical and/or physical reads for the particular statement exceeds a certain amount of all logical and physical reads.
Reference Data
| Managed System | MSSQL Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | MSSExpSQLExcludeShow, MSSExpSQLLogicalReadCrit, MSSExpSQLLogicalReadWarn, MSSExpSQLPhysicalReadCrit, MSSExpSQLPhysicalReadWarn, and MSSExpSQLExclude |
MSS_LOGBACKUP
Determines the last transaction log backup of the managed Database.
If it's older than the configurable Warning or Critical thresholds an alert is raised respectively.
If you are using the simple recovery model you may want to disable this Check.
Reference Data
| Managed System | MSSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | MSSLogBckAgeWarn, and MSSLogBckAgeCrit |
MSS_LOGUSAGE
Determines the usage of the transaction log for the managed Database. An alert is raised if the transaction log usage exceeds some configurable threshold, or if the predicted exhaustion is within a configurable period of time.
Reference Data
| Managed System | MSSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | MSSLogExCrit, MSSLogExWarn, MSSLogForecast, MSSDBRemote, MSSLogUsageWarn, and MSSLogUsageCrit |
ORA_ALERTLOG
Verifies the Oracle alert log file.
A Critical alert is raised if a certain number of the following entries is found during a configurable period of time:
- Oracle Database Error Messages: ORA-00255, ORA-00257, ORA-00270, ORA-00272, ORA-00376, ORA-00447, ORA-00470, ORA-00471, ORA-00472, ORA-00473, ORA-00474, ORA-00600, ORA-00603, ORA-01113, ORA-01114, ORA-01115, ORA-01122, ORA-01135, ORA-01578, ORA-01628, ORA-01629, ORA-01630, ORA-01631, ORA-01632, ORA-01650, ORA-01651, ORA-01652, ORA-01653, ORA-01654, ORA-01655, ORA-01656, ORA-01680, ORA-01681, ORA-01683, ORA-01684, ORA-01685, ORA-01688, ORA-01691, ORA-01692, ORA-01693, ORA-01694, ORA-03113, ORA-07445, ORA-16014, ORA-16038, ORA-19502, ORA-19504, ORA-19510, ORA-27044, ORA-27063, ORA-27072, ORA-30036.
- Messages containing
Corruptblock.
A Warning alert is raised if a certain number of the following entries is found:
- Oracle Database Error Messages: ORA-00060, ORA-01149, ORA-01555, ORA-01562.
- Messages containing
Checkpoint not complete.
ORA_ALERTLOG can be configured in a very flexible way. The log parsing engine allows you to access any field of an Oracle alert log entry, and you have the option to define virtually any Boolean expression in order to flag certain entries as Warning or Critical.
The check evaluation rule is: If there are more than ORAAlertLogCountCrit entries found during the past ORAAlertLogTimeSpan minutes matching the expression ORAAlertLogExprCrit, the check status will be Critical. Otherwise, if there are more than ORAAlertLogCountWarn entries during the same time span matching the expression ORAAlertLogExprWarn, the check status will be Warning. Otherwise, it will be OK.
The location of the Oracle alert log file is determined by ORAAlertLogLocation. If this parameter is not set, the value from the DIAGNOSTIC_DEST (for Oracle 11g and newer) or BACKGROUND_DUMP_DEST (Oracle 10g and older) parameter is considered.
A Warning Check Result will be returned if the location cannot be determined.
ORA_ALERTLOG is not supported for systems using a remote database (ORADBRemote is set to 1)
Reference Data
| Managed System | Oracle Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | AGENTALIVE |
| Monitoring Parameters | ORAAlertLogCountWarn, ORAHomeDir, ORAAlertLogTimeSpan, ORAAlertLogExprCrit, ORAAlertLogExprWarn, ORADBRemote, and ORAAlertLogCountCrit |
ORA_BACKUP
This check verifies the availability and consistency of the latest backup performed with the Oracle Recovery Manager (RMAN).
The check is only executed if parameter ORABackupTool is set to RMAN which is the default for standalone Databases.
If your database is backed up with SAP BR*Tools, you should set ORABackupTool to BRBACKUP (default for SAP System). In this case, this check is automatically deleted.
If you neither use RMAN nor the BR*Tools to backup your Oracle Database you are encouraged to disable this check.
Basically, a backup is considered available and consistent if it can be recovered byRMAN. So the check verifies if the control file, spfile, datafiles, and archive log files backups are consistent and if the point in time they can be recovered to is not older than thresholds defined in BackupAgeWarn or BackupAgeCrit. Otherwise, the check will report a corresponding Warning or Critical Check Result.
The consistency check of the backups comprises the verification of consistent SCN (System Change Numbers, Transaction Numbers) chains contained in valid incremental backups starting with a valid full backup.
The latest SCN of the newest complete incremental backup chains of the datafiles are searched for in the Redo Log Backup Sets, and starting from the oldest set, the Redo Log Backup SCNs are checked for consistency up to the last entry.
For further information on Backup Sets and SCNs, see the oracleRMANDoc.
If backups are written to disk, the check also verifies if the files are available on disk, unless ORABackupSkipFilesCheck is set, or the database is monitored remotely (indicated by ORADBRemote). The Avantra Agent needs the appropriate permissions on the file system to verify the existence of the files. Set the ORABackupSkipFilesCheck otherwise.
The check will return Critical also if no backup is found within the period defined by ORARMANSelectRange.
If you manipulate files already backed up (e.g. remove or rename them) using other tools thanRMAN,RMANmay not know about these changes. Neither does the Avantra Agent. You should run a crosscheck within RMANin this case.
The check is always related to the latest backup. It does not check if your Database can be restored using any backup before the latest one. It does, however, check if the redo logs required to restore the latest backup are all backed up, too.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | ORABackupSkipFilesCheck, TimeOutDBMonitor, ORAHomeDir, BackupAgeWarn, BackupAgeCrit, ORARMANSelectRange, ORABackupTool, and ORADBRemote |
ORA_BRARCHIVE
An overview of all BrArchive runs during the last Full Check Cycle is listed in the Check Result.
If there are unsuccessful runs the check will result in a Warning. The check is only executed if ORABackupTool is set to BRBACKUP, which is the default for an SAP System. If your database is not backed up with SAP BR*Tools, but with RMAN, you should set ORABackupTool to RMAN (default for standalone Databases). In this case, this check is automatically deleted.
If you neither use RMAN nor the BR*Tools to backup your Oracle Database, it's recommended to disable this check.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | ORABrToolsSchema, ORAHomeDir, ORABackupTool, and ORABrToolsSelectRange |
ORA_BRBACKUP
This check type comprises two different sub-checks:
- The return code of the latest backup is evaluated. If the return code is 0, the check status will be Ok, in case the value is 1, the status will be Warning. Otherwise, the status is set to Critical.
- If the latest successful backup (i.e. one with a return code
0or1) is older than a configured period of time, a Warning or Critical message is generated.
The check is only executed if ORABackupTool is set to BRBACKUP, which is the default for an SAP System. If your database is not backed up with SAP BR*Tools, but with RMAN, you should set ORABackupTool to RMAN (default for standalone Databases). In this case, this check is automatically deleted.
If you neither use RMAN nor the BR*Tools to backup your Oracle Database, it's recommended to disable this check.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | ORABrbackupSuccessFIDs, ORABrToolsSchema, ORAHomeDir, BackupAgeWarn, BackupAgeCrit, ORABackupTool, and ORABrToolsSelectRange |
ORA_BRBACKUPSTAT
This check type comprises two different sub-checks:
- The return code of the latest backup is evaluated. If the return code is
0, the check status will be OK, in case the value is1, the status will be Warning. Otherwise, the status is set to Critical. - The runtime of the backup is verified. The runtime is compared with the average runtime of the previous 2 to 5 (if available) backups, and additionally it's compared against a static time threshold. This shall help to reduce false alerts especially if average backup times are small. If the current runtime takes more than ORABrbackupDelayWarn percent longer than the average and is above ORABrbackupDelayTimeWarn minutes, the check status is set to Warning. If it takes more than ORABrbackupDelayCrit percent longer and is above ORABrbackupDelayTimeCrit minutes, the check status is set to Critical.
If we cannot compute an average, a value of 4 hours is assumed.
The check is only executed if ORABackupTool is set to BRBACKUP, which is the default for an SAP System. If your database is not backed up with SAP BR*Tools, but with RMAN, you should set ORABackupTool to RMAN (default for standalone Databases). In this case, this check is automatically deleted.
If you neither use RMAN nor the BR*Tools to backup your Oracle Database, it's recommended to disable this check.
This check reports to the RealTime Monitoring. BackupResetRTMTime can be used to reset the check status back to OK automatically after a certain period of time.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORABrbackupDelayTimeWarn, ORABrbackupDelayTimeCrit, ORABrbackupSuccessFIDs, ORABrToolsSchema, ORABrbackupDelayWarn, BackupResetRTMTime, ORABrbackupDelayCrit, ORAHomeDir, ORABackupTool, and ORABrToolsSelectRange |
ORA_DATAFILES
This check comprises two sub-checks:
- The status of each datafile is checked and a Critical alert is raised unless it's either
ONLINEorSYSTEM. - The check calculates how many auto extent increments will fit into the filesystem where the datafile is located.
If the number of increments is below ORADataFileIncrementsCrit, a Critical alert is reported, if it's below ORADataFileIncrementsWarn but not below ORADataFileIncrementsCrit, a Warning is raised.
This check verifies for each datafile if there is enough space in its filesystem. It will not check if all datafiles located in the same filesystem can be auto-extended at the same time.
The second part of the check is not available for remote databases (i.e. if ORADBRemote is set to 1).
Reference Data
| Managed System | Oracle Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORAHomeDir, ORADataFileIncrementsWarn, ORADataFileIncrementsCrit, and ORADBRemote |
ORA_DATAGUARD
This check is implemented under particular parameters, which checks on the Oracle Data Guard feature (High Availability/Disaster Recovery) for Oracle databases with eight sub-checks to ensure archive destinations fulfill specific criteria.
By default, this check is disabled for all customers and should not report back ever any results.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORADataGuardDBCount |
ORA_DBAOPER
This check verifies certain Oracle DBA operations that are executed with BR*Tools.
The operations can be selected by defining their Function IDs (e.g. as listed in transaction DB14) in ORADBAOperFunctionIDs.
The check is only executed if ORASAPToolsEnable is set to 1, which is the default for SAP Systems. For standalone Databases, this check is by default disabled (ORASAPToolsEnable is set to 0). If you enable the check, defining ORASAPToolsSchema may be required.
The check consists of two sub-checks:
- The return code of the latest finished DBA operation is checked. If the return code is
0, the check status will be OK If it's1, the check status will be Warning, otherwise, the check status will be Critical. Running operations withRC=9999are ignored. - It is verified if the latest successful DBA operation is not older than defined in the ORADBAOperAgeCrit or ORADBAOperAgeWarn thresholds. Otherwise, the check status will be set accordingly.
By default, the following operations are checked:
- Collect Optimizer Statistics
- Database verification with
DBVERIFY - Check Optimizer Statistics.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | ORADBAOperFunctionIDs, ORADBAOperAgeWarn, ORADBAOperAgeCrit, ORADBAOperSelectRange, ORAHomeDir, ORASAPToolsEnable, and ORASAPToolsSchema |
ORA_DBCHECKLOG
The result of the latest sapdba -check or brconnect -f check run is parsed. If the last run is older than 24 hours, a Warning message is raised. Data is only searched for in the time span defined by ORABrToolsSelectRange.
Otherwise, the result is not too old. It is analyzed as follows: if the result contains messages with W level, the check returns a Warning, if the result contains messages with E level, the check returns Critical.
The check is only executed if ORASAPToolsEnable is set to 1, which is the default for SAP Systems. For standalone Databases, this check is by default disabled (ORASAPToolsEnable is set to 0). If you enable the check, defining ORASAPToolsSchema may be required.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | ORAHomeDir, ORABrToolsSelectRange, ORASAPToolsEnable, and ORASAPToolsSchema |
ORA_Enqueue
This check collects enqueue statistics on timeouts, waits, and deadlocks. The statistics are temporarily stored with a timestamp. The check then verifies if the statistics values exceed one of the defined thresholds in a certain time span.
For deadlocks, absolute numbers are collected and verified. As Oracle recommends examining each deadlock, the default Critical threshold for deadlocks is set to 1.
Timeouts and waits are calculated as a ratio to the total number of enqueue requests and conversions. This allows the check to scale on huge Databases, where more enqueue requests will occur, resulting in more timeouts and wait events.
All thresholds can be configured by means of Monitoring Parameters. For each statistics value there are two separate thresholds for Warning and Critical check status available. By default, the Warning thresholds are disabled, i.e. they have the same default value as their corresponding Critical threshold. The threshold parameters are: ORAEnqueueDeadLocksCrit/ORAEnqueueDeadLocksWarn, ORAEnqueueTimeoutsCrit/ORAEnqueueTimeoutsWarn, ORAEnqueueWaitsCrit/ORAEnqueueWaitsWarn.
By setting a Critical threshold to 0 (or < 0), the associated statistics check is turned off for example, setting ORAEnqueueTimeoutsCrit to 0 disables the timeouts part of the check.
The time span by which the statistics are collected and verified can be configured using the ORAEnqueueTimeSpan.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORAEnqueueTimeSpan, ORAEnqueueDeadLocksWarn, ORAEnqueueDeadLocksCrit, ORAEnqueueTimeoutsWarn, ORAEnqueueTimeoutsCrit, ORAEnqueueWaitsWarn, and ORAEnqueueWaitsCrit |
ORA_EXPSQL
An SQL statement is considered expensive if the amount of buffer-gets and disk-reads for the particular statement exceeds a certain amount of all buffer-gets and disk-reads. Warning and Critical thresholds can be defined for the gets and reads, and programs executing the statements can be excluded from the check.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | ORAExpSQLExclude, ORAExpSQLExcludeShow, ORAHomeDir, ORAExpSQLReadWarn, ORAExpSQLReadCrit, ORAExpSQLGetWarn, and ORAExpSQLGetCrit |
ORA_FSLOGARCH
A special case of the FILESYSTEMS check for ORAARCH filesystems with separate thresholds.
The ORAARCH filesystems are detected automatically. This check is not supported for remote databases (i.e. ORADBRemote is set to 1).
Reference Data
| Managed System | Oracle Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | AGENTALIVE |
| Monitoring Parameters | ORAFSLogArchForecast, ORAFSLogArchWarn, ORAFSLogArchCrit, ORAFSLogArchExCrit, ORAFSLogArchExWarn, FSTypeLocal, FSTypeRemote, ORAHomeDir, FSMonitorNetwork, ORADBRemote, and ORAFSLogArchLocation |
ORA_LOG_MODE
This check verifies if the Database runs in archive log mode and returns Critical if not.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORAHomeDir |
ORA_SEGMENTS
The check analyzes the Oracle segments (e.g. tables and indexes) of tablespaces with dictionary extent management and permanent storage in two ways:
- If the number of allocated extents exceeds a configurable threshold of the segment's maximum number of extents (as defined by the table or index storage parameter max_extents or Critical alert is issued.
- A Critical alert is issued if the continuous space in a tablespace is not large enough to allocate another extent (known as table or index storage parameter next_extent) for a segment.
For databases with locally managed tablespaces only, the Check Result simply displays a message
Database does not contain tablespaces with dictionary extent management and permanent content.
If the check status is OK, and if the database contains dictionary extent management tablespaces, the check will display the covered tablespaces:
Segments are checked in tablespaces with dictionary extent management and permanent content: PSAPC11DB, SYSTEM
All segments can allocate another extent.
All segments' number of extents are below threshold.
Due to resource consumption, this check is by default configured to run only every 60 minutes (see ORASegsChkWaitTime) in RealTime Monitoring. This check also runs in the Daily Check.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Basicmp:orasegschkwaittime,60 |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORAExtentsUsageWarn, ORAExtentsUsageCrit, ORASegsChkWaitTime, and ORAHomeDir |
ORA_Sessions
This Check counts the number of waiting sessions, considering wait time, wait class, and wait status of each session.
For each session waiting and holding a matching wait class (at time of Check execution), the wait time is compared against a Warning and a Critical wait time threshold (Monitoring Parameters ORASessionsTimeWaitWarn and ORASessionsTimeWaitCrit). All Warning and Critical sessions are counted, and the counter is compared against a count threshold (Monitoring Parameter ORASessionsCountWait). If the count threshold is exceeded by the Critical sessions, the check will be Critical, otherwise, if the count threshold is exceeded by the Critical and Warning sessions, the check will be Warning.
The wait class of a session is considered to filter out sessions not accounting for the check status. The wait class filter can be configured by means of the ORASessionsIgnoreWaitClass Monitoring Parameter.
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORASessionsTimeWaitWarn, ORASessionsTimeWaitCrit, ORASessionsCountWait, and ORASessionsIgnoreWaitClass |
ORA_TABLESPACES
An alert is raised if the tablespace usage exceeds some configurable threshold, or if the predicted tablespace exhaustion is within a configurable period of time.
Exceptions to the general Warning and Critical thresholds may be defined on a per tablespace level.
For tablespaces with auto-extent enabled, the maximum allocatable space (in the check message labeled auto-extent free) is considered as free space for usage and remaining free space calculations, and not the real free space (labeled free) considering the currently allocated tablespace size.
The value of auto-extent free is not limited by the effective free space of the filesystems holding the tablespace's datafiles. The ORA_DATAFILES check, however, verifies if auto-extensible datafiles can be extended within their filesystems.
The details about exhausted tables are only shown when:
- Forecasting is enabled for the system (use ORATableSpaceForecast monitoring parameter)
- The tablespace is growing
- The currently used tablespace is more than 50%
- The value in 'Exhausted In' column is less than one year
Reference Data
| Managed System | Oracle Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | ORATableSpaceUsageWarn, ORATableSpaceForecast, ORATableSpaceUsageCrit, ORAHomeDir, ORATableSpaceExCrit, ORATableSpaceExWarn, and ORATableSpaceUseSegments |
PGSQL_Bloat
This check retrieves the information from the PostgreSQL database about tables and indexes that have significant bloat (disk space used before a table/index update that is now no longer needed and can be released as free space). If the bloat percentage per database is within or beyond the preset thresholds, the status of the check changes. The monitoring parameters are used to customize the bloat percentage value that is required to trigger a certain check status.
Reference Data
| Managed System | PostgreSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | PGSQLBloatTablePctCrit, PGSQLBloatTablePctWarn, PGSQLBloatIndexPctCrit, and PGSQLBloatIndexPctWarn |
PGSQL_Connections
This check executes a query to retrieve the information from the PostgreSQL Database about the available and used connections to the Database. If the ratio of active user connections is within or beyond the preset thresholds, the status of the check changes. The monitoring parameters are used to customize the percentage of active user connections required to trigger a certain check status.
Reference Data
| Managed System | PostgreSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | PGSQLConnectionsUsedCrit, and PGSQLConnectionsUsedWarn |
PGSQL_Deadlocks
This check executes a query to retrieve this information from the PostgreSQL database. The total number of deadlocks since the last PostgreSQL statistics reset is shown as well as the number of deadlocks that occurred in the last hour or since the Avantra agent restarted (whichever is earlier). The monitoring parameters can be used to customize the number of deadlocks that are required (in this time period) to trigger a certain check status.
Reference Data
| Managed System | PostgreSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | PGSQLDeadlocksWarn, and PGSQLDeadlocksCrit |
PGSQL_LongTransactions
This check executes a query to retrieve the information from the PostgreSQL database about the long-running transactions and sessions that stay in the "idle in transaction" state for too long. The check result shows if there are too many active transactions running longer than the defined threshold or if there are "idle" transactions running longer than the preset threshold. If the number is above the predefined thresholds, the system raises the alert. The monitoring parameters can be used to customize the time threshold for different types of transactions.
Reference Data
| Managed System | PostgreSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | PGSQLTransactionRuntime, PGSQLTransactionIdletime, PGSQLIdleInTransactionsWarn, PGSQLIdleInTransactionsCrit, PGSQLLongTransactionsWarn, and PGSQLLongTransactionsCrit |
PGSQL_ReplicationSlot
This check keeps track of the lag status of replication slots on a PostgreSQL Database and raises the alert if a replication slot gathered warning or critical amount of replication lag.
Reference Data
| Managed System | PostgreSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | PGSQLReplicationSlotLagCrit, and PGSQLReplicationSlotLagWarn |
PGSQL_TempFiles
This check executes a query to retrieve the information from the PostgreSQL Database about the number of temporary files. The total number of files in temporary file storage since the last PostgreSQL statistics reset is shown. If this number is above the predefined thresholds, the system alert is raised. The monitoring parameters can be used to customize the number of temp files in the storage that is required (in this period) to trigger a certain check status.
Reference Data
| Managed System | PostgreSQL Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | PGSQLTempFileWarn, and PGSQLTempFileCrit |
SIQ_Backup
The check verifies if the last backup for each database was successful. If the last backup has failed, the check result will be Warning.
Then the check looks for the last successful backup of the database. If there is none at all (at least none in SIQBackupSelectRange days) or if the time since the last dump is above threshold BackupAgeCrit, the check result will be Critical.
If there is a successful backup and the time since the last backup is below BackupAgeCrit but above SIQBackupAgeWarn the check result will be Warning.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | Full |
| Depends on | DBCONNECT |
| Monitoring Parameters | FullBackupAgeWarn, FullBackupAgeCrit, SIQBackupSelectRange, BackupAgeWarn, and BackupAgeCrit |
SIQ_Cache
The check queries the database to get information on the Main, Temp and Catalog Cache sizes, and their usages. There is a sub-check per cache (main, temp and catalog).
For the Main cache, by default we only enable the Warning status as this check alerts if there is too much free space allocated to the main cache that could indicate a cache rebalance is necessary. It is possible to also configure a Critical threshold if desired.
For the Temp and Catalog checks, we check the reverse, whether these caches are running out of space with Warning and Critical threshold configured the Temp and Catalog cache usage monitoring parameters.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SIQMainCacheUsageWarn, SIQMainCacheUsageCrit, SIQTempCacheUsageWarn, SIQTempCacheUsageCrit, SIQCatalogCacheUsageWarn, and SIQCatalogCacheUsageCrit |
SIQ_Connections
Retrieves the current database connection statistics and evaluates the number of free connections — that is, how many additional connections the database can accept. More available connections indicate better performance
If the evaluated value is less than or equal to SIQConnectionsNumWarn but greater thanSIQConnectionsNumCrit, the check result is Warning. If the evaluated value is less than or equal to SIQConnectionsNumCrit, the check result is Critical.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | SIQConnectionsNumWarn, and SIQConnectionsNumCrit |
SIQ_DataFiles
The check verifies if enough free space is available in all datafiles. If the usage or the amount of remaining free space is exceeding/falling below SIQDataFilesUsageCrit the check status will be Critical. If the usage or the amount of remaining free space is exceeding/falling below SIQDataFilesUsageWarn but is still below/above SIQDataFilesUsageCrit, the status will be warning.
The total check status is the worst of all sub-status of all datafiles. You can see the sub-result for each datafile in the table provided. This checks features Monitoring Exception Parameters, so you may define individual thresholds for certain databases.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SIQDataFilesUsageWarn, and SIQDataFilesUsageCrit |
SIQ_DataSpaces
The check verifies if enough free space is available in all dataspaces. If the usage or the amount of remaining free space is exceeding/falling below SIQDataSpacesUsageCrit the check status will be Critical. If the usage or the amount of remaining free space is exceeding/falling below SIQDataSpacesUsageWarn but is still below/above SIQDataSpacesUsageCrit, the status will be warning.
The total check status is the worst of all sub-status of all dataspaces. You can see the sub-result for each dataspace in the table provided. This checks features Monitoring Exception Parameters so you may define individual thresholds for certain dataspaces.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SIQDataSpacesUsageWarn, SIQDataSpacesUsageCrit, SIQDataSpacesForecast, SIQDataSpacesExCrit, and SIQDataSpacesExWarn |
SIQ_LongTransactions
The check retrieves all the transactions currently running and counts ones running longer than the time specified with SIQTransactionRuntime. The fewer long-running transactions are there, the better.
If the evaluated figure exceeds or equals SIQLongTransactionsWarn, but is less than SIQLongTransactionsCrit, the check result is Warning. If the evaluated figure is more than or equals SIQLongTransactionsCrit, the check result is Critical.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SIQLongTransactionsWarn, SIQLongTransactionsCrit, and SIQTransactionRuntime |
SIQ_OperationsWaiting
Evaluates the number of operations waiting for the resource governor. Fewer operations in the queue indicate better performance.
If the evaluated value is greater than or equal to SIQOperationsWaitingWarn, but is less than SIQOperationsWaitingCrit, the check result is Warning. If the evaluated value is greater than or equal to SIQOperationsWaitingCrit, the check result is Critical.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SIQOperationsWaitingWarn, and SIQOperationsWaitingCrit |
SIQ_Threads
The check retrieves a current amount of database server threads available for use. The more threads available, the better.
If the evaluated figure falls below or equals SIQThreadsWarn, but is still more than SIQThreadsCrit, the check result is Warning. If the evaluated figure is less than or equals SIQThreadsCrit, the check result is Critical.
Reference Data
| Managed System | Sybase IQ Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SIQThreadsWarn, and SIQThreadsCrit |
Syb_ATM
The check verifies if the last dump for each database was successful. If the last dump has failed, the check result will be Warning.
Then the check looks for the last successful dump for each database. If there is none at all (at least none in SYBBackupSelectRange days) or if the time since the last dump is above threshold BackupAgeCrit, the check result will be Critical.
If there is a successful dump and the time since the last dump is below BackupAgeCrit but above BackupAgeWarn the check result will be Warning.
The total check status is the worst of all sub-status of all databases. You can see the sub-result for each database in the table provided. Please note that the size of backup dump files can only be displayed if the file still exists on the file system. You may exclude databases that are not backed up using parameter SYBBackupExclude. Most databases that usually require no backup up are already excluded by default. However, you may add more databases since the backup of some databases is documented as optional in the official SAP guide 'SAP Business Suite on SAP Adaptive Server Enterprise'.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | Full |
| Depends on | DBCONNECT |
| Monitoring Parameters | None |
SYB_Backup
The check verifies if the last dump for each database was successful. If the last dump has failed, the check result will be Warning.
Then the check looks for the last successful dump for each database. If there is none at all (at least none in SYBBackupSelectRange days) or if the time since the last dump is above threshold BackupAgeCrit, the check result will be Critical.
If there is a successful dump and the time since the last dump is below BackupAgeCrit but above BackupAgeWarn, the check result will be Warning.
The total check status is the worst of all sub-status of all databases. You can see the sub-result for each database in the table provided. Please note that the size of backup dump files can only be displayed if the file still exists on the file system. You may exclude databases that are not backed up using parameter SYBBackupExclude. Most databases that usually require no backup up are already excluded by default. However, you may add more databases since the backup of some databases is documented as optional in the official SAP guide 'SAP Business Suite on SAP Adaptive Server Enterprise'.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | FullBackupAgeWarn, FullBackupAgeCrit, BackupAgeWarn, BackupAgeCrit, SYBBackupSelectRange, SYBBackupExclude, and SYBBackupOKDisplayMax |
SYB_BackupStat
The check complements the SYB_Backup with a RealTime Monitoring check, which immediately displays a Warning or Critical status when the last backup has failed. The status displayed after a backup has failed can be configured with monitoring parameter SYBBackupStatFailedStatus. SYBBackupStatFailedDisplayTime minutes after the failed backup has been detected, the check result status is reset to OK.
If a backup is currently being processed, the check verifies the current runtime since the backup start and compares it against the average backup time of the last 5 successful backups, and additionally, it's compared against a static time threshold. This shall help to reduce false alerts especially if average backup times are small. If the current runtime takes more than 50 percent longer than the average and is above SYBBackupStatDelayTimeWarn minutes the check status is set to Warning. If it takes more than 100 percent longer and is above SYBBackupStatDelayTimeCrit minutes the check status is set to Critical.
If no 5 successful backups are found the check takes the average runtime of as many backups as possible. If none is found at all, the average runtime is initialized to 2 hours.
Please note that this check does not check the age of the last successful backup. This is done by SYB_Backup.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | Basic |
| Depends on | DBCONNECT |
| Monitoring Parameters | SYBBackupStatFailedStatus, SYBBackupStatFailedDisplayTime, SYBBackupStatDelayTimeCrit, SYBBackupStatDelayTimeWarn, and SYBBackupStatExclude |
Syb_Config
This check analyses the results of the SAP ASE configuration checks. Check results are presented as a table, each result is evaluated. If at least one row in the table is PARAM_RESULT = 1, then the status is Warning. The check status is Critical if at least one row has PARAM_RESULT = 2. If all configuration check rows have PARAM_RESULT = 0, then the check status is OK.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | Full |
| Depends on | DBCONNECT |
| Monitoring Parameters | Syb_SaptoolsCreds, Syb_ConfigExclude, and Syb_ConfigOsOverwrite |
SYB_DataBases
The check verifies the durability status of all databases found and checks if it's set to full. Temporary databases have durability status no_recovery and are automatically excluded. If a database with a durability status not equal to full or at_shutdown is found, the check result will be Warning.
More importantly, the check verifies if suspect pages are reported for a database. If yes, the check status will be Critical. If a database is marked as suspect, you should find the reason for this. Usually, there are entries in the error log. Please refer to Sybase/SAP documentation on how to proceed and how to reset the suspect status.
The check table includes much information for your reference and overview. The same data is checked elsewhere, e.g. in checks SYB_DataSpaces and SYB_LogSpaces.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | None |
SYB_DataSpaces
The check verifies if enough data space is available in all databases. If the usage or the amount of remaining free space is exceeding/falling below SYBDBUsageCrit, the check status will be Critical. If the usage or the amount of remaining free space is exceeding/falling below SYBDBUsageWarn but is still below/above SYBDBUsageCrit, the status will be Warning.
The total check status is the worst of all sub-status of all databases. You can see the sub-result for each database in the table provided. This check features Monitoring Parameter Exceptions so you may define individual thresholds for certain databases.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SYBDBUsageCrit, SYBDBUsageWarn, SYBDBForecast, SYBDBExCrit, and SYBDBExWarn |
SYB_ErrorLog
The check queries the Sybase error log for entries within the last day. If Monitoring Parameter RunDailyCheckOnWE is false, the check queries the error log for the last 2 days on Sundays, and for the last 3 days on Mondays, to make sure you do not miss any entries.
The check status is OK if no entries at all or only entries with severity level 0 or 10 are found. If any entries with severity level ≥11 and ≤16 are found, the check status is Warning. If entries with severity level 17 or above are found, the check result will be Critical.
Severity level 17 means Insufficient Resources, for example, space allocation fails due to missing free extents in a data segment.
Severity level 21 and above means, that SAP ASE needs to be restarted or is damaged and must be repaired.
Please check the SAP Sybase ASE guide System Administration Guide: Volume 1 for information on severity levels and how to proceed in case you encounter severe error log entries.
Monitoring Parameter SYBErrorLogExcludeErrNums may be used to exclude certain error numbers from being checked. Enter a comma or blank-separated list of numbers to specify multiple values.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | Full |
| Depends on | None |
| Monitoring Parameters | SYBErrorLogExcludeErrNums, and RunDailyCheckOnWE |
SYB_ErrorLogStat
SYB_ErrorLogStat does the same as SYB_ErrorLog — monitoring the ASE error log, but queries it for entries within last SYBErrorLogTimeSpan minutes only and reports to RealTime Monitoring.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SYBErrorLogTimeSpan, and SYBErrorLogExcludeErrNums |
SYB_LogBackup
This check monitors if the last transaction log backup is recent enough. This is important to ensure the recoverability of your databases.
If the last transaction log dump is above SYBLogBackupAgeWarn minutes ago, but below SYBLogBackupAgeCrit minutes, the check status is Warning. If the last transaction log dump is above SYBLogBackupAgeCrit minutes ago, the check result is Critical. If a database reports a full transaction log, the check result is reported Critical. Please note that a full transaction log should usually not happen, since exhausting log space should be reported in advance by the SYB_LogSpaces check.
You may exclude databases from being checked by adding the name of the database to the comma-separated list defined by SYBLogBackupExclude. Many system databases are already excluded by default. However, databases are still checked for the full transaction log, no matter if excluded or not.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SYBLogBackupExclude, SYBLogBackupAgeCrit, and SYBLogBackupAgeWarn |
SYB_LogSpaces
This check corresponds to the SYB_DataSpaces check but verifies if enough log space is available in all databases. If the usage or the amount of remaining free space is exceeding/falling below SYBLogUsageCrit, the check status will be Critical. If the usage or the amount of remaining free space is exceeding/falling below SYBLogUsageWarn but is still below/above SYBLogUsageCrit, the status will be Warning.
The total check status is the worst of all sub-status of all databases. You can see the sub-result for each database in the table provided. In contrast to SYB_DataSpaces, this check does not feature Monitoring Parameter Exception.
Reference Data
| Managed System | SAP ASE Database |
| Check Cycle | (../../Glossary/#check-cycle) |
| Depends on | DBCONNECT |
| Monitoring Parameters | SYBLogUsageCrit, SYBLogUsageWarn, SYBLogForecast, SYBLogExCrit, and SYBLogExWarn |