Recently, I had an opportunity to tune latch contention for cache buffers chain (CBC) latches. The problem was high CPU-usage combined with poor application performance. A quick review of the statspack report for 15 minutes showed a latch-free wait as the top event, consuming approximately 3600 seconds in an 8-CPU server. CPU usage was quite high, which is a typical symptom of latch contention, due to the spinning involved. v$session_wait showed that hundreds of sessions were waiting for latch free event.

SQL> @waits10g

   SID PID     EVENT         P1_P2_P3_TEXT
------ ------- ------------  --------------------------------------
   294  17189  latch free    address 15873156640-number 127-tries 0
   628  17187  latch free    address 15873156640-number 127-tries 0
....
   343  17191  latch free    address 15873156640-number 127-tries 0
   599  17199  latch: cache  address 17748373096-number 122-tries 0
               buffers chains
   337  17214  latch: cache  address 17748373096-number 122-tries 0
               buffers chains
.....
   695  17228  latch: cache  address 17748373096-number 122-tries 0
               buffers chains
....
   276  15153  latch: cache  address 19878655176-number 122-tries 1
               buffers chains

I will use a two-pronged approach to find the root cause scientifically. First, I’ll find the SQL suffering from latch contention and objects associated with the access plan for that SQL. Next,I will find the buffers involved in latch contention, and map that back to objects. Finally, I will match these two techniques to pinpoint the root cause.

Before I go any further, let’s do a quick summary of the internals of latch operations.

Read the rest of this entry . . .

It felt like the right time for us to look back at some useful commands for table maintenance that some of us may not have mastered as much as we might like to think.

In my post about gathering index statistics, I referred to OPTIMIZE TABLE, ANALYZE TABLE, and REPAIR TABLE — but I never explained in depth what the different commands do, and what the differences between them are. That is what I thought I would do with this post, focusing on InnoDB and MyISAM, and the differences in how they treat those commands. I will also look at different cases and see which one is right for in each case.

Read the rest of this entry . . .

Welcome to the 107th edition of the Log Buffer. My name is Keith Murphy and I am a MySQL database administrator for the Pythian Group. In addition, I am the editor of MySQL Magazine. This is my second go for the Log Buffer, so I must be doing something right!

This week for the open source world brings OSCON in Portland Oregon. There are plenty of MySQL people present and there have been more posting this week from these realms than normal. Also, Lewis Cunningham, among others, posted news that EnterpriseDB released the results of their open source survey at OSCON. The 451 CAOS Theory published their thoughts on the survey.

Of interest to all DBAs is John Duncan’s post about what is called the “five minute rule”. This was introduced in 1987 by Jim Grey. And finally, before we dive into the specific server news, here is a post on Facebook’s project to build a distributed database similar to Google’s BigTable.

MySQL News:

Friday saw the release of the summer issue of MySQL Magazine. The highlights of the issue include the first annual MySQL Usage Survey. The magazine is available here. Peter, over at Percona, shows some initial benchmarks for the latest version (0.9.8) of Sphinx. If you aren’t familier with Sphinx, it is a full text search engine that easily integrates with MySQL.

Probably the biggest news this week was the announcement by Brian Aker of “Drizzle”. It is what amounts to a slimmed down version of MySQL server. These comments are from his initial post “Stored Procedures, Views, Triggers, Query Cache, and Prepared Statements are gone for now.” Interesting. My co-worker, Sheeri K. Cabral, posted a video of Brian Aker talking about the Drizzle project at this week’s OSCON. Monty Widenius writes a good summary how Drizzle can/might integrate with the MySQL “ecosphere” at large. It was very good to hear Monty say that Sun management is encouraging this project. There has been some other interesting posts about this as well including Arjen’s thoughts, and Paul McCullagh’s. Brian Moon gives a very thoughtful view on how Drizzle could potentially fit in at dealnews. While I could probably fill up the entire Log Buffer with links to post about Drizzle, I better leave it at that.

Read the rest of this entry . . .

Exceptional Software Explained: Embrace Error, by Robert “r0ml” Lefkowitz of Asurion. One of the contenders for “best open source comedian”, r0ml delivers a humorous look at the past and future of software development models. This keynote was delivered at OSCon 2008 on Tuesday evening.

Play this 20 minute video directly in your browser at http://technocation.org/node/577/play or download the 286 Mb file directly at http://technocation.org/node/577/download.

