DBA Procedures
-
Hello all.
I have a question about what is expected of a run-of-the-mill dba (if there is such a thing).
For those of you that function entirely or primarily as DBAs, do you create detailed documentation regarding troubleshooting and past problems?
What about detailed documentation about preventative maintenance?
If so, how much time per day do you allocate to your duties plus documentation?
-
I keep a record, paper and electronic, of any issue and related references, that I come across as a DBA. This runs from server setup, how to move system databases, KB articles, msdn articles, posts/emails from sites such as this - but only if it touches what I do or a problem/issue I have had to deal with ( mostly - otherwise you have too much ). I have this since SQL6.0 so it's my bible of things that affect SQL Server.
I also inlcude references to o/s events and infrastructure things, e.g. switch settings, dns, wins .. etc. etc.
Generally I have a set of procedures . scripts and so on that I use to administer / make my life easier.
If you don't document you lose your points of reference and you may be required to provide documented proof of something you wish to do, having the original docs is much better than having a recollection of reading something, somewhere, some time ago
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/ -
I have never documented anything of my process. But now that I need to review some old process I developed a long time ago, I 've noticed I should spent some time documenting a bit.
Not much, but at least some pages.
-
Here's a few items that you'll probably see: User maintenance (be SURE your HR department includes you on employee terminations), new development, patch management, security and auditing, tuning, scheduled database management/maintenance (it seems I'm always tweaking my jobs to be a little better <g>
. Let's not forget meetings. Injecting a voice of reason when developers get some wild notion in their heads and you have to reel them back to earth with "no, we don't have the resources to download the internet to our database server."If nothing else, document your disaster recovery procedures. The best way to do this is to actually walk through a disaster recovery from start to finish in a test environment if possible. Document every step, every click and every check box. When you're under the gun and your boss's boss's boss is in hover mode while you're on the console, having a checklist will avoid any potentially unpleasant situations caused by forgetting a step (aka "career suicide").
Here's a little quote I've referenced before. I hope you enjoy it.
Cheers,
Ken
----------
A Day in the Life of a DBA
A day in the life of a DBA is usually quite hectic. The DBA maintains production and test environments, monitors active application development projects, attends strategy and design meetings, selects and evaluates new products, and connects legacy systems to the Web. And, of course: "Joe in Accounting, he just resubmitted that query from hell that’s bringing the system to a halt. Can you do something about that?" All of this can occur within a single workday.
To add to the chaos, DBAs are expected to know everything about everything. From technical and business jargon to the latest management and technology fads, the DBA is expected to be "in the know." And do not expect any private time: A DBA must be prepared for interruptions at any time to answer any type of question - and not just about databases, either.
When application problems occur, the database environment is frequently the first thing blamed. The database is "guilty until proven innocent." A DBA is rarely approached with a question like "I’ve got some really bad SQL here. Can you help me fix it?" Instead, the DBA is forced to investigate problems where the underlying assumption is that the DBMS or perhaps the DBA is a fault, when the most common cause of relational performance problems is inefficiently coded applications.
Oftentimes the DBA is forced to prove that the database is not the source of the problem. The DBA must know enough about all aspects of IT to track down errors and exonerate the DBMS and database structures he has designed. So he must be an expert in database technology, but also have semi-expert knowledge of the IT components with which the DBMS interacts: application programming languages, operating systems, network protocols and products, transaction processors, every type of computer hardware imaginable, and more. The need to understand such diverse elements makes the DBA a very valuable resource. It also makes the job interesting and challenging.
--Exerpt from "Oracle DBA on UNIX and Linux" by Michael Wessler, Chapter 1, titled "What is a DBA?"
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply