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?
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.
“Yet those questions are absurd.”
I’ve been saying the entire “certification” program is a joke and an insult to the intelligence of the common person for over 15 years.
Unfortunately, every up-and-coming would-be “expert” out there is convinced that the way to mark a presence is to deride and disparage those who have been around a little/lot longer and that “the Oracle cert is the only way”.
I’ve always asked one question since this whole rigmarole started:
Who certifies the certifier?
Until that is answered in a clear and satisfactory manner, the whole thing will remain what it has always been: a joke.
And no, this is no “disrespect” for those who have taken the exams: their choice. It’s total contempt for the qualification itself and those who promote it. No apologies.
Except it is not just the certifications. Our entire education system is full of those multiple choice exams, teaching students there is only one correct answer and that they are not allowed to ask questions or discuss ideas.
database server / ORACLE_SID
The database server is either the server where your database is running (hostname) or at most the database name (DB_NAME).
According to the doc, the SID is the unique Oracle system identifier.
It matchs the INSTANCE_NAME init.ora parameter.
Was this an real exam question?
It was actually from a job interview, not at Pythian. Yes, their choices made no sense and I didn’t want to argue with the interviewer too much.
But the problem is not the specific question and answers, I think its the entire idea of “only one correct answer to everything”. Every real problem has one *more* answer which no one discovered yet.
[…] In other news this week, Sheeri Cabral and Chen Shapira both took part in the Battle Against Any Guess. Sheeri advised her listeners to “NEVER take any advice that tells you what to do or how to do it without understanding WHY.” Chen railed against the ingrained belief that “every question has a single solution and one that is so obvious that once you see it, you recognize …” […]