Thanks for the question, Sam.

Asked: January 02, 2002 - 11:45 pm UTC

Last updated: October 03, 2002 - 6:41 pm UTC

Version: 8.1.7

Viewed 1000+ times

You Asked

Tom

Can you give your piece of mind on the following..

We were having a discussion out here , and I opined that a startup dba or a dba with round about 2 to 3 years experience should be good enough for the following.

1.Sound knowledge of the architechture.
2.Good experience of Backup , and at least theoritically sound in Recovery.
3.Proficient in Tablespace management.
4.Proficient in Schema creation and privilege management.
5.Sound in Security concepts.
6.Sound knowledge of Sql loader
7.Reasonably good in Shell scripting( assuming that the dba is working on unix).
8.Good knowledge of data dictionary views.
9.Sound knowledge of daily activities like alert log monitoring etc

What else would you like to add to the above.

Further, if some one were to ask you to divide the most important tasks of a dba into daily , weekly, and monthly , how would that appear.

Thank you

and Tom said...

How about the most important one:

0) has excellent interpersonal skills, truly likes working in a team environment. Has a good "can do" attitude. Understands that the developers, as well as end users, are his/her customer and that when the customer isn't happy -- they are not doing their job. Having the database up and running is one of their tasks, their main job is customer satisfaction. Understands the difference between "keeping the database protected" and "getting the job done" (meaning that draconian rules such as "no views in my database, no procedures in my database" are stupid). Has the ability to use imagination and technical know-how to solve problems, not just "book stuff" they know, more like common sense.

I can teach anyone the database, I cannot make them a good co-worker.

