🚀 go-pugleaf

http://www.sqlservercentral.com/articles/career+growth/64632/

By Craig Outcalt, 2008/11/18

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!
 
--
http://bbs.sjtu.edu.cn/file/comic/122390669464913.jpg

�� ��Դ:����ˮ˼Դ bbs.sjtu.edu.cn��[FROM: 207.46.55.31]