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.