Andy Leonard pens the following blog entry:
There are quite a few organizations that feel they can get by without a
DBA on staff. They believe they are cutting cost, not realizing that
they are incurring it. Andy covers the situation from a development
perspective. I'll speak from an operational one.
I can think of an example from a couple of years back where a friend
who had a consulting company gave me a call. A private college near
where I lived had a data corruption issue that affected their student
records (oops). They didn't have a DBA and the system administrator
thought he had implemented the database backups properly. Now, it's not
hard to institute database backups. However, it does require a bit more
thinking that "schedule a backup tape to run once a day." He didn't do
that level of thinking and as a result, the organization lost data.
Luckily, they had all the records on paper and they were able to
re-key. So they were able to get everything re-entered, but at a
significant time loss.
There's an expected gap in knowledge operationally between a solid
system administrator and a DBA who knows his or her stuff
operationally. Case in point (and this isn't related to the case I
helped my friend
with): if the organization has a point-in-time recovery requirement (if
possible), how many server administrators know enough about SQL Server
to attack something like that? A lot of system administrators will see
the disk space warnings, realize the transaction logs have grown
enormously, and then ask how to prevent the transaction logs from
growing so big. They'll do a bit of research and find out simple
recovery will help with this and they'll institute it. But what have
they just done? Yup, they've just removed point-in-time recovery as an
option. And this is just one case where a DBA is needed.
Technorati Tags: DATABASE |