Wednesday, October 05, 2005

What do I need to know Part II

How do you know what you need to know, if you don't know it yet?

It's quite a frightening question!

My first couple of months as a DBA were spent with me working alone.
A lot of the tasks I was performing were based around following written instructions left by the previous DBA.
I knew what I had to do, and which commands to run, I just didn't necessarily understand what I was doing or why.

I don't think anybody realised how dangerous a scenario this could be, until I managed to bring the production system crashing to a halt a couple of times!
It wasn't anything malicious, just pure lack of understanding.

I found that once I'd got my head round most of the basics, I had to learn everything else on a 'need to know' basis.
If I stumbled upon an issue or concept I didn't understand, then I had to research it and learn on the spot.

After about 3 months, the company brought a contractor in, mainly to work on an upgrade project that was clearly above my limits at the time. He also became a mentor to me and was able to provide a bit of structure to my learning.

That's when I was able to go on my first Oracle DBA course and get a proper understanding of the theory behind some of the tasks I had been doing.

Once I'd worked out that my starting point was to learn the basics of Oracle, I then asked myself "what next?".

It's probably easier, or at least it was for me, to work out what you don't need to know.

For example, we didn't use RMAN, so I didn't need to worry about that.
We didn't run 24x7, so we did a shut down and cold backups nightly, therefore I didn't need to look into hot backups.
Similarly, if your place doesn't use RAC or Dataguard, then don't worry about learning it.

That's not to say you'll never need to learn, you just don't need to yet.

Concentrate your learning on the systems you have in front of you, and you can build from there.

Stick to learning one new concept or skill at a time.
As you progress things will naturally fall together and may make more sense to you. I usually find that if I try and take in too much at one time, it all gets a bit jumbled up and I have to go and learn it all over again.

So how did anybody else approach learning?

How do you decide what and when to learn?


Blogger shrek said...

well, since i got to be a DBA by walking into work as a contractor one day and finding a bunch of books on my desk and when i asked what they all were i was told "you're the new DBA, and the database is down so fix it." the first things i learned were where everything was and how to read dump files.

Wednesday, October 05, 2005 5:37:00 pm  
Blogger Rachel said...

I learned by reading the manuals. Of course back then (version 5) there were all of two manuals total, so that's not as hard a task as it sounds.

I start from "what do I need to know to keep the systems working" and expand on from there. First thing is ALWAYS "how do I bring things back if the database falls down and goes boom". Once I know I can restore the world if I (or anyone else) make a mistake, I start with the daily stuff..... are queries running in reasonable response time, do we have enough space to expand....

Thursday, October 06, 2005 10:34:00 am  
Blogger mattypenny said...

Slightly ambivalent about the whole process, but I have learnt a lot from doing the Oracle certification exams. There are a few reasons why this has worked for me:

1) it forced me to cover something like the whole of the subject matter. Before then, if something never went obviously wrong I never got to see it (e.g. rollback)

2) similarly it forces you to cover all of the new features for each of the releases.

3) I tend to need something like an exam as a focus/incentive. The best Computing books in the world would otherwise just stay in my rucsac or on my desk unread I'm afraid

Thursday, October 06, 2005 11:31:00 am  
Blogger JamieF said...

I am at the stage where I have grasped basic concepts. Creating databases, RMAN, exports, basic recovery. So I can keep the database up.

I have no clue yet about tuning or getting the best out of the systems and frankly I need a strategy to know where to start on that front.

I don't have anyone to ask, no mentor, so I rely on forums like this to get answers on a need to know basis.

Thursday, October 06, 2005 7:23:00 pm  
Anonymous Ram said...

Tom Kyte says the following manuals are a must read: Concepts manual, PL SQL guide (and one more) for developers
Concepts, backup & recovery, DBA Admin guide for DBAs. I couldnt find that link this am, sleepy.

Sunday, October 09, 2005 12:38:00 pm  
Blogger Jeff Moss said...

I tend to learn from whatever is in front of me on any given day...and as Tom Kyte always maintains...I learn something every day. Today for instance I learned about the MV_CAPABILITIES_TABLE and REWRITE_TABLE and their use in determining what operations are/are not possible for any given Materialized View and whether query rewrite can/will take place for a given query string...I've not posted it to my site since the code I was using is internal stuff and I didn't have time to conjure up a test day...!

Nice site - see you at bloggers dinner at UKOUG if you're there!

Thursday, October 13, 2005 9:06:00 pm  
Blogger cstiu said...

Hi Lisa! I just found your site via Tom Kyte's, and I'm so relieved to learn I'm not the only one who entered the Oracle DBA realm alone 4 years ago. The previous senior DBA gave me a couple of notes and commands (back then I didn't even had any idea what a standby database, or RMAN, is! I was just taught pre-prepared shell script "commands" created by the previous DBA. Right after that he quit. Its been hell and back for me, including a couple of instances when the production DB was just locked and frozen. Motivation for the best way to learn? Unfortunately, from disaster circumstances. Once you're faced with disaster situations several times over, you get tired of "unexpected circumstances" and stop treating the DB like a black box.

First thing I did when placed in a neophyte position and left with a working Oracle db? Build the DB server from ground up without any GUI tools. It'll helps the person to familiarize with the barebone basics (create db, tablespace, rollback segment scripts).

Second thing? Backup and recovery options. This helps when hell freezes over. Once you know how to recover, usually you can rest easy since you're (sort of) still in control when the db crashes or hangs up. You can recover the data which is most likely the lifeblood of the company. At least it won't get you fired ("errr.. Sorry, I seemed to have lost your precious data" company: "We're also sorry, cause we're going to fire you").

Third thing to learn? Find out why the d*mnned DB is so slow! Starting out with the statspack/utl scripts helps a lot. After that, its research, research and more research! (Jonathan Lewis' Practical Oracle8i really helped a lot on this one) This is where things get pretty exciting, to say the least.

I'm still learning a lot up until now, but things are picking up. Sorry if this comment is kinda long, but I wanted to share my newbie experience. :) Glad to see a blog that caters to newbies. Most of the others I've seen are pretty specific and in depth. They're not bad, but to a newbie, its frustrating to read and boggles the mind.

Monday, October 24, 2005 8:40:00 am  

Post a Comment

<< Home