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.
