Scribd
Upload
37 views3 pages

The Disappearing DBA

The DBA's primary responsibility is to safeguard the organization's data. As the lifeblood of the business, data is incredibly valuable and a data loss event could seriously impact or even cause the closure of a company. There are many potential causes of data loss, from hardware failures to natural disasters to malicious acts. As DBA, it is their job to defend the data from these risks and take responsibility for its protection. The next article will discuss how using the FULL recovery model can help DBAs fulfill this important duty.

Uploaded by

Bryan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
37 views3 pages

The Disappearing DBA

The DBA's primary responsibility is to safeguard the organization's data. As the lifeblood of the business, data is incredibly valuable and a data loss event could seriously impact or even cause the closure of a company. There are many potential causes of data loss, from hardware failures to natural disasters to malicious acts. As DBA, it is their job to defend the data from these risks and take responsibility for its protection. The next article will discuss how using the FULL recovery model can help DBAs fulfill this important duty.

Uploaded by

Bryan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 3

The Disappearing DBA

By Tony Davis, 2009/04/06


Total article views: 365 | Views in the last 30 days: 167
Rate this |
Join the discussion | Briefcase |

Print

During a "difficult period", a developer tends to sink from view. When delivery dates have slipped, and
testers are hammering them with bugs they've found in their 'perfect' code, the developer will sit quietly in
the corner, unnoticed by most, doggedly bashing away at their keyboard.
However, when things are going well, when an awesome new feature has been completed or particularly
knotty programming problem solved, everyone knows about it. Suddenly they are the gunslinger, the
hotshot; rightly proud of their achievement they swagger around the office telling all to anyone who will
listen.
The DBA often looks on wistfully. For him, the "fame trajectory" seems to work in reverse. When a server is
down or performance is suffering, customers are quick to complain, and managers are eager to point the
finger of blame. During difficult periods, the DBA is the centre of attention. The harder the DBA works, and
the smoother everything is running, the more invisible the DBA becomes.
In short, it is the unfortunate lot of the DBA to work their way towards absence. In a recent blog, Andy
Leonard notes that DBAs think differently to developers, and it's true. The DBA role requires a completely
different mindset, and a very different perception of what "success" means.

Some DBAs, perhaps envious of the high profile developers , make a point of highlighting
their achievements, sending regular emails that report uptime on the company servers, improvements made
to database processes and so on. This isn't such a bad idea, but most seem content with a working life
spent keeping deliberately out of the limelight. Plaudits and esteem are all well and good, but they don't
trade for much at the bank. What DBAs lack in public profile they tend to make up in personal remuneration.
They accept the occasional public lambasting with good grace, perhaps consoling themselves using Phil
Factor's old trick of calculating, on the hourly rate, how much they are being paid to receive it.
One cannot change human nature, and so it may be better to aim for an image of quiet efficiency rather than
gun-slinging hero. Whereas the developer can bring a spring to his step from thought of the recognition of
the quality of his work and skills, the DBA can cheer himself from the thought that it has been a nice, quiet
month; and now it's payday.
Cheers,
Tony.

By Tony Davis, 2009/04/06


Total article views: 365 | Views in the last 30 days: 167

Part 1: The Database Administrator's Primary Responsibility


By John Sansom, 2009/09/14
Total article views: 4188 | Views in the last 30 days: 4188
Rate this |
Join the discussion | Briefcase |

Print

You're busy coding away at your workstation when all of a sudden your manager walks over to you all
excited and begins discussing with you, the details of this great new application your company has just
acquired. It turns out that he wants you to look after and administer this newly acquired application platform,
which by the way, has a SQL Server engine.
You're a natural when it comes to solving problems and you think you can handle it for sure, that is until
slowly but surely it dawns on you that you have never actually had to administer a SQL Server database
server before. In fact, you're not even sure where you should begin.

Well fear not my friend! Whether you are an accidental DBA, just getting started with learning SQL Server
technology or perhaps you just want to polish up on the basics. This is the first in a series of blog posts just
for those of you that want to get up to speed on the essentials of SQL Server, the core stuff that you just
absolutely must know.
So with no time to loose, let's get started.....

What is the primary and most important responsibility of a SQL


Server Database Administrator?
Before you even go anywhere near a keyboard or launch SQL Server Management Studio, the first lesson
that you absolutely must take on board is that the primary responsibility of a SQL Server database
administrator is "data".

What's so special about data?


Data is arguably the most valuable asset of a business. It is the lifeblood of the organisation, whithout which
it cannot function. As a SQL Server database administrator you have to safeguard your data.
The variety of information that data can describe is possibly limitless, with each variety just as important as
the next, to the business it belongs to. Some examples of information that data may be used to describe
include:

An Application Backend/Data store


Storing and collecting vast amounts of data from the Large Hardron Collider at CERN or Modelling
the human genome
Customer/Client Contact Details
Financial Information / Banking Systems / Credit Card Processing
Company Sales Figures
Order Inventory System
Website Content
Train Timetables / Aircraft Reservation
Library / DVD / Car Rental
The list is, as I'm sure you can imagine, potentially infinite. What should be immediately clear to you
however, is that if anything bad were to happen to your data, for example a data loss event were to occur, it
would almost certainly have a negative impact to the business. Possibly even serious enough to result in
closure. Seriously this can and unfortunately does happen!

Data Loss Event Types


To give you an idea of what you're going to be up against, consider that Wikpedia categorises data loss
events into 5 main categories:

o
o
o
o

o
o
o
o
o

Intentional Action
Intentional deletion of a file or program
Unintentional Action
Accidental deletion of a file or program
Misplacement of CDs or floppies
Administration errors
Inability to read unknown file format
Failure
Power failure, resulting in data in volatile memory not being saved to permanent memory.
Hardware failure, such as a head crash in a hard disk.
A software crash or freeze, resulting in data not being saved.
Software bugs or poor usability, such as not confirming a file delete command.
Data corruption, such as filesystem corruption or database corruption.


o
o

o
o

Disaster
Natural disaster, earthquake, flood, tornado, etc.
Fire
Crime
Theft, hacking, sabotage, etc.
A malicious act, such as a worm, virus, hacker or theft of physical media.

Understanding your responsibility


I want you to sit back and to take a moment to think about what it is that you are about to become
responsible for.
Make no mistake, as a SQL Server database administrator it is YOU who is responsible for safeguarding the
database data. Your actions could be what makes the difference between a data loss event being fatal to
your business or merely just a nuisance.

What can I do to look after my data?


Now that you know the Database Administrator's primary responsibility is the data in their custody, what with
all these potential risks vying to get at your precious data, what can you do to defend yourself?
Find out in Part 2 of the SQL Server Essentials Series, where we will look at the SQL Server database
administrator's most formidable defence method and discuss Why you should be using the FULL Recovery
Model for your databases.
Have you got a tale to tell about data loss? Please feel free to share your thoughts in the discussion thread
or write to me on my Blog.

By John Sansom, 2009/09/14


Total article views: 4188 | Views in the last 30 days: 4188

You might also like