MySQL Bugs: #47114: ENHANCEMENT request : Alert: table_has_been

Bug #47114	ENHANCEMENT request : Alert: table_has_been_altered does not tell which table
Submitted:	3 Sep 2009 20:03	Modified:	23 Oct 2009 21:55
Reporter:	yvonne kire	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Enterprise Monitor	Severity:	S4 (Feature request)
Version:	2.1.0.1096	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
ENHANCEMENT request 

ALERT: should include which table was found and that triggered the alarm

MySQL Enterprise Monitor Warning Alert: table_has_been_altered.name

How to repeat:
add a column to a table

Suggested fix:
Many of the MySQL Enterprise Monitor Warning and Alerts I get is pretty meaningless cause they could give more information for trouble shooting.
Ofcourse I want to know WHICH table got altered and it should be pretty easy to suply that info to ...

"and it should be pretty easy to supply that info"

I do not believe this is pretty easy. How will you query the server about it?
I only know: "SHOW GLOBAL STATUS LIKE 'com_alter_table';" what returns a 'global alter_table count' only.

MySQL is not really 'instrumentated' for exposing such detailed information. Of course in principle general log or binary log could be used (at least on local machine), but I do not believe much in it. It would be too load-expensive for monitoring to do.

Maybe the google patches for MySQL has some option similar to the SHOW USER STATISTICS they implemented (but they are not included in the official MySQL server release) or it may be implemented a similar way. 

Just my 5 cents

Peter
(not a MySQL person)

This is an excellent feature request, although difficult to implement as pointed out above.  We do indeed use the Com_alter_table status variable to trigger the rule, which simply says that a table was altered, but not which one.  To determine which one, we'd have to monitor the binary log for all statements, which can be expensive, although we'll probably take a look at it some day.

In the meantime, I highly recommend using the Query Analyzer as a workaround.  As we note in the advice for this rule (as of our 2.0 release):

"If Query Analyzer is enabled, browse to the Query Analyzer tab and set the filters to look for ALTER statements issued shortly before the time of this alert."