The Complexity Defense and Other DBA Crimes

No matter how far my career and role has shifted, I will always view myself as a database administrator.  I know this because when I fill out any form asking me what role I fulfill in IT, I still choose “DBA” from the list.  No matter what claims the media and leading sources state, DBAs are an important role, even as technology shifts and traditional database tasks move to the cloud.  Deeper relational database skills are still quite relevant when working in complex technical scenarios.

The Experts

Companies work to ensure they hire the right technical specialists.  They don’t understand database and other deep technology, so they hire someone who does.  The challenge arises when the technologist may fear responsibility for a problem or an incident, so decides to use the technical complexity to disqualify their technical area, such as a database, suspect.

The Problem

I’ve begun to experience this more often since joining Microsoft.  Its more often a scenario where I’m approached by exasperated peers who’ve been attempting to identify an issue in an environment that includes an Oracle database and as the Oracle DBA assumes the Microsoft folks won’t know Oracle, the DBA create a less than truthful explanation of why its not the Oracle database.  The answer they give is often incredibly complex, filled with proprietary jargon, so the Microsoft technologist(s) can do little more than thank the DBA for their time and move on to investigating other tiers in the environment.

The DBA may claim they’ve already cleared the database tier of any impact in the latency issue with their own research. They may refuse to investigate after stating a feature would make it impossible for the database to cause the issue or point fingers at  the application or network layer to distract everyone. Often latency is caused by a combination of issues, (application code vs. database design or database code vs. network bandwidth) but at the center of it all is the database and a mature RDBMS has tools to diagnose a great many issues, no matter the culprit.

Now we all know its no fun when the technology we’re responsible for is the source of contention, but it’s preferable to identify the issue and correct it than to insinuate its not the problem and later on down the road, after significant time wasted, discover that it actually was.  Even worse, what if the problem continues to grow and is never solved?

Not Worth It

The technologist that creates these situations rarely realizes they’ve become a liability to resolving the issue or that they’re the roadblock.  Believing they have saved their technology from being pinpointed, such as an Oracle database in an Azure environment, by making incorrect claims that prove the database’s innocence, really just delays the inevitable.  This is commonly where the Azure team locates someone like me at Microsoft who does know Oracle, (quite well) and has the skills to call the individual’s bluff.

So here’s the deal-  stop viewing the technology as a personal reflection on yourself and realize that it belongs to the company you work for.  Its not worth the loss in trust, time and respect.  I am undeniably persistent about performance data-  reports, traces, so on and so forth, until I can definitively state the database isn’t suspect.  Its only a matter of time before you’re going to have to explain yourself, play dumb or just look foolish.

Sincerely,

Your Friendly Azure Data Platform Architect

AKA Previous Oracle/SQL Server Optimization DBA