Introduction

Like many DBAs out there, my path to database administration came through another gateway. First I was a web designer, then a systems engineer, and finally a systems administrator. I would imagine most of you found yourselves on similar paths that eventually led to being a brand spanking new DBA without much of a clue as to what the job REALLY entailed!

The scary part about being a new DBA is that you don't know the extent of what you don't know. There is a lot to learn in this job and a great amount of responsibility to the organization. In the information age, the data IS the organization; The DBA is therefore trusted to administer the company's greatest technology assets.

For everyone who was once new to database administration, knowledge of the RDBMS was clearly the first obstacle to bridge. Mastering the new concepts like transaction logs, isolation levels and checkpoints are barriers that also must be crossed. However, the truly important skills of the profession transcend the specific platforms or technologies; they are the biggest difference between Junior DBAs and Senior DBAs.

Where, then should a new DBA learn the skills necessary to do the job?

This brings me to first of the long list of concepts that I wish somebody would have written down in a book, or sat down and had a good long talk with me about. It would have saved me some headaches, and would have made me a better DBA at a time when I didn't know what being a good DBA was about.

Tip Number One: CIA Is the Main Thing

As Database Administrators we are paid to maintain three things:

• Confidentiality of data
• Integrity of data
• Availability of data

The CIA triangle of Information Security fame...

The CEO doesn't really care HOW it happens, whether its transaction log backups, and XML indexes or whizbang fiber-optic laser beam assemblers. He wants his data when he wants it, where he wants it and has to be 100% reliable. THAT is our purpose. Adjust your focus if you don't see it that way; CIA is what you need to be concentrating on.

Confidentiality

We must ensure that nobody is looking at, writing to, or altering the structure, function, content, or form of the database that is not supposed to. This means two things to SQL Server DBAs. One is authentication-based security and using database users and roles to manage access to data and databases. The second is the more difficult one: Controlling the system outside the system.

This means knowing which developers are allowed to send you stored procedure changes to push to production. Knowing who is allowed to use a linked server to access another system outside your control. Knowing who is allowed to tell you which logins to add to your server and what level of access to grant them. These things aren't stored in any system unless its one that you or your company have created. Learn the importance of verifying every request and how to document who has the proper authorization and authentication.

Integrity

Integrity is the concept that the data is always an accurate source of truth. The first and most basic way to ensure this is to validate the data file integrity through regularly scheduled DBCC CHECKDB's. This causes machine-based corruption to be recognized and (hopefully) resolved as quickly as possible. Another way to ensure integrity is to be an advocate for good database design. Try to make developers use well-designed primary and foreign keys, make them normalize their tables, call them out if something looks bad because ultimately you may be called to help straiten it out. The third way to guarantee data integrity is during a disaster. When you restore at an object level, be sure to take all the precautions to make sure the restored data and the pre-restored data is there for the developers to reference when they are performing their data surgery. Another good approach is to not allow object-level restorations. This is a 100% guarantee that your recovery is not just valid, but has the original and intended referential integrity.

A final way to ensure integrity is to have appropriate access controls in place to make sure people aren't polluting the data or data structure (See confidentiality!).

Availability

Availability is probably the most visible portion of our job, but it's not really the most difficult part. Availability is the topic of lots of papers and technological discussions about clustering, backup strategies, performance tuning and the like. I will simplify the discussion by simply stating: have good backups.

This is the principle demand for availability that transcends all platforms. Run a backup before you make any structural changes, before any application upgrade, before changing or dropping a user account, before changing a schema, before changing anything. Allow me to paraphrase the old saying about voting: "Backup early, Backup often" and also verify those backups with a 'RESTORE VERIFYONLY' at a very minimum.

The main reason is that once you change something, if ANY little thing breaks you don't always need to recover the database from backup, but you can restore to a different database or server and reference the pre-change database so you can "get it back to normal". If you don't have a backup, you have to guess.

I'll say it again: disk is cheap; Backup early, Backup often... and verify those backups!

THIS MEANS YOU!

Tip Number Two: No Heroes

I have had the privilege of working with many great DBAs who have used their skills and talents to overcome great challenges, and these are not the heroes that I'm talking about. The DBA Hero that I will warn you about is a much more insidious sort. This is the DBA who has tremendous knowledge of the RDBMS; This DBA has developed and designed all the support systems, processes, and routines. This person has been in the department long enough to have built relationships with all the customers and management, and has had his or her fingers in most projects. Many of you may be reading this and asking yourself: What's wrong with that DBA? Or: Hey! I'm that DBA!! The problem is not with the DBA, per se. The problem is the dependency which has built up around this one individual.

What hero systems typically lack is what organizations truly need: Documentation, repeatable processes, managed solutions, and sharable and centralized institutional knowledge. Dependency on a hero can only cripple the efforts of the organization in its efforts to mature.

As a new DBA, taking steps toward the "no hero" philosophy are some of the most important ones that you can take for yourself and for your organization.

A great first step for a new DBA would be to volunteer to document the organization's existing processes. This kills two birds with one stone by giving you first-hand knowledge of the documentable processes and also helps the organization to exorcise its dependency on heroes.

Tip Number Three: Create Definable Expectations

Communication is a big part of the DBA's job. It's nice when that communication is simple and the rules of engagement are understood by all parties.

Imagine yourself seeing a colleague in the hallway and you say "Hello, Jim, how are you?".
While there are no pre-defined rules about how this conversation should go, it usually ends with "Hey, what's up?" or some other friendly greeting in return. If Jim wanted to abuse your time, he could use you as a psychologist and tell you about all of his problems and everything else. This is, of course an analogy of the benefits of Service Level Agreements.

Yep. I like SLA's.

I also like closed systems where each group is responsible for defining a few inputs and outputs of service. This creates simple, easy-to-understand rules about how you as a DBA need to respond, and when you need to respond.

An example of a closed system might be that all incoming requests come through the helpdesk, or through a ticketing system, or need approval from a division manager... whatever works as long as it can be defined.

Example outputs might be closing a ticket, responding via a phone call or email.

The Service Level Agreement would be the measurement that surround and define your system's inputs and outputs.

An example SLA would be that the customer can call you when query response time dips below X milliseconds on a pre-defined production critical activity.

By defining the expectation you can eliminate yourself from the "urgent" phone call during lunch that a user thinks the system is "slow". While I sympathize, sometimes slow is relative, and nobody should call you during your lunch break unless it's an emergency... better yet if it's a pre-defined emergency that you know exactly how engage the customer and better still, have a pre-defined process built around.

These are the first three tips I have for new DBA's and even for people who have been DBA's since SQL 6.5. While they are not extremely technical or profound, I know all of us can benefit from revisiting the fundamentals and maybe "dusting off our existing way of doing things and seeing if there is a way to improve, mature, and become more capable.

Tune in next time for three more tips:

Know your limits
Script your way to into the heart of SQL Server
The art of saying: NO!