The Database Administrator’s Primary Responsibility

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 aquired. It turns out that he wants you to look after and administer this newly aquired 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 you guys and girls 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 infinte. 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 unfortunatly does happen!

Do NOT let this happen to you.

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:

 

• 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.
• 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 nuissance.

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 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 using the comments box below.