Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: DBA tasklist

Re: DBA tasklist

From: RSH <RSH_Oracle_at_worldnet.att.net>
Date: Thu, 07 Mar 2002 22:44:58 GMT
Message-ID: <K3Sh8.20500$106.1668266@bgtnsc05-news.ops.worldnet.att.net>


Well DBA "Duties and Responsibilities" are outlined in one of the Oracle manuals, DBA Reference Manual, at one time I think it was in the SQL manual; its around in the first 20 pages of one of the major references. And it's all goop. Recruiters and HR people and such smart enough to turn pages and read plop this into the requirement description, and you have tedious reading of reqs in text or listening to it by phone, until you know it is the formulaic text and you can shut them up.

If you are asking for REAL answers:

  1. Keep production systems running and accessible at any cost consistent with your morals, work ethic, and avoid torturing other people with off-hours unless you really need them. Bribery er incentives such as home-made baked goods such as cookies, or a surprise home-catered luncheon with lasagna, garlic bread, and salad will earn great numbers of points you can collect when the Pits of Hell open up and you need EVERYBODY to help.

1a: Preserve and protect all information and data passing through your fingers and ensure you have multiple mechanisms to reconstruct data you've been sent as feeds, to reconstruct the database by at least two different means; to reconstruct outputs that were to be feeds to other systems. PRESERVE ALL INFORMATION in as many different ways as manageable, because sooner or later someone is going to need something that has been years gone from the system, so create a structured, auditable framework to keep track of tapes sent off to offsite secure archives, what is on site, what you have in your right hand lower desk drawer, etc.

2. Have a laptop and remote access. First thing you do when you awaken, log in and check all systems, instances and a look at the alert logs and trace files. Check sar and vmstat for overal system performance, look for unusual CPU consumption, excessive paging or swapping.

Check used and available filespace on all servers.

Check who -u and see how many actual UNIX connections are on and which are active and who they are. A dot means they are current; if that is one of your tedious and troublesome developers, make sure he/she/it hasn't blown out /tmp or /usr/tmp by spooling a SQLPLUS query, say :

SELECT * from NAMES_OF_ALL_LIVING_BEINGS_ON_EARTH

which thus can can cause interdepartmental chaos when all of a sudden none of the UNIX side developers can invoke 'vi'.

Summarily terminate the session(s) of anyone doing such things, and call and remonstrate with them severely.

Look for any connections that have been on for more time than you generally are used to, and see what they are up to.

If it is an LRQ of any kind (remember this is the AY-YEM!) against production tables or objects, and it is not on the production schedule, terminate with extreme prejudice and track down the culprit and ask them what they meant to be doing.

Check free space on all development instances. Check all production instances for objects running out of extents, or for tablespaces that are too filled with data and need more space. Allocate another partition or two depending (as datafiles) to impoverished tablespaces. With non-raw I/O you can just fiddle with whatever the existing datafiles to give them more growth.

If you use autoextend, that is your own lookout. Unlimited extents can cause similar fun.

HS (hora somni) [when normal people take sleeping tablets]:

Do the same thing you did in the AM before you came to work.

Check status of feeders and other external interfaces.

Look at:
sar
vmstat
netstat
who -u
and /etc/whodo

for abnormal activity

check the $sick_of_OFA er the directories holding the alert logs, and the bdumps and udumps for unusual things

A peeve of mine in years past involved developers who logged into Oracle via sqlplus, shelled out (!) to UNIX, did other things, forgot they were already IN Oracle, invole SQLPLUS again, ad infinitum, and you'd see

wnamenotmentioned
sh
sqlplus
sqlplus
sqlplus
sqlplus
ksh
sqlplus

...

Remonstrate with those people, since at your bedtime, these people have long been asleep.

who -u would give you the smoking gun.

Above all, if vmstat / sar tell you there is less than 10% free CPU, start doing

pf -ef | grep ora

and top or whatever your O/S has to tell you the piggy processes.

3. Do please have a pager and cellphone. Depending on what tier of support you are in, constrain distribution of that information to department heads and such.

4. Never let anyone tell you a line like "That's the system administrator's job."

If Oracle isn't working right, it is your fault, and nobody cares.

Words of experience.

Welcome to buying Alleve by the case,

RSH.
"Dale DeRemer" <dderemer_at_agmc.org> wrote in message news:a680mq$7ah$1_at_malgudi.oar.net...
> I am a new DBA. I've been to some Oracle classes, and I have just the
> beginnings of a clue. Anyway, I'm wondering if anyone has, or could
suggest
> a list of tasks that a "generic" Oracle 8.1.7 DBA should perform. That is,
> daily, weekly, monthly, etc. tasks.
> Thanks for the help in advance.
>
>
Received on Thu Mar 07 2002 - 16:44:58 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US