When a DBA holds all the cards

As we move through the life cycle of content management projects, we deal with project managers, internal and external vendors, technical architects, storage managers, and database administrators (DBAs). Sometimes DBAs are reactionary, sometimes they are forward thinking and actually care about projecting growth of data.

You could spend weeks with the software QA department trying to tune the queries that are slow only to find out that the database is maxed out, or the software is tuned for MS SQL over Oracle, or vice versa.
During major upgrades or migrations, DBAs need to be on top of their game, they need to anticipate a jump in database size, RAM, and CPU utilization. When they get caught not doing their job is when performance slows and users start complaining. This puts you in the middle, having to explain to the users and project sponsors that, “yes, you allowed for this possibility”, but, “no, we are still looking why this happened.”

DBAs can either go into cover your ass mode, or fess up to their oversight and make plans to fix it. The tell tail sign that you are being stonewalled is when you ask a question and you never quite get a straight answer. Sometime you get an answer by way of push back, like, “what queries are you guys running anyways”, or you get long responses that tout their expertise and knowledge, but still don’t answer the questions of performance.
 

So how do we light a fire under the DBA to boast performance that is obviously being affected by over taxed RAM and CPU? We could escalate the issue to managers, which could work, if the management is accountable and works well with one another. We escalate the issue between the users and the DBA, which would put the two parties most affected by the performance in the same run to describe the pain of waiting for results.
 

The bottom line is that we need to include all players in a meeting during the planning phases to make sure everyone knows the ramifications and expectations of the project and to have face to face agreements which are a lot stronger than email acknowledgements.