BAAG, Best Practices and Multiple Choice Exams

(This post originally appeared at the Pythian blog)

I’ve been following the discussion in various MySQL blogs regarding the sort_buffer_size parameters. As an Oracle DBA, I don’t have an opinion on the subject, but the discussion did remind me of many discussions I’ve been involved in. What’s the best size for SDU? What is the right value for OPEN_CURSORS? How big should the shared pool be?

All are good questions. Many DBAs ask them hoping for a clear cut answer – Do this, don’t do that! Some experts recognize the need for a clear cut answer, and if they are responsible experts, they will give the answer that does the least harm.

Often the harmless answer is “Don’t touch anything, because if you have to ask this question you don’t have the experience to make the correct decision”. As Sheeri noted, it is a rather patronizing answer and it is stands in the way of those who truly want to learn and become experts.

But I can appreciate that it comes from long and bitter experience. Many users read random bits of information off the web and then rush to modify the production database without fully digesting the details. They end up tuning their database in a way no database should ever be tuned. Not even MySQL.

I used to think that users search for those “best practices” out of laziness, or maybe a lack of time. I used to laugh at the belief that there are best practices and clear answers, because if there were – we wouldn’t have a parameter. But now I think the problem is in the way most institutions evaluate intelligence, which affects the way many people approach any problem.

Even though all of us DBAs come from a wide variety of cultures, I’m willing to bet that every one of us had to work his way through a multiple choice test. If you ever took an Oracle certification exam, you know what I mean:

How do you find the name of the database server?
A) ORACLE_SID
B) ORACLE_DBNAME
C) DB_ID
D) none of the above

You run into those in certification exams, job interviews and in slightly different variation when you try to get accepted to a university. You had to learn to succeed at those multiple choice tests at a very early age, or you would be labled “less intelligent”.

Yet those questions are absurd. In the question above, the answer could be A, but A would be wrong if my database is a RAC cluster. Besides a much better way would be to use /etc/oratab because there may be more than one DB on the machine.

But you can’t have a discussion with the exam author. You can’t ask for assumptions and clarifications  and you can’t even explain your assumptions in the test. What’s more, these tests also check for speed, so you don’t have much time to contemplate the options.

What these exams teach you is that every question has a single solution and one that is so obvious that once you see it, you recognize its rightness in less than 30 seconds. They also teach you that someone else knows the right answer (the person grading the test). So finding the right answer can be a matter of getting the “expert” to give you the one and obvious correct answer.

If our society teaches this point of view from a very young age, why are we surprised that DBAs keep looking for the one obvious answer?

I fully support the BAAG cause, and I believe that DBAs should be given a full explanation of the problem involved, the different choices that exist, their meaning, the trade-offs involved and in general give them the tools to make the right decision themselves time after time. But we should realize that undoing years of faulty teaching can take a while.

There is an even worse side effect to those multiple-choice-should-be-obvious tests. You may learn to never ask for clarifications. That asking for clarifications is “bad” or “wrong” in some way. In any real problem, asking for clarifications such as “why are you asking this?”, “what is the real issue you are trying to solve?” and  “How will you use this script?” is the most important part of finding a solution. It is not cheating – it is doing a professional job.

It is a scary thought that the very way we train and evaluate the future DBAs is something that will prevent them from doing a good job of being DBAs.

Meeting Mr. Pythian

Last night I had dinner at San Francisco with Paul Vallee, CEO of Pythian.

Just in case you never heard about Pythian: They are a company specializing in remote DBA services. There are other companies that do remote DBA, but Pythian is special, because other companies don’t contribute to the community nearly as much as Pythian does.
They have a Pythian blog, with useful technical articles. Incidentally that was the second blog I started reading (The first was Tom Kyte’s). Their second contribution to the community is even more unique –  Log Buffer – the weekly compilation of everything that is hot in the DBA blogsphere.

With so much community interaction going on, it was not surprising to find out that Paul Vallee is on top of every industry trend and has some unique ideas on where the industry is heading. Talking to him for few hours gave me more stuff to consider than I usually encounter in a week or maybe two.

Paul is a huge believer in the future of MySQL. I know a lot of Oracle DBAs think that MySQL is barely a database, but according to Paul there is a huge demand for DBAs that can manage MySQL, because many organizations find out that in some cases Oracle is too much of a database. I have some experience with MySQL and I can’t say I like it much. On the other hand, I like the MySQL community a lot – it is small, friendly and very helpful to newbies. I’m not sure this nice community realize how much more mature Oracle is. Not just in terms of features, also in things like scientific thinking and optimization methodologies.  MySQL community needs people like Tom Kyte, Cary Millisap and Jonathan Lewis, to give structure to the community knowledge sharing and discussions and add deeper and more methodical content.

As I wrote in the beginning, Paul is working hard to anticipate the trends of the database industry, and he thinks that DBAs that define themselves by vendor (Oracle DBAs vs. SQL Server DBAs) are a thing of the past. The same way that developers tend to work in multiple languages through their careers, DBA careers are heading the same way. I’m not sure I agree with this view, I have a feeling that there is a fundamental reason that makes it sensible for DBAs to stick mostly with one vendor, but it is certainly something interesting to consider.

It was not surprising to hear that Paul believes in hiring the best DBAs he can find, the surprising thing was that he seems to think that a DBA team is about as strong as the best person in the team. A team with one very experienced and competent DBA will be significantly better than the same team without him. It makes sense to me, but it is well known among developers that a team is as good as its *worst* developer, so you really want your team to be as strong as you can get while pretty much everyone is on the same level. Another thing to think about.

As you can tell, it was a pretty interesting dinner 🙂 I’m still a bit stoked that I got to meet a real live CEO, and one that founded a company that I really admire. This is just too cool.

**
I didn’t post suggested links in a while.  Lutz Hartmann wrote about an interesting  initiative from Oracle and Netapp. I was excited about it for a full hour, before our storage manager told me that since we are moving away from Netapp in the near future (It is not Netapp’s fault! We love Netapp! It is a political decision), we won’t be testing the new initiative.