MySQL and Other Topics in RMOUG SQL>Update Winter 2010 Edition

The Winter 2010 edition of RMOUG SQL>Update (the newsletter of the Rocky Mountain Oracle Users Group) arrived this week. It had several interesting articles that I'll reference here. As usual, the newsletter was largely oriented toward database administration, but I still found some things of interest to developers.

Peggy King's "From the President" column provided a summary of RMOUG happenings in 2010. About Training Days 2010, King states, "Over eighty speakers from RMOUG and around the world came together to present what has become known as one of the top Oracle conferences." I presented at RMOUG Training Days 2010 on REST and Groovy and will be presenting on Groovy and HTML5 at RMOUG Training Days 2011 next month.

King also states in her column that over 25 Oracle Aces/Ace Directors attended Training Days 2010 and that 2010's edition was the first to feature an Oracle Ace Panel. Peggy also highlighted RMOUG's three quarterly training meetings, the RMOUG newsletter SQL>Update, and other RMOUG events in 2010.

Technical articles featured in the Winter 2010 edition of RMOUG SQL>Update include Steven Feuerstein's "Guarantee Application Success." A "PL/SQL Evangelist for Quest Software since January 2001," Feuerstein starts his article with these two sentences:

The lawyers at Quest Software asked me to clarify something right up front: using our software will not guarantee that you will be successful. Having said that, I do believe that if you follow the ideas in this paper and my presentation you are likely to improve the chances of delivering a successful application.

The presentation referenced in that quote is probably the Oracle OpenWorld 2010 presentation Guarantee Application Success and is probably related to Guarantee Application Success with the Toad Development Suite. In the article, Feuerstein sets up criteria that an application must be correct, fast enough, and maintainable and then goes into the general high-level approaches he believes should be followed to achieve these desirable criteria. Although PL/SQL is mentioned specifically, most of these ideas apply to development in any language.

John Krahulec's "Enterprise Social Networking: It's Now Ready for the Workplace" begins with an introduction to "Enterprise Social Networking." Krahulec states that "Enterprise Social Networking connects People to People and People to Information." He writes about the merits of social networking and how to deliver those merits to the enterprise. He also discusses the obstacles to adoption of enterprise social networking and discusses use of an Oracle database in application of an enterprise social network. I am interested to see if Enterprise Social Networking continues to grow or if it will fizzle out because of various issues and concerns.

In "ASM - The Next Generation," Tim Mishek looks at the current state of Automatic Storage Management. After describing ASM Dynamic Volume Manager, ASM Clustered File System, ASM Configuration Assistant (asmca), ASM Command Line Interface (ASMCMD), and other issues related to ASM, Mishek concludes, "Oracle has really done it right. Not only is ASM an absolute necessity for database clustering technologies, but is now a better option for general database storage. ... ASM has become a full featured storage solution."

The most interesting article in this edition of the newsletter for me is the single page article "Four Things to Know about MySQL" by Benjamin Wood. During Oracle's acquisition of Sun and its MySQL assets, some were concerned that Oracle only wanted MySQL to kill it. Several Oracle actions since the acquisition have proven otherwise. This article on MySQL by an Oracle Sales Consultant in a magazine heavily targeted at Oracle database administrators is further evidence that Oracle plans to continue supporting and providing MySQL. Wood provides explanation for his "four things," but I only list the four items here (see page 20 of the newsletter for the explanations). The four things Wood states we should know about MySQL follow:

1. MySQL is Now an Oracle Product
2. MySQL Powers the High Volume Web
3. MySQL Powers Critical Infrastructure
4. Oracle 11g and MySQL Work Together

Wood ends his article by explaining how to acquire MySQL from edelivery.oracle.com. He concludes, "Leverage your Oracle knowledge and get started with the world's most popular open source database -- now an Oracle product!"

Dan Hotka is the subject of the "RMOUG Member Focus" column. It is interesting to read about the technology advancements he has seen in his career. It is also interesting to read about the various twists in his career that I believe most of us experience if we stay in the technology-oriented careers long enough.

Heidi Kuhn is the subject of the "RMOUG Board Focus" column. As the RMOUG Administrative Assistant, Kuhn has access to interesting statistical information about RMOUG. Her column includes pie charts indicating the membership types in RMOUG ("Individuals" dominate with 77% of the memberships) and the percentage of RMOUG members associated with a company (67% associated with a company, 32% individual, and 1% students). Perhaps most interesting of all is the line chart showing RMOUG membership from 1998 through 2010. Current numbers (less than 1000 members) are the lowest on the chart and the peak was in the early 2000s (~2000 members).

