Team with the best
Database Performance Tools
company in the World
Database Performance Tools
company in the World
| Feature/Capability |
DBI
Brother-Hawk |
IBM DB2
Health Monitor |
| Capable of sending email alerts to one or more individuals | Yes | Yes |
| Provides the ability to customize the format and contents of email alerts. Alerts emails can be sent as plain text, HTML, or short SMS Text messages. | Yes | No |
| Capable of sending SNMP trap alerts to central consoles such as Tivoli, Nagios, CA-Unicenter, or HP-OpenView. | Yes | No |
| Alert squelch feature that suppresses duplicate alerts for a customizable period of time, which minimizes alert noise. | Yes | No |
| Provides alerts based on real-time (current situation) observations | Yes | Yes |
| Provides alerts based on near real-time recent historical advanced computations and analysis | Yes | No |
| Provides the ability to automatically execute one or more DB2 or operating system commands when an alert triggers - virtually limitless automated response capability | Yes | No |
| Provides alert rule filters allow a rule to apply to all databases, a particular database, or even to a specific table in a specific database. | Yes | No |
| Provides the ability to tailor alert rules such that they apply to only certain times of the day or certain days of the week, plus the ability to govern the alert check frequency interval (number of minutes between checks). | Yes | No |
| Capable of providing alerts on automatic storage utilization and tablespace utilization | Yes | Yes |
| Capable of providing an alert to let you know that DB2 is "up" or not. | Yes | Yes |
| Capable of providing an alert on tablespace operational state | Yes | Yes |
| Provides alert capabilities for Private and Shared Sort Memory Utilization, plus percentage of sorts that overflowed SORTHEAP | Yes | Yes |
| Capable of providing alerts on the need for Table Reorganization, Statistics Collection, and Database Backup | Yes | Yes |
| Capable of providing alerts on HADR Operational Status and Log Delays (but why are you using HADR when you should be using Xkoto Gridscale for Active-Active continous availability?) | Yes | Yes |
| Capable of providing alerts on Log Utilization | Yes | Yes |
| Capable of providing alerts on Deadlock rates, Lock List Utilization, Lock escalation rates, and the number of Applications/Connections Waiting on Locks | Yes | Yes |
| Provides alerts for a poor Catalog Cache Hit Ratio | Yes | Yes |
| Capable of providing alerts for a poor Package Cache Hit Ratio (but supposedly DB2 automatically tunes this, so what is the need?) | Yes | Yes |
| Capable of providing alerts for a poor Shared Workspace hit ratio | Yes | Yes |
| Capable of providing alerts for Monitor Heap Utilization | Yes | Yes |
| Capable of providing alerts for Database Heap Utilization (but, again, DB2 automatically tunes this, so why is an alert needed?) | Yes | Yes |
| Capable of providing alerts for Catalog Cache Overflows | Yes | No |
| Capable of providing alerts for Package Cache Overflows | Yes | No |
| Capable of providing alerts for poor overall database health (a low database score indicating substantial problems or opportunities for improvement) | Yes | No |
| Capable of providing alerts for poor database partition performance and key performance indicators related to partitions | Yes | No |
| Capable of providing alerts for bufferpool hit ratio performance | Yes | No |
| Capable of providing alerts for database files closed | Yes | No |
|
Capable of providing alerts when an SQL or XQuery statement uses a high percentage of CPU, in the aggregate, compared to other statements,
within a specified timeframe (for example, during the past 15 or 30 minutes)
*** REAL PROBLEM *** |
Yes | No |
| Capable of providing alerts if a table incurs an excessively high percentage of Read I/O, in the aggregate, compared to other tables. | Yes | No |
|
Capable of providing alerts if "Table Rows Read per Transaction" breaches a defined threshold which would indicate excessive scans and CPU
utilization are occuring.
*** REAL BIG PROBLEM *** |
Yes | No |
| Capable of providing alerts when an SQL or XQuery statement uses a high percentage of Sort Overflows or Sort Time, in the aggregate, compared to other statements, within a specified timeframe (for example, during the past 15 or 30 minutes) | Yes | No |
| Able to provide alerts if overall disk read time (ORMS) becomes too high for the database or a tablespace | Yes | No |
| Able to provide alerts if overall disk write time (OWMS) becomes too high for the database or a tablespace | Yes | No |
| Able to provide alerts if the Asynchronous Pages Read per Request (APPR) is too low - indicating that prefetch I/O is failing and causing performance degradation | Yes | No |
| Able to provide alerts if the database Asynchronous Write Percentage (AWP) is too low | Yes | No |
| Able to provide alerts if the number of Logical Index Reads per Transaction (LITX) is too high - indicating the likelihood of Index Leaf Page scans and unnecessarily high CPU consumption | Yes | No |
| Able to provide alerts if the Synchronous Read Percentage (SRP) is too low - indicating excessive asynchronous prefetch I/O and the likely need to create missing indexes or provide higher quality indexes. | Yes | No |
| Can provide alerts for poor XQuery performance including, but not limited to, a low XQuery bufferpool hit ratio or a low XQuery Synchronous Read Percentage | Yes | No |
| Can provide alerts if average lock wait time is too high, there have been too many lock escalations, there is insufficient Locklist memory, there are too many locks per transaction, or there are excessive lock timeouts. | Yes | No |
| Can provide alerts if Index Cluster Ratios are too low, table statistics are missing, or if Indexes are defined without the MINPCTUSED clause. | Yes | No |
| Can provide alerts if the average number of Hash Joins per Transaction is too high - indicating that indexes are missing and CPU utilization is too high. | Yes | No |
| Able to provide alerts if the Index Read Efficiency (IREF) metric is too high for the database, a database partition, or a SQL statement - indicating that costly scans are occuring and CPU utilization is too high | Yes | No |
| Capable of providing alerts if CPU Busy Percentage is too high on the server, or if the database server's paging rates are too high | Yes | No |
|
Able to provide an alert if database transaction response time averages, during a recent time period, exceed a certain response time
threshold. Simply stated, the ability to tell you if response times stink.
*** HUGE PROBLEM *** |
Yes | No |
|
Able to provide an alert if Service Level Agreement response time targets are not being met. In other words, the ability to notify you that
you are not meeting your SLA targets.
*** REAL BIG PROBLEM *** |
Yes | No |
|
Provides the extensible capability to alert on ANY condition! If you can code a SQL statement to test the condition,
Brother-Hawk can provide an alert! You can even alert on business data - for instance, low inventory conditions or excessive bank
withdrawals!
*** REAL BIG OPPORTUNITY *** |
Yes | No |
| Provides federated database Nickname operational status and Data Source Server alerts | No | Yes |
| Has a reputation for being buggy, causing locking and memory problems, and having high overhead (Here is one independent consultant's view: http://www.ebenner.com/db2dba_blog/?p=84 ) | No | Yes |
