RE: DBA Support Database

Ron,

As you may have seen already, some issues have been pointed out. However, there are deeper issues... :(

Databases need to run on Servers - these servers in turn rely on other services below them, namely Disk infrastructure (such as SANs, NAS, Switch fabric, etc.) as well as other networking services such as DNS, Routers, switches, gateways, etc. As well, there are the Application and other middleware layers that take part in the equation. In addition, there are the people that manage them, the organization structure that holds it together and the IT processes that define how and who does what. As you can see, this quickly gets very complicated, and maintaining this data [assuming that an application exists to do this] becomes a priority. Miss capturing or maintaining any of this, and the data quickly gets out of date or is irrelevant so that it is no use.

I say all of this to say what comes next: Certain IT standards bodies have recongnized this and have specified that IT creates a 'Configuration Management Database' [and an application around it]. Processes around this include

• Incident Management [something breaks, a user calls the Helpdesk who record and route it, a technician fixes it]
• Problem Management [a process to identify trends in Incidents and identify/fix root causes]
• Change Management [a process to document, agree and implement changes to the IT components in a controlled fashion with adequate understanding of effects and impact]
• Other processes such as Asset Management, etc.

In addition to other things mentioned above, the Config database should be able to map Business processes [business-speak for what an IT user does to keep the business flowing] to IT components as well as maintain the relationships and dependencies of the IT components so that impact analysis can be done....

Add up all this, and you see both the need for this as well as the complexity of the issue. Prepackaged applications exist to do this all : Examples are HP's Service Desk [they have been at it a long time], Troux [www.troux.com], etc.

I hope that I haven't quenched your enthusiam - just wanted to make you understand that your mini-database will be (has to be) a component in the big picture. As a start, you could always create a 'Control Database' that lists all your Databases so that you can use it as a reference to put together a periodic publishing of a List of databases and versions, Sizes allocated and used, and other good stuff such as 'Average BCHR in the last month' :-) These tools have the capability to reference such standalone repositories and update themselves, so you haven't lost anything....

Hope this helps!
John Kanagaraj
Oracle Applications DBA
Hitach Data Systems, Santa Clara
Work : (408) 970 7002
Fax: 408 327 3402 (Call/Email prior to fax)

>-----Original Message-----
>From: DENNIS WILLIAMS [mailto:DWILLIAMS_at_LIFETOUCH.COM]
>Sent: Thursday, October 30, 2003 9:09 AM
>To: Multiple recipients of list ORACLE-L
>Subject: RE: DBA Support Database
>
>
>Ken, Ron
> I think the most important step is to ask some very hard
>questions about
>what data you really need. From what I've seen (and been
>involved in), you
>begin with a burst of enthusiasm and tend to collect far too
>much data. Then
>you can't keep it all updated, so the data tends to get
>obsolete and not
>trusted. Better to start with the minimum and add more data later.
> One thought is to collect data on the interdependencies between the
>databases. If one database has a link to another, it would be
>nice to know
>this before you take one of them down and accidentally shut
>down some other
>users.
>
>Dennis Williams
>DBA
>Lifetouch, Inc.
>dwilliams_at_lifetouch.com
>
>-----Original Message-----
>Sent: Thursday, October 30, 2003 10:09 AM
>To: Multiple recipients of list ORACLE-L
>
>
>Ron:
>
>I have heard of this being done especially in large companies that have
>many, many databases. It is difficult to keep track of all the little
>details that are spread out all over the company. Having a
>central data
>mart for this information I thing would be very helpful. The
>only problem I
>see is keeping it up to date.
>
>Ken Janusz, CPIM
>
>
>----- Original Message -----
>To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
>Sent: Thursday, October 30, 2003 9:29 AM
>
>
>> I was thinking about putting together a database that
>contains a list of
>> DBAs, servers, databases, and applications. The database
>would be used
>> by the Helpdesk and Management to see who is responsible for a given
>> application or database when problems occur.
>>
>> I thought I would check first and see if anyone has already designed
>> such a database and might be willing to share it.
>>
>> Thanks!
>> Ron Smith
>> --
>> Please see the official ORACLE-L FAQ: http://www.orafaq.net
>> --
>> Author: Smith, Ron L.
>> INET: rlsmith_at_kmg.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: KENNETH JANUSZ
> INET: kjanusz_at_att.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: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.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: John Kanagaraj
  INET: john.kanagaraj_at_hds.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).