A recent photo that Julian
took. More whacky then the bunny photo?
I rather like it :)

I just signed out of the MySQL internal IRC server for the last time. Changing jobs is really bittersweet, I have truly loved working for MySQL and consider many of my coworkwers to be great friends. I hope to keep in touch but I know I will miss the daily interactions with them.

I know that tomorrow I’ll be excited to start work for OmniTI, but for today I feel the loss of the best job I’ve had to date with the best bunch of people I have ever worked with.

There's been some interesting reports lately on how open source software is eating into the traditional license and maintenance fees of the closed source legacy vendors.  Not only is open source a viable alternative to many closed source offerings, but just the fact that you're looking at open source is enough of a threat to some vendors that they will sometimes discount up to 80%.  Just put up a Linux poster and wear a MySQL t-shirt and you'll get your costs down.  Or better yet, start moving to open source where it makes sense, especially new web-based applications. 

• InfoWorld: Bargaining with Microsoft
• Tech Target: CIO's Guide to …

One of the most important requirements for any startup is hiring exceptional people. Hire weak people, and the company rises to the level of their incompetence. Hire exceptional people, and the company is elevated to the level of their expertise.

So how do you hire well in open source, given that - outside the realm of developers - very few business people actually have open source experience?

This is a question that I've had to answer repeatedly of late, as I've been hiring Alfresco's North and South American sales and business development organization. I have been very fortunate thus far, hiring three of the best people I've ever worked with: Luis Sala (Solutions Engineering), Jason Hardin (Inside Sales), and Martin Musierowicz aka "Mark" (Alliances).

What do most of Alfresco's employees have in common? Not a minute of open source experience. (Martin (JBoss) and Jason (Novell) are exceptions to this rule, as both came …

Sometimes a message from one of your database maintenance tasks makes you shudder, probably because it is an awful error message. Sometimes such a message can make you shudder even more, even if there is no error in your systems.

In a meteorological company, we use our MySQL database to keep track of a wealth of weather data from all around the world. The message from the maintenance task was short and simple: OLBA removed from list of active stations.

OLBA is the ICAO code for Beirut's Rafic Hariri International Airport. Their weather station continued to report even after the first bombing attacks, which forced the airport closed. The attacks continued, and the last report came in at 3 o'clock UTC this morning: a temperature of 25 °C, an air pressure of 1009 hPa, some scattered clouds and - no significant changes. The station has been silent since.

Welcome to the inaugural Log Buffer, a Carnival of the Vanities for the DBA community. Since this is the first, the duty of hosting it falls to us, but we hope other bloggers in the community will take on future editions. Here are our favourite database-related blog articles. Ten years ago on July 8th, the [...]

One of our managers at MySQL recommended the book "It's Not What You Say... It's What You Do" to me as something that he's used in managing teams.  While there's nothing here specifically about open source, the book provides a good "back to basics" approach to management.  Forget the big strategic initiatives in a company, the radical pronouncements of being customer-centric or sigma-six-oriented or whatever the latest buzzword is among management gurus.  The key questions are: Did you set goals?  Was there buy-in?  How much did you follow up? 

My own management style is not perfect, but I try …

This past Monday the Boston MySQL meetup featured Jim Starkey, a database guru who's hard at work coding a new database storage engine (code named Falcon) for MySQL.

This is a great presentation, Jim throws in a lot of database history and insight into working with MySQL. I left the camera on for the first bit of the Q/A. Also very good stuff.

I put in some extra video production effort this month. The video includes superimposed slides for better readability. Sheeri bought a new mic last month which captures the audience feedback better than in the past, seems to work well.

You can get the Quicktime here or …

Some weeks back I posted that the development of SQLbusRT had started. After some days this task had been postponed to reconsider the architectural design and to do some more theoretical research.

The version I started was programmed in C, which seemed to be a logical choice since there's a good ORTE API in C.

Yesterday I restarted the coding, now with C++ as the language. It's still possible to use the C API for ORTE, but it also allows me to have an object oriented approach.

The following components will be present in the first release:

• A tiny API for writing simple clients and sensors
• An insertion interface, which writes the sensor data to the database
• A selection interface, which handles query requests from clients
• A small example client and sensor

As soon as a package becomes available, I will post a message here on how to …

Please note that I am in no way affiliated with MySQL (AB). I am just a user of their products. Everything you read here, especially my explanations and conclusions are to the best of my knowledge, but there is a chance that they are awfully wrong!

I recently had to investigate the cause for a very long running delete operation in one of our applications. Apparently the time was spent in a single MySQL statement. While looking into the matter I exchanged numerous mails with the MySQL customer support, until I finally came up with a (much) improved version of the query. Along the way I learned some valuable information about MySQL's (or better InnoDB's) transaction levels.

Problem

The general problem looks quite simple:

• Three tables, let's just call them A (500.000 rows), B (4.000 rows) and C (180.000 rows)

• B contains detail information for …