Although Oracle now owns many products outside of the Oracle database, I don't think there's any question that RMOUG is still primarily made up of database administrators and focused on database administration. That being stated, RMOUG does work to have presentations at Training Days that are not database related (mine are typically good examples of this) and to address other technology areas as well. Although I'm not a DBA and have no desire to become one, I do find it advantageous to know at least a little about the database.

JavaOne 2010/MySQL Sunday: You Know Databases, So How Hard Can MySQL Be?

Sarah Novotny presented You Know Databases, So How Hard Can MySQL Be? at MySQL Sunday.  This is my summary of that presentation.  As I stated in my summary of Ronald Bradford's MySQL Sunday presentation MySQL Idiosyncrasies that Bite, I'm far from a MySQL expert and any errors in this summary are likely mine in interpretation.

There are terminology differences between Oracle and MySQL that can cause confusion.  There are not always direct translations between Oracle and MySQL terms and concepts.  For example, Oracle has a database, instance, and schema, but MySQL treats all three of these concepts as database.  Notvotny described approximate MySQL equivalents to Oracle's System Global Area (SGA) and User Global Area (UGA).

Novotny pointed out several tips to make using MySQL easier. She said to flush privileges and use minimal privileges. Like Ronald Bradford, Sarah Novotny generally recommended using the InnoDB storage engine rather than the MyISAM storage engine because InnoDB is more likely to do what people familiar with Oracle expect. Novotny stated that InnoDB employs row-level locking while MyISAM employs table-level locking.  An interesting read related to these two storage engines is Should you move from MyISAM to InnoDB?

Novotny inserted several "short diversions" into her presentation.  One of these was to recommend the Second Edition of High Performance MySQL. She emphasized that the first edition should now be avoided because it is very out of date unless using MySQL 4.  I also enjoyed the fact that a developer was used as an example of accidental exploitation of MySQL vulnerabilities when a DBA doesn't set up the database security/privileges/permissions appropriately.  That theme was 2 for 2 in the MySQL presentations I attended today.

