We’ve been running into a problem with one client: SELECT COUNT(*) FROM tbl; takes 0.25 seconds on one db, and 0.06 seconds on another.
Consistently. That’s a fourfold difference. There aren’t any significant configuration differences (like query cache, etc.), the software versions are the same, and the table fits into memory. This has been looked at by at least 3 in-house MySQL experts, and the only thing we can determine is that it’s a hardware difference.
I have created a MySQL Professionals Group for networking with others in the space, in the tradition of the Oracle Professionals group and the SQL Server Professionals groups that I already participate in. This is a great way to network with other professionals in your field of work. I hope you join us.
Are you interested in attending the 2008 MySQL Conference & Expo? I’m happy to announce that LinuxQuestions.org is able to give away one pass to the event. Visit this link for additional information. Good luck.
As of this month, Adam Machanic has been hired to lead Pythian’s global SQL Server practice and will be working out of our office in Central Square in Boston, Massachussets. Adam is in my opinion as close as it comes to a resource in the Microsoft SQL Server space that has the personality, track record and respect that Tom Kyte has in the Oracle space.
Here is the video of “Database Basics”, which I presented at the February 2008 Boston MySQL User Group meeting. The presentation goes over the basics of relations, data, the Entity-Relationship Model, how to choose data types, and how to do basic CREATE statements.
If you have a 12-server MySQL Cluster with, 1 Management Node, 3 SQL Nodes, 2 Data Node Groups, and 4 Data Nodes per group. And each machine is configured to allocate 1G of memory for its function, how much data (data + indexes) can you store in total in your cluster?
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.