|Robin Schumacher, MySQL|
No matter the platform, the No. 1 thing that I and many other database administrators struggle with is proving that performance issues and slowdowns are most times not the fault of the database.
Sometimes there are database problems that cause system performance degradations, but many times the issue lies outside the database -- at the network, application server, Web server or even client level. Exonerating the database isn't easy and takes skill on part of the DBA, as well as a team of system administrators who work well together. This is why active/passive monitoring software that can send and track synthetic transactions through the system stack and uncover where the actual time is spent is so valuable. What advantages and disadvantages does Linux bring as a database platform?
My favorite quote regarding Linux as a database platform came from Intel's Craig Barrett [chairman of the board] during a keynote at an Oracle OpenWorld a couple of years ago. He said that if you want higher performance and better reliability in your database environment, you've got to prepare yourself to pay a lot less.
I've witnessed this firsthand in the field and watched commodity hardware that costs one-fourth of other platforms outperform large Unix systems in eyebrow-raising ways. Other than the obvious pure cost savings, moving to Linux allows most system administrators and DBAs to carry over their Unix skills and become immediately productive on a new platform. In what situations would Linux not be a good database platform?
I can't think of many scenarios where, from a technical standpoint, Linux wouldn't be a good choice. Instead, you're dealing with soft and political issues that play a huge part in what goes on in many IT shops. As a DBA, did the proprietary nature of IBM DB2, Oracle, Microsoft SQL Server, Sybase and NCR Teradata cause problems for you?
There were a number of times that I was frustrated by the limitations of a database engine and wished I could change things, but these were before open source databases became prominent. In a database administrator's day-to-day life, how does working with a proprietary product differ from working with an open source database? Does it only make a difference if you need to customize?
Besides being able to extend the core functionality, the next best thing about open source is that it allows better understanding of what goes on under the covers. For example, I was speaking to someone in the field who told me they didn't understand why MySQL's query cache -- a part of the database engine that allows reuse of issued SQL queries -- was working in particular way. So he opened the source code, followed the logic, and then realized why things were working as they were. Obviously, this isn't something you can do with engines like Oracle and SQL Server. Based on your experience, could you offer some best practices advice to database administrators?
I'll touch on two areas: protecting data assets and performance troubleshooting.
First, the No. 1 job of a DBA is to protect the strategic data assets of their company. This means a DBA needs to develop bulletproof backup and recovery strategies that work every time. I see so often where a DBA thought a backup plan was running, but instead it was failing every night without the DBA's knowledge.
I also see DBAs not validating backups and then, when a restore needs to happen, the backup files are discovered to be corrupt. To prevent such things, a DBA needs to create backup plans that are validated each time they are run, and when a backup job fails, the DBA needs to be notified. A DBA should, when possible, also go the extra mile and practice recoveries on another machine so they can be confident that they're protected should a true disaster occur.
Secondly, a DBA needs to create a performance-troubleshooting road map that they follow when performance issues arise. A lot of DBAs work in a reactionary and hunt-and-peck fashion when it comes to diagnosing performance problems, which leads to frustrated users and system downtime.
A DBA needs to know how to separate the true performance issues from other non-relevant system noise and work from there. You'd be surprised at how many DBAs fall short in this area.