Novotny recommended several free tools including Innotop, Maatkit, MySQL proxy, and cacti templates.  Her recommended additional resources include irc.freenode.org (#mysql and #maatkit), mysql.com, and the previously mentioned book High Performance MySQL (Second Edition). The slides for this presentation are available online at http://www.slideshare.net/sarahnovotny/you-know-databases-how-hard-can-mysql-be.

JavaOne 2010/MySQL Sunday: MySQL Idiosyncrasies that Bite

I attended Ronald Bradford's MySQL Sunday presentation MySQL Idiosyncrasies that Bite and this post is a summary of what I got out of it.  Please keep in mind that I am more familiar with the Oracle database and the PostgreSQL database than I am with MySQL, so any errors in my summary are probably my own misinterpretations of what Bradford stated.  The last time I used MySQL was in my Ruby/Rails days.

Bradford's presentation focused on idiosyncrasies of the MySQL database, especially as contrasted to the Oracle database behavior.  One of his first slides was titled "Oracle != MySQL" and that was a pretty concise description of his presentation, that had many more details.  On the slide titled "Oracle != MySQL," Bradford listed five bullets describing overall explanations why they are different: age, development philosophy, target audience, developer practices, and installed versions.

Bradford stated that the storage engine concept is likely the most foreign MySQL concept for Oracle DBAs. He recommended using InnoDB as the storage engine, but MyISAM is the default storage engine for MySQL until InnoDB takes that role with MySQL 5.5.

One of Bradford's slides listed five RDBMS characteristics (data integrity, transactions, ACID, data security, and ANSI SQL) that are not supported in MySQL by default. Bradford outlines several options that should be specified by setting SQL_MODE appropriately.  These included STRICT_ALL_TABLES (disallow out of range values without silent truncation), NO_ZERO_DATE (disallows zero dates), NO_ZERO_IN_DATE, NO_ENGINE_SUBSTITUTION, and ONLY_FULL_GROUP_BY.  On one his final slides, Bradford references http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html for a list of available SQL_MODE options and includes some options to avoid (such as PIPES_AS_CONCAT and POSTGRESQL) in red.  Bradford warned that SQL_MODE settings should be set correctly initially rather than once in production because changing them too late can lead to less than desirable results.

One potential gotcha when first using MySQL is the misuse of variable scopes.  The default scope is GLOBAL starting with 5.0.2, but was SESSION before that version.  It was also noted in this presentation that Oracle's READ COMMITTED is different than MySQL's READ-COMMITTED.  InnoDB's current default is REPEATABLE-READ.  Bradford's main point here is that a DBA should not use MySQL's READ-COMMITTED simply because he or she is used to using Oracle's READ COMMITTED.  Although both Oracle and MySQL have isolation levels, the various levels are not necessarily exactly the same.

Bradford warned of a couple other common mistakes he sees people new to MySQL make.  One is not fully understanding case sensitivity dependent on underlying platforms.  A second mistake is using the command GRANT ALL ON *.* TO user@’%’ which grants even the SUPER privilege.  As is common in presentations given by DBAs, the anecdotal story of this gone wrong involved a developer who should not have been allowed to cause havoc if this permission had not been accidentally set.

Although I'm not very familiar with MySQL, this presentation was developed and delivered in such a way that I was able to stay involved with it and understand the majority of Bradford's points and examples.  Bradford has presented this presentation before and those slides are available for download. Although I don't use MySQL regularly, I found the presentation to be interesting and informative and expect it to be useful when I do use MySQL in the future.

Who Should Oracle Sell MySQL To?

There is no shortage of people calling for Oracle to sell MySQL. I keep reading that Oracle should sell MySQL to "a suitable third-party" or to a "neutral third party." I understand why these people feel passionate about this, but "loose" terminology like this is always dangerous. It implies that this is an easy thing to do and that there is a line of suitors out there waiting to snap up MySQL for a fair market price.

I wonder if there is a line of potential MySQL purchasers out there just waiting for an opportunity to bid on MySQL. Should Oracle have to shed MySQL even for a low-ball price in the name of market competitiveness? Can a company make significant money off of MySQL? Did Sun make money off of MySQL? Should Oracle or Sun take a loss on MySQL in the name of community betterment? Should another company purchase MySQL even if they don't believe they can ever earn back their investment (without even considering a desired profit margin) in the name of community betterment? Is eminent domain a consideration here?

Some companies make money related to shepherding open source projects; many do not. Ironically, at the time it seemed that Sun's purchase of MySQL overshadowed Oracle's purchase of BEA. Sun purchased MySQL for roughly one billion U.S. dollars ($800 million cash plus $200 million debt assumption). Can Oracle expect to get at least that for MySQL? Or, is MySQL worth more or less than that now? One could argue its only worth what someone else will pay for it. Is someone willing to pay more than $1 billion for MySQL? Should Oracle be forced to sell MySQL to the highest bidder regardless of the amount bid?

I have no idea what the fate of MySQL would be under Oracle, but I am almost as curious and uncertain about what price Oracle could get for MySQL. It is probably much like my most trusted old cars have been: they have been worth quite a bit more to me because they are cheap to own and operate and I know they are in good condition. However, they are not worth nearly as much to anyone else. I wonder if this is a similar case: is MySQL worth much more to Oracle than it is to anyone else? One could make an argument that "the community" values MySQL more, but it is nearly impossible for "the community" to purchase something like this for any reasonable price. What would be required in that case is either Oracle donating MySQL or selling it at significant discount or a "representative" of the community stepping forward to purchase it. Is there any organization out there ready to step up and be that representative? Does any organization have sufficient selfish motivation to do this?

It's easy to suggest that Oracle should sell to a "suitable third party?" That's just talk. The potentially significantly more difficult thing might be to actually find a buyer that meets the definition of "suitable" to all involved. I would love to hear those who state that Oracle should sell MySQL do more than state things as though if are as easily implemented as they are stated. I'd like to see who is willing to bid for MySQL and how much they're willing to bid. Of course, even those organizations interested in bidding on MySQL are not likely going to share their offers publicly. So, we're left wondering if there are any buyers out there willing to pay anything close to what Oracle feels the value of MySQL is.

MySQL may be one of the best examples one can think of where its value to the overall community is tremendous (perhaps many times more than $1 billion in this case), but it is much more difficult for any single organization to see enough individual value to justify purchasing it (in this case for anywhere close to $1 billion). There is no question that MySQL brings significant value to its users, but does it carry enough value to whoever owns it to justify its purchase? Or, is this another example of the problems of the commons? For my part, I can see how MySQL might be of more value to Oracle than it is to any other single party. This makes a sale difficult because Oracle wants more than any individual organization is willing to pay. MySQL is almost certainly more valuable to the collective community, but the collective community is not structured to make the purchase.

If someone is to purchase MySQL without a deep discount from what Oracle likely thinks it is worth, that "someone" will need to have a plan how they will make money from their ownership of MySQL. The more they pay for MySQL, the more revenue they need to be able to directly trace back to ownership of MySQL. Which organizations are in a position to profit from owning MySQL? How can these organizations most readily make money off ownership of MySQL? I don't know the answers to all of these questions, but I'd love to hear others' ideas.