MySQL Bugs: #42105: EXPLAIN/example query is not always shown for queries with

Bug #42105	EXPLAIN/example query is not always shown for queries with > 500ms runtimes
Submitted:	14 Jan 2009 10:25	Modified:	26 Apr 2011 19:39
Reporter:	Mark Leith	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Agent	Severity:	S3 (Non-critical)
Version:	2.0.1.7125	OS:	Any
Assigned to:	Jan Kneschke	CPU Architecture:	Any

Description:
EXPLAIN plans are not always shown for queries that run for greater than 500 milliseconds, as the EXPLAIN may have been purged with the work done on keeping memory usage to a minimum, or due to backlogs/delays in the server asking for the data. 

How to repeat:
No reliable test case as yet, however, running a lot of statements through Query Analysis with auto-EXPLAIN enabled should result in a number of the statements not getting an EXPLAIN plan within the statement popups within the Dashboard.

Suggested fix:
The JSON protocol should fix this, as the data would not be purged before being sent.

This also happens with the example query text too.

Bug #43212 was marked as a duplicate of this one.

Jan Kneschke writes: 
it is really accepted.

Mark Matthews writes: 
There is a possibility to fix this without JSON/REST but by letting the slot count for examples and explains be varied by the service manager, or when the agent notices that things will be "overrun"?

Jan Kneschke writes: 
After investigating #40462 it showed we use the item-hash value-caching wrongly for the QUAN case.

Under heavy query load this may result in loss of QUAN data before it could be sent up to the MEM-server. The agent log would contain plenty of lines like:

{noformat}
 (histogram_collect) can't find norm_query_inst: 0e982db4-2577-4fc0-b4d2-d1721748bfbf..efbb23290963b1cdc83186b600162246
 [quan.lua] norm_query_inst not found: 0e982db4-2577-4fc0-b4d2-d1721748bfbf..efbb23290963b1cdc83186b600162246
{noformat}

Heavy query load means that it has to take more than 20sec to send up all the QUAN data to MEM-server.

Jan Kneschke writes: 
Pushed to agent-trunk:

revno: 2003
fixes bug(s): http://bugs.mysql.com/42105
committer: jan@mysql.com
branch nick: trunk
timestamp: Fri 2011-01-14 18:57:25 +0100
message:
  fetch all QUAN data from the Lua script over to the item-hash at list-instances(mysql::statementsummary) time (fixes #42104/EM-3001)
  
  * all QUAN classes are fetched at the same time
  * data is consistent 
  * data removal is predictible

Andy Bang writes: 
Fix is in build 2.3.2.2051.

This was resolved in 2.3.2