Re: describing instance

Comments embedded.

On 16 Apr 2003 14:09:46 -0700, joel-garry_at_home.com (Joel Garry) wrote:

>Ed Stevens <nospam_at_noway.nohow> wrote in message news:<ik5r9v41vuvblth3tcfti2l69ur8ot4kf4_at_4ax.com>...
>> On Wed, 16 Apr 2003 16:05:58 +0200, "Boris Findrik"
>> <risbo61REMOVE_at_yahoo.com> wrote:
>>
>> >Hi,
>> >I would like to make document system which will finaly describe our
>> >complex environment and stop the chaos :)
>> >(SID, version, init param, ....)
>> >
>> >Have anyone some examples ?
>> >Software solution? (except excell :)
>> >
>> >Regards,
>> >Boris
>> >
>> I am always a bit distrustful of this kind of document. The more
>> detailed and comprehensive it is, the more likely it is to be wrong.
>> They tend to get outdated about as soon as the ink is dry.
>
>That is why one uses scripts to do this. In some environments, I add
>them to the daily backups!
>
>>
>> That said, I do keep some docs with some of this kind of info, but
>> keep it minimal, with just enough info to point me to the true source.
>> For instance, why would I want to "document" the init parms, when they
>> are absolutely correctly documented in the init.ora file? Why would I
>> want to document the version when all I have to do is log on to an
>> instance and query that info? My TNSNAMES.ORA file provides
>> documentation on what databases I have and what servers they are
>> hosted on.
>
>I guess you've never had someone change the init.ora file of a running
>system (or change parameters online)! :-O
>

Not without my knowledge. But then I am 50% of the Oracle DBA staff here. And if I do change a parm on-line -- and decide pretty quickly to leave it -- I go ahead and make the change in the init.ora file so I don't lose it next time the database is restarted. The other 50% of the staff works the same way, and we generally don't make these kind of changes without consulting the other.

>Guess you've never had an environment large enough to have two
>tnsnames.ora! :-O

Correct. We use the tns_admin registry setting to point to a single "master" tnsnames file. There are a few special cases where this is not true. Each DB server itself keeps its own tnsnames, and some web-servers keep their own, but the "master" one used by the general population always has everything. I have actually argued against keeping *everything* in this tnsnames, but since I don't control 51% of the vote (see above on staffing) . . .

>
>Guess you've never had to answer which version one of several db's is
>when it is down! :-O

Correct. Though I do have an "out" on this one. We use Embarcadaro's DB-Artisan for a lot of our db management and whenever it opens a DB it gets the version and adds that info to it's (Artisan's) db 'catalog' info. So I can open Artisan and see the version number for all managed DB's in its navigation tree.

>
>Don't take it personal, Ed. I just think you haven't answered his
>question properly.

Nothing personal and no offense taken. I need the occasional (or not so occasional!) reminder that I've only done Oracle in one shop and tend not to see a lot of the possibilities of how my solutions might not fit other situations. While I always understand that in an abstract sense, the common failing is that we "don't know what we don't know." Even with no one pointing it out, I am painfully aware of the fact that my 'x' years of doing this has not really translated to 'x' years of experience, but is closer to one year's exerience 'x' times.

>
>>
>> That being said, I *do* keep a couple of 'quick reference' docs. One
>> lists all of my servers, their IP addresses, key OS userids and
>> passwords, and the databases hosted on each. Another lists all the
>> databases, what server they are on, and key Orcle userids and
>> passwords. I keep these docs on ---- Excel.
>>
>> I don't think you're going to find anything that automates this. How
>> would some tool maker know what information you want to document,
>> especially given the multiple platforms you may or may not have Oracle
>> running on?
>>
>> Whether you keep it in a spreadsheet, a word processing doc, or a
>> database is really somewhat irrelevant. (I am curious why you say 'not
>> Excell') This is really something you design to fit your needs and
>> temperment.
>
>Actually, you need to design it to fit the future needs of the
>organization, which they might or might not understand.
>
>There's a gazillion scripts floating around for documenting db's,
>including some nice ones on metalink and most every website devoted to
>admin. This link might work:
>
>http://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT?p_id=131704.1
>

Thanks. I'll take a look at them.

>Personally, I tend to use these sorts of scripts because they keep the
>info online in a place that someone has to deal with them will look,
>then also occasionally prettify them in the sites favorite format for
>management. And the passwords in a secret place off the computer!
>:-)
>
>jg
Received on Thu Apr 17 2003 - 08:11:44 CDT