Brian Aker gives the “zinger” lightning talk about the newly announced “Drizzle”. This short (under 8 minutes) video captures Aker’s highlights of why he started the Drizzle project and how Drizzle is different from MySQL — both in what has been removed from MySQL and what features Drizzle can accomodate.

Play the video directly in your browser at http://technocation.org/node/576/play or download the 116 Mb file at http://technocation.org/node/576/download.

Let me first say that the PBXT storage engine has some great people behind it. At the users conference last April, I had a chance to meet Paul McCullagh, who created PBXT, and some of the people who work on it. They are dedicated individuals who are creating something unique.

Like the InnoDB storage engine, which is backed by the Innobase company, PBXT has a company that backs it, Primebase Technologies. This means that if needed, support can be got from the company that created the product. For enterprise companies this might be important.

The basics characteristics of PBXT:

• MVCC: Multi-version concurrency control, enables reading without locking.
• Transactional: Support for BEGIN, COMMIT and ROLLBACK and recovery on startup.
• ACID compliant: Atomic, Consistent, Isolated, Durable (once committed, changes cannot be lost).
• Row-level locking: updates use row-level locking, allowing for maximum concurrency.
• Deadlock detection: immediate notification if client processes are deadlocked.
• Referential Integrity: foreign-key support.
• Write-once: PBXT avoids double-writes by using a log-based architecture.

Much of this is the same as for the other transactional storage engines, so I won’t spend time on them. What sets PBXT apart from other storage engines is the write-once characteristic. It is worth understanding.

Read the rest of this entry . . .

1, 2, 3, 4, 5, 6, 9, or 10. It ain’t no Feist song, but she got it right. Notice that she mentions no 7 or 8 in it. Well, that is also true for version support in release 1.21 of DBD::Oracle.

With some of the new functionality that was introduced in DBD::Oracle 1.21, you can no longer use the Oracle 7 and most early 8 clients to build DBD::Oracle.

I hope this little table will help you choose which version of DBD::Oracle is right for you.

As there are dozens and dozens of different versions of Oracle’s clients, I did not bother to list any of them, just the major release versions of Oracle that are out there.

Note that one can still connect to any Oracle version with the older DBD::Oracle versions. The only problem you will have is that some of the newer OCI and Oracle features available in later DBD::Oracle releases will not be available to you.

So to make a short story a little longer:

Read the rest of this entry . . .

Well, nobody from Sun showed up in person, but we got a great rendition of “Where were you when you heard THE NEWS that Sun bought MySQL?” from Mark Rubin, the MySQL Sales Engineer for the New England area, and from Giuseppe Maxia, who revealed something very interesting and riveting.

From there, Giuseppe gave a short talk on what it’s like to work at MySQL, and then we moved on to the topic of the user group meeting, “What is MySQL Cluster Good For?”

The slides for the talk are downloadable in PDF Format 61kB and Flash (SWF) format, 31kB

The video can be played at http://technocation.org/node/572/play and downloaded (404 Mb) at http://technocation.org/node/572/download.

The last keynote of Tuesday evening at OSCon 2008 was entitled “Temporarily Quaquaversal Virtual Nanomachine Programming in Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces…..Made Easy!”

Damian Conway is a speaker that should not be missed. He spends his time hacking perl to do fascinating and obscure feats of technology such as time travel. This video is just over an hour of rolling laughter that will entertain you into realizing what a genius Damian Conway is.

Now, most of my exposure is within the MySQL Community, so if folks could pass the links to the video along to other communities, that would be great.

(This video is at 1.0 Mb/sec. Watch the video online at http://technocation.org/node/571/play or download it at http://technocation.org/node/571/download. Please do not download the file if you are on the conference network, these links are not time sensitive.)

Liveblogging from OSCon 2008: Going Open Source, The 20 Most Important Things to Do - by Martin Aschoff of AGNITAS AS.

Firstly I have to extend a heartfelt “thank you” to Sun Microsystems and Monty Widenius, as I would not have been able to attend OSCon without their assistance.

AGNITAS AS makes e-marketing software, 25 employees, no venture capital, from Munich, Germany. The municipality of Munich runs entirely on Linux desktops and on infrastructures with open source software.

This session is about the nuts and bolts of an open source company. Aschoff kept a journal of the key learnings of the company when it went open source, and has become a board member of the Open Source Business Association in Europe.

Before deciding on going open source:
Read the rest of this entry . . .