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: spreading my wings -- looking for some recommdations/best practices

Re: spreading my wings -- looking for some recommdations/best practices

From: Ed Stevens <nospam_at_noway.nohow>
Date: Fri, 22 Oct 2004 07:41:48 -0500
Message-ID: <3juhn0pe2021ut4kqm35abkdn82uqgmd4e@4ax.com>


On 21 Oct 2004 15:14:06 -0700, joel-garry_at_home.com (Joel Garry) wrote:

>Ed Stevens <nospam_at_noway.nohow> wrote in message news:<2jfdn091hbtpjoie0p4qn1j5c2e1rs68kc_at_4ax.com>...
>>
>> The question at hand has to do with placement/specification of the
>> archive log files. I know they belong on their own file system, that
>> is not a problem. But what I see in these configurations is that in
>> one case they chose to specify that destination directly in the pfile;
>> in the other case the pfile actually references a symbolic link
>> defined in $ORACLE_BASE/admin/arch, said link pointing to the actual
>> destination, on a dedicated file system. (I've also seen the
>> archivelogs actually placed in $ORACLE_BASE/admin/arch. Even *I* see
>> problems there!) I'm leaning towards having the pfile refer to the
>> link rather than the actual destination. My thinking is that it would
>> give us more flexibility if we decided we needed to relocate the files
>> -- we would just redefine the link and Oracle would never know the
>> difference.
>>
>> Pros? Cons? Is my inclination leading me down the road to hell?
>
>If you are comfortable with this, then you probably can be comfortable
>with links:
>
>oracle:DARTH_at_deathstar /home2/oracle$ echo "gimme a drink" > foo
>oracle:DARTH_at_deathstar /home2/oracle$ ln -s foo bar
>oracle:DARTH_at_deathstar /home2/oracle$ rm foo
>oracle:DARTH_at_deathstar /home2/oracle$ cat bar
>cat: Cannot open bar: No such file or directory
>oracle:DARTH_at_deathstar /home2/oracle$ ls bar
>bar
>
>>
>> On a similar note, I've gone back and forth on my thinking about where
>> to place home-grown scripts and utilities ... the two choices being in
>> the oracle user's $HOME/scripts (where $HOME is something like
>> /local/home/oracle) or in $ORACLE_BASE/admin/scripts. I know, some
>> people insist that oracle's $HOME should be at or near
>> $ORACLE_BASE/admin, but that's a different issue . . .
>
>Definitely the former, plus additional dir's for development, personal
>and archived scripts, as well as output dir's for the script output
>and archived output. I'll bet you have scripts that survive Oracle
>version upgrades.
>
>jg

Oh, absolutely that most scripts will survive version upgrades. But just to play devil's advocate, $ORACLE_BASE/admin also survives upgrades.

$ORACLE_HOME = /u01/app/oracle/product/9.2.0 $ORACLE_BASE = /u01/app/oracle  

and $ORACLE_BASE in turn contains

 ../admin
../admin/scripts  (optional, for non-sid specific scripts)
../admin/logs  (optional, for non-sid specific script logs)
../admin/MYSID
../admin/MYSID/bdump
../admin/MYSID/cdump
../admin/MYSID/create
../admin/MYSID/pfile
../admin/MYSID/udump
../admin/MYSID/   (optional, for sid specific scripts)
../admin/MYSID/   (optional, for sid specific script logs)

When we upgrade to Oracle X.2, it will go into /u01/app/oracle/product/X.2.0, leaving everything in /u01/app/oracle/admin intact.

That said, my preference leans toward keeping my scripts and logs in /local/home/oracle, thus

/local/home/oracle/scripts  (for non-sid specific scripts)
/local/home/oracle/scripts/MYSID  (for sid specific scripts)
/local/home/oracle/logs  (for non-sid specific script logs)
/local/home/oracle/logs/MYSID  (for sid specific script logs)

I realize that either way is quite workable -- possibly equally so. But since I'm working in a bit of a vacuum, I thought I'd pick the brains of others before forging ahead and creating a structure that I'll look at in a couple of years and ask "what the h*** was I thinking?" I don't want to over-engineer something that is really rather simple, but at the same time I don't want to create something that will quickly collapse into an amorphous mess. Received on Fri Oct 22 2004 - 07:41:48 CDT

Original text of this message

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