Welcome to the 88th edition of Log Buffer, the weekly review of database blogs.
No one has ever come out and formally asked me for a document that states “Best Practices to Scale Application X”. It is an unusual demand, since it’s something many of us at Pythian have implemented, but it’s been more of an ad hoc, iterative process — and rightly so, since architectures must be so organic, and so tailored to the application. What’s more, no one has ever brought us on board so early in the game that we have a hand in actually — gasp! — doing the design and data-model from the get-go. Woo hoo!
I’m amazed what people are able to do with Oracle technologies. One of the things I’ve liked the most is to spend some time (not enough!) with Kuassi Mensah. The guy is awesome! As a Product Manager at Oracle, he knows probably everything about JServer (the JVM in Oracle 11g), and he is one of the best guys on the subject of some of the key connection layer to access an Oracle database, including JDBC, OCI, and Web Services.
If you’re interested by any of those subjects, you should subscribe to his 360Â° blog and read his book.
I got to troubleshoot an amazing situation a few weeks ago. I think it is essentially inconceivable that allowing a single query to run on your system can flip another query’s plans and cause major performance issues (and in this case even downtime!). Sometimes it’s coincidence, sometimes it’s load, and sometimes it’s a single ad hoc query with a new predicate that starts the slowly-ticking time bomb. Here is how it happens and how to fix it.
Kenny Tilton posted about database troubleshooting, and he anecdotally illustrates and elaborates on a law of troubleshooting that I strongly agree with: Always solve the first problem. The corollary to his law is that “there only is the first problem.” I’m not sure I entirely agree with that one, but I will admit that that corollary is true at least 90% of the time, which is often enough to make it an incredibly useful insight.
I have been automating to make the life of my team members easier. As part of the DBA service, we offer monitoring in the form of alerting, and also in the form of daily checks to ensure everything is running smoothly. Daily checks consist of things that do not need to be checked every minute, but should be checked frequently. This is very valuable to ensure that no changes get lost. A DBA might be adjusting the configuration, but forget to put the final changes in the config file. In that case, the next day our daily checks will throw a warning, and that DBA will say “oh yeah, I forgot to put that into the config file!”
Open Source means that the source code is open. There are many inferences that can be made from this, and many stereotypes that can be applied, but in the end, all it means is that you can read the source code as well as use the binaries. One of my team’s current tasks is to restore a backup (using InnoDB Hot Backup, and compressed) from a client’s production machine to a development instance…weekly — thus we want to automate it. We got everything going well, except uncompressing the production backup and applying any logs (with ibbackup).
I was recently asked a question by someone who had attended my Shmoocon talk entitled “Why are Databases So Hard to Secure?”. (PDF slides are available). I was going to put this into a more formal structure, but the conversational nature works really well. I would love to see comments reflecting others’ thoughts.
On Monday, March 10th, Sun makes a stop in Boston on its world tour of “Mashup Meetups”. If you can’t make it in person, join us on the live ustream videocast. We will have Sun and MySQL employees present, and there will be a short (30 min max) presentation on “What is Cluster Good For?”. We will try to broadcast live on ustream.tv if possible.
Welcome the the 87th of Log Buffer, the weekly review of database blogs.