New Year Wishes for Customers of Oracle's MySQL Technical Support Services

Dear Oracle Customers,

I am sure you are mostly happy with MySQL software and support services that Oracle MySQL Support provides. For any experienced DBA MySQL software mostly works "as expected" and when any Oracle customer has a problem she can just call and get proper advice, workaround or solution, 24x7, in frames of a new support request.

In some (rare) cases though MySQL software does NOT work as expected and documented and you may think that you had actually found a new bug. Typical action in this case, encouraged by Oracle, is, again, to open a new support request and work with assigned engineer on a bug report. Engineer will tell you eventually if you hit a known bug, if there are any workarounds for your specific case and, if needed, will open, verify, escalate and monitor processing of the new bug based on your support request and use case. In 99.99% of cases (should be 100, by Oracle rules) this bug report will be created by Oracle support engineer in Oracle's internal bugs database that you can search and access, to some extent, via the same interface you use to work with your support requests or knowledge base articles.

I am sure this works good enough for most of you in most cases. But I am also sure that some of you had cases when the bug that you remember can not be found, or search is slow and produce too many hits (efficient searching in Oracle knowledge base used to be not that easy even for support engineers) or you do not get bug fix as fast as you expected and support request ends up closed with workaround and bug waiting for some future version or decision that nobody can tell you anything definite about, no matter how many times you ask.

All these problems can become easier to solve if you, customer of Oracle MySQL Technical Support, will try the following procedure instead:

1. When you suspect that you are hit by the bug in MySQL software, report it first at http://bugs.mysql.com. Surely you should not report security issues this way or provide any customer sensitive information there, but if without these sensitive details bug report still makes sense, just create it and tell the entire world about the problem found. Share the stack trace, wrong results case, undocumented or improperly documented behavior. You can do this via account that is not associated with your business or company name if you wish.

2. Then immediately open support request and inform Oracle about bug number for the bug report you had created. You can provide all missing details requested by Oracle engineers in frames of support request, but, please, share all substantial, nonsensitive and not security related information in public bug report as well, or ask Oracle engineer to do this for you. Basically, ask Oracle to process your bug report and inform community if it is accepted as a new bug, duplicate of a known bug or if any further testing/information is required. Some bug reports can be a result of your misunderstanding of the manual or improper use of some feature, but even in this case it would be nice to see public explanation why this is not a bug.

This procedure should not be used for bugs with clear security implications - for them you should probably inform only vendor and/or security related organizations. Otherwise, I think, it is almost as easy as just creating new support request (you will be asked to provide details about the problem anyway), but gives the following benefits to Oracle customer:

1. Bug report at http://bugs.mysql.com can be easily found later using search interface of public bugs database or just by using Google search for the site, like this:

site:bugs.mysql.com drop add index InnoDB

2. Bug report becomes visible to other customers, community members and MySQL support providers and developers outside of Oracle. You can get valid advice, workaround or even patch/bug fix faster as a result. Or, at least, you can get opinion of others and more reasons to escalate the bug for Oracle (if other customers and well known community users will see it and find out they are also affected).

Several Oracle (and, before that Sun's and MySQL AB's) customers had used this approach having valid support contract in place and I hardly remember any negative result of this over years. If you think that some articles in your support contract does NOT let you apply the procedure above, well, you can try to change these requirements while renewing it or signing new ones.

Why I care how Oracle customers report bugs, being not associated with Oracle for several months already, one may ask? That's because I've spent many years processing bugs at http://bugs.mysql.com and I still want to see it as a central location of all information related to MySQL bugs and feature requests. I think this is useful for all parties: Oracle MySQL support and development teams, Oracle customers, community users and alternative vendors of MySQL-related software and services.

Best wishes to you all in the New Year of 2013, year of MySQL 5.6 GA release and many interesting MySQL-related events! May your backup and restore strategy work as expected and you never need to report any bug in MySQL.  But if you'll hit something that looks like a bug next year, please, try to remember this post and think twice on how to report it.

Good bye, Oracle...

Most of my current and former colleagues already know this, others who care could probably note my unusually low activity at http://bugs.mysql.com, but still formal announcement is needed. August 31, 2012 was my last working day at MySQL Support team in Oracle. I've spent great 7+ years in MySQL Support, but I think that Oracle is no longer the best place for me to work at. It's time to pass Redwood Shores (I had never been there anyway).

Now I am support engineer at Percona. This is what may happen when you read http://www.mysqlperformanceblog.com/ too often and even quote it to customers, no matter if they are MySQL AB, Sun or Oracle customers.

I hope with all these new duties, procedures and events I'll still be able to contribute something useful to MySQL community bug reports, both at http://bugs.mysql.com and at lp:percona-server.

How to create a MySQL bug report that someone would like to read and comment on

It happens to me almost every day. I note some "bug report" at http://bugs.mysql.com that makes me think that my job is miserable... Like this, Bug #66580. What readers of such a bug report are supposed to do with it? Other than ignore?

Today I want to stay positive, so instead of cursing in public let me give some advices inspired by this great HOWTO and detailed instructions from MySQL site.

Before you send a problem report to MySQL public bugs database, please:

• Try to find similar bugs by searching MySQL bugs database. Google search for site:bugs.mysql.com <something specific, like stack trace or message from the error log> usually works good enough
• Try to find a solution to similar problem by searching the Web
• Try to find a solution/reason by reading the manual (you may get links to the manual while searching the Web...)
• Try to find a solution by reading other online documentation, forums and blogs
• Try to find a reason for your problem by inspection or experimentation
• Try to find a reason for your problem by asking a skilled friend (#mysql channel at irc.freenode.net could be a nice place to find some friends of this kind)
• If you're a programmer, try to find a reason by reading or tracing the source code, inspecting core files created etc

Only if, after all these steps, you are still not able to solve your problem and still sure that the reason is the bug in MySQL, it starts to make some sense to create a new bug report.

When you send a problem report to MySQL bugs database, please:

• Provide meaningful, specific subject/summary and description. Describe the symptoms of your problem or bug carefully and clearly
• Write in clear, grammatical, correctly-spelled English language
• Be precise and informative about your problem:

1. Describe the environment in which it occurs (MySQL software version, hardware, OS, application, whatever). Provide configuration file content and attach the entire MySQL error log (compressed if it is large).
2. Describe the research you did to try and understand the problem before you reported it
3. Describe the diagnostic steps you took to try and pin down the problem yourself before you reported it
4. Describe any possibly relevant recent changes in your hardware or software configuration
5. State explicitly what exactly you consider a bug in this case, and why
6. Ideally, you should provide a complete test case and/or instructions that any reader can use to reproduce your problem
   

• Make sure the problem is repeatable with latest officially released version of MySQL software you use
• Finally, do not report the same problem or bug more than once (unless you had found a regression bug in a recent version that was already reported before and closed). Better add your comments to existing bug report (that will be re-opened automatically in this case)

Please, remember that while it is (theoretically) possible to get free support at MySQL bugs database (and sometimes it may be even fast and good), it is neither proper nor best place to ask for it.

It's all about bugs...

I've spent more than 7 years processing bug reports at bugs.mysql.com. That was the only public place where I've discussed MySQL. Soon this will be the other.