Your list sounds good for your environment (i suppose). I would encourage you to (when interviewing) ask each candidate to simply go to the whiteboard and "draw" a picture of Oracle -- its main processes/threads, whats in the SGA, how the files are layed out -- what each file does, the importance of each and so on. I'll betcha 80% cannot do it (even more I think) -- even though its clearly depicted early on in the concepts guide. Ask them if they've ever read that document and if so, give a brief outline of the topics covered therein (most will say they read it, most will say "i dont know" to whats in it)I say it looks good for your environment because there is no mention of "GUI" skills -- no OEM, no system mgmt tools. Many shops rely on these tools (i myself wouldn't make the cut there ;)

I don't really have any weekly/daily/monthly jobs for DBA's. In a smoothly running shop -- it should be "business as usual" day in, day out. Everything should be automated -- so the nightly backups are done every day (outlining how my databases run) in HOT mode, there are at least 3-5 backups stored offline, the every other nightly export happened, the database/OS pages us when something bad happens, etc. In this fashion, the DBA can spend their day helping people, fixing things that go awry, etc.

Rating

(11 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Excellent

Shivaswamy, January 03, 2002 - 10:50 am UTC

A reader, January 03, 2002 - 11:17 am UTC

"I say it looks
good for your environment because there is no mention of "GUI" skills -- no OEM, no system mgmt tools. Many shops rely on these tools (i myself wouldn't make
the cut there ;)"

Tom, can you give us a list of popular GUI tools out there, for DB administration.

What do you mean by 'i myself wouldn't make
the cut there'

January 03, 2002 - 11:37 am UTC

I cannot really -- for the simple reason that "i myself wouldn't make the cut there" means I have no gui skills. I get totally lost in them trying to find the darn commands in a menu structure (which is really hard when you actually KNOW all of the commands and cannot find them).

I use the command line -- i use sqlplus -- telnet is my gui.

Top most things a startup dba should be proficient

shenif, January 03, 2002 - 11:28 am UTC

I think you are right on the ball. But what about knowledge of pl/sql? How much of it should be known?

January 03, 2002 - 11:39 am UTC

for a DBA, it depends. They need just enough to do simple loops and such -- scripting at the OS level seems more important. If they can write sh, ksh, csh -- they can write a little plsql when needed.

Making the cut

Ralph Wagner, January 03, 2002 - 11:39 am UTC

I think what he means is that he doesn't use the GUI based tools - so he wouldn't make the cut with a 'GUI' series of questions.

If you've ever had the opportunity to see Tom speak (with a keyboard nearby) you'd see that he's a SQL*Plus kind of guy - No Point-and-click stuff. This comes from spending your day in a telnet session rather than on a Windows client. :)

There are lots of 3rd party Tools out there for DB management -

These links (I think) are good starting points for DBAs or developers. I'm sure others have their favorites as well...

</code> http://www.orafaq.com/tools/index.htm

and

http://www.natcapoug.org/list_of_oracle_tools_1.html <code>
(about 3/4 down are DBA tools).

A good DBA is using one's own scripts for the job.

Sean Bu, January 03, 2002 - 12:37 pm UTC

Disagreement with Sean Bu

A reader, January 04, 2002 - 9:13 am UTC

Sorry Sean but I disagree on your statement - As Tom said its all about getting the job done and keeping users happy.

If this means using code provided by other people for whatever you are trying to achieve and you are not violating copyrights etc. then by all means save yourself and your users the time.

What is important is the knowledge to fully understand the code and realise when it might not work on your system and being able then to make enhancements to it should you need to.

But saying only self written code in my db is very ignorant,and it comes down to what Tom called "draconian rules" in his response.
There is always someone who can do it better than you.

If the resources are there to use then use it.

Colin Davies, February 27, 2002 - 2:36 pm UTC

>2.Good experience of Backup , and at least theoritically sound in Recovery<

Backups are useless unless the DBA knows how to recover the database and has practised it and documented it, including all the main scenarios (corrupt datafile, corrupt rollback segment, etc.). This should receive much greater emphasis, especially in a 24x7 environment.

shell scripting

Mike, October 02, 2002 - 8:38 pm UTC

Since all agree that the unix shell scripting is one of major skills a dba must have, I ask the following:

Until recently I had been working mostly on NT and limited on UNIX. Having not been exploring much on the Unix shell scripting. The current job requires considerably shell scripting skill, because the ETL is mainly based shell scripts (though I believe it is not good idea).

What is the learning curve for acquiring the scripting skill? I want to be reasonably good to understand and enable to make some modifications of the current scripts.
Is it the deep as the same as to learn such as pl/sql?

TIA

October 03, 2002 - 9:11 am UTC

I don't agree with the "since all agree".

Maybe in 1990 that would have been true, but in 2002 -- it is most certainly not.

Is it helpful? (Yes) Does it make them better? (sometimes, depends on the quality of their code like anything else). Is it necessary? (no, i don't think so. If you can manage Oracle on NT, you can manage Oracle on Unix IMO. You need to learn some unix'isms like you did with NT..)

I cannot imagine ETL based mainly on scripting. Sounds painfully slow unless there ETL is painfully trivial or their data volumes are tiny.

Cannot really say how long it takes to learn script -- it was sooo long ago that I was faced with learning. It is rather learning the breadth of tools you'll be using like grep sed awk nawk perl cut etc....

Thanks for the insight and info, Tom.

Robert, October 03, 2002 - 10:13 am UTC

Tracking down BV-Violaters

Robert C, October 03, 2002 - 2:24 pm UTC

Tom, in your opinion, should a DBA keep an active eye (or 2) out for programmers not using bind variables in their code ?
which may involve having to view their source code (pl/sql , java, vb...) if the BV information is not readily apparent. Should the DBA take it up then with the managers ?
Thanks

October 03, 2002 - 6:36 pm UTC

YES, definitely YES.

You don't need to read the code. You'll find it in TEST by querying the v$ tables easily. You'll find it in TEST when you hit lots of library latch contention. (what, you don't have test? back to square one then)

see
</code> http://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:1163635055580 <code>

and yes, you need to speak to THEM first (not their manager, give them a chance, teach them why this is bad). then talk to their mgr ;)

A dba has the responsibility to make sure the DB is being utilized properly.

ETL process and shellscripts

A reader, October 03, 2002 - 2:25 pm UTC

Hi Tom

you said shell scripts is not very good idea for ETL processes but then how would we code them?

Currently we use extensively combinations between

Shell scripts
PL/SQL, SQL scripts
PL/SQL Stored procedures
PRO*C
ETI*Extract (this generates shell scripts code)
SQL*PLUS
SQL*Loader
BMC Control-M

Mainly Shell scripts calls the tools and get the return codes

If these tools are not used I wonder in what language should we code ETL processes?

October 03, 2002 - 6:41 pm UTC

shell scripts call tools -- so the shell scripts do almost nothing. the shell scripts aren't doing ETL, they are just being used like JCL on a mainframe would be -- to execute programs.

Breadcrumb

Question and Answer