Re: Database management techniques and frameworks

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Friday, December 05, 2003 2:44 PM

> So your approach is to write a series of custom scripts, add them to (I
> assume) oracle's crontab for periodic execution. Do you have one single
> machine (or pair of machines) that monitor remote databases? Or do you
> install these scripts on each database server? Do you leverage dbms_jobs?
> And relying on email seems kind of iffy -- what happens if you're not
> around to check your email? Page system? Escalation matrix in place?
>

7-8 servers and growing. we use data files that the scripts read. We use an NAS, so we share common
directories across servers making it easier to manage. so each server will be

<server_name>.host
each instance
<instance>.target

We use scripts to access these data files so we can change them.

For example, I have one script that tests all alert logs. It does ps -ef| grep pmon. Then logs in to each instance and gets all the alert log paths and polls them for new ORA messages.

I have another one to test whether the instances are up. This one takes the host variable and hits the appropriate *.host file. This file will have a list of all instances on that server. Then tries to log into each server.

We dont have adequate code for checking the listener? Any suggestions.

Easier to do with CRON on a platform like this than DBMS_JOB, plus I dont have to worry about the quotes.

Our threat matrix is Success, failure, warning. People carry beepers that have emails and if a failure flag comes up, they get beeped. We use warnings for this such as ORA messages in alert log, Increase in size of data file, things that arent 100% the way we want on ETL loads, etc...

> Not trying to ruffle any feathers here, and certainly, I appreciate the
> time requirements in fully answering a question as broad as the one I
> submitted, but I would like to probe further into various strategies. The
> whole "run scripts to check, install statspack, etc." approach seems both
> highly unscalable and leaves much to the whim of the individual DBA. So
> what, you've installed statspack? Do you use it regularly? Is this a
> manual review, or is some system in place to monitor changes? How easy is
> it to deploy this framework?

Scripts are very scalable. You just dont go nailing the v$views 1000 times. We do our polling stuff every 5 minutes. You cant monitor statspack all the time. We monitor it when we have a problem. That is what design is for. As I said, I also write code every day.
>
> (Does anyone here use Oracle's SNMP agents for monitoring? I've leveraged
> these -- along with a home-grown SNMP NMS (in Perl) -- to some degree at a
> multiple database site to good effect.)

not in the budget.
>
> Are there any 'design patterns for databases' around? Should we come up
> with some?

David Wendelken from casetech has some articles on his company's website. More lower level patterns. Such as different types of relations. He basically takes relational theory and makes it readable. They are quite good. Overall all high level pattersn for one size fits all doesnt work. But lower level 'relational' patterns for specific tables is a viable strategy.

Perl and C might be good. Dont know perl and Im weak in C.

>
> (I'll post my own notes on the topic of management in a future post --
> still compiling.)
>
> Adam
>
>
>
>
> <ryan_oracle_at_cox.net>
> Sent by: ml-errors_at_fatcity.com
> 12/05/2003 11:09 AM
> Please respond to
> ORACLE-L_at_fatcity.com
>
>
> To
> Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> cc
>
> Subject
> Re: Database management techniques and frameworks
>
>
>
>
>
>
> We have about 20-25 instances here. Nearly all on SUN. I dont touch the
> ones on windows. I also have development responsibilities, so I dont have
> time for a checklist.
>
> you need to automate tasks. You cant spend your time reading the alert
> log. you should poll it and get an email when something pops up. Same with
> chained rows, tablespace sizes, etc... Write scripts for this and send
> your self emails.
>
> Have statspack snapshots run daily.
>
> >
> > From: AdamDonahue_at_maximus.com
> > Date: 2003/12/05 Fri PM 01:49:30 EST
> > To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > Subject: Database management techniques and frameworks
> >
> > Folks,
> >
> > I thought it'd be interesting to take a survey on what techniques and
> > frameworks DBA's on this list use to manage their Oracle databases. I
> > imagine that some of us manage only a single database and instance, but
> in
> > those configurations where there are many instances, multiple databases,
>
> > different platforms/versions, etc., what are some of the strategies for
> > management in place? What daily tasks do you perform, and how do you
> > organize them? How do you manage user requests (individually or as part
>
> > of a larger environment)? How do you handle jobs? Organization
> > techniques? Naming standards? User/application deployment framework,
> > etc., etc.?
> >
> > (Obviously we could write a book about this -- there's an idea! -- but
> > summaries and pointers would be interesting. Perhaps we can come up
> with
> > a best practices document and associated framework for Oracle database
> > management.)
> >
> > Thanks,
> >
> > Adam
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author:
> > INET: AdamDonahue_at_maximus.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> >
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: <ryan_oracle_at_cox.net
> INET: ryan_oracle_at_cox.net
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author:
> INET: AdamDonahue_at_maximus.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Ryan
  INET: ryan_oracle_at_cox.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).