Re: Server Architecture

Keeping track of sids and homes can be handled with a shell script in your path that you use to set the sid and oracle home. And dont set any sid or home as a login default. That way if the dba is used to setting it each time, he or she is less likely to make a mistake. Something simple and easy to remember, like . myenv orcl

You can also call the script for cron jobs that may run against multiple instances.

On Jan 3, 2008 11:37 AM, Matthew Zito <mzito_at_gridapp.com> wrote:

> Well, that can get messy with a) remembering what databases are in what
> homes, and b) naming conventions and the like. It's useful to be able to
> say, "I know what the home is purely by virtue of the instance name" or
> something similar. Or if someone moves a database over and another DBA
> doesn't get the memo, and it gets started out of the wrong home or what have
> you. Badness can result.
>
>
>
> Thanks,
>
> Matt
>
>
> ------------------------------
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Dan Norris
> *Sent:* Thursday, January 03, 2008 11:26 AM
> *To:* tanel.poder.003_at_mail.ee; Oracle L
> *Subject:* Re: Server Architecture
>
>
>
> If they're all on the same patch level today, why introduce all the
> ORACLE_HOMEs today? Personally, I'd keep them all on the same ORACLE_HOME
> now and when one wants to patch and the others aren't ready, spin up a new
> ORACLE_HOME, patch it, then migrate the DB in question to use the new
> ORACLE_HOME at that point. That way, if you don't run into patching
> conflicts, you'll never need the extra ORACLE_HOMEs. Is there something
> wrong with my logic?
>
> Dan
>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l