Bug #24419 Excessive alerting on "full table scans"
Submitted: 18 Nov 2006 22:30 Modified: 28 Nov 2006 18:58
Reporter: Gary Whizin Email Updates:
Status: Closed Impact on me:
None 
Category: Severity:S3 (Non-critical)
Version:1.0.0 OS:Any (all)
Assigned to: Andy Bang CPU Architecture:Any
Tags: Advisors, heat chart, mer100 readme, mer101

[18 Nov 2006 22:30] Gary Whizin 
Description:
Table Scans column in Heat Chart will frequently show "red", corresponding event fires--even on dbs with low activity

From a beta tester:

"appears to be working very well  - however all of my  
databases are RED because of excessive table scans, even servers that  
really are not used much.  Some of these are not really issues, one  
DB (who went red for table scans pretty much right away) scans a  
preferences table once every few minutes but it's only 10 rows, I'm  
sure it's always cached."

How to repeat:
see above
[19 Nov 2006 2:12] Andy Bang 
The expression for this rule involves several Handler_read_xxx status variables.  The problem is that on a lightly-loaded system, Handler_read_rnd_next can easily get incremented quickly relative to the other Handler variables and can skew the results of the evaluation of the expression.  We just shouldn't even evaluate this rule unless there's lots of activity.
[20 Nov 2006 20:40] Andy Bang 
Added the following "guard" to the expression:

&& (%Handler_read_rnd_next% > 4000)

In other words, don't trigger the rule unless there's lots of activity on the table.
[27 Nov 2006 23:35] Sloan Childers 
Fixed in r4313
[28 Nov 2006 18:58] Bill Weber 
Verified fixed with Advisor bundle 1.0.1.4289 - now on MySQL Network