Re: survey - DBA structure in your company ?

  • From: Chen Shapira <cshapi@xxxxxxxxx>
  • To: Jared Still <jkstill@xxxxxxxxx>
  • Date: Tue, 7 Apr 2009 10:00:52 -0700

> I will play devil's advocate and say that this doesn't necessarily have
> anything to do with the organizational architecture.
> There may be very valid reasons for these

I agree that there could be valid reasons for this.
Ideally these reasons should be documented somewhere, and maybe
reviewed once in a while.
It will also be useful if the geographically and organizationally
separate DBAs will talk to each other once in a while, because if one
DBA found added value in a specific technique or feature, maybe others
will want to know about it.
(I hope I don't sound bitter here, I love my work environment. I just
sometimes wish I knew what to expect when I have to maintain a server
that is not officially "mine". Similar directory names would be nice
as a start).

That said, I do see value in consolidation for consolidation sake,
unless the requirements are really different.
It seems to require somewhat less time to maintain one reasonably
generic script than the aggregated maintenance of 10 scripts each
slightly different.

The major example I can give to this is that we are moving from NFS to
SAN this year. If we finish consolidating our backup scripts on time,
it'll be only one backup procedure we have to figure out how to
migrate, and only one place we will have to later fix all the bugs
will surely run into on our first attempt to work with that SAN.

But, as Tom Kyte said - Never say always and never say never.


Other related posts: