Re: Server Architecture

  • From: Dan Norris <dannorris@xxxxxxxxxxxxx>
  • To: tanel.poder.003@xxxxxxx, Oracle L <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 3 Jan 2008 08:25:49 -0800 (PST)

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

----- Original Message ----
From: Tanel Poder <tanel.poder.003@xxxxxxx>
To: oracle-l@xxxxxxxxxxxxx
Sent: Thursday, January 3, 2008 10:05:40 AM
Subject: RE: Server Architecture




 

One good 
reason for separate sets of binaries is patching and patch testing on one 
database without affecting others. 

 

Having all 
installations under different Unix users (and also groups in this case!) may be 
better for security but will make the everyday maintenance, refreshes etc 
probably harder... as you'll have various problems with permissioning and file 
access, need to constantly su between users, chmod/chown files etc... that's 
unless you want to chmod 777 all your directories & files, which would 
heavily go against the security principles again.

 

I know quite 
many shops which use a separate software installation (and set of database 
directories) for each database and it works well. You need to do more manual 
work for applying patches for all software installations (unless you use 
automatic provisioning of some sort), but you win in flexibility to 
patch/upgrade only selected databased in the server instead of 
all.

 

Regarding 
different users for each database - this may be useful if you want 
fine-grained separation of duties - by database. However this approach will be 
useless if all your DBAs have access to all accounts anyway, in this case you 
will just make your life harder without gaining any benefit. So you should 
figure out if you really need all your Oracle installations under different 
unix 
usernames and whether the benefit outweighs the maintenance overhead. 


 

In summary 
(YMMV):

 

- different 
oracle homes for each instance - YES

- different 
unix user for each oracle installation - NO ( use single unix user and separate 
environment files for each instance ).

 

--
Regards,
Tanel Poder
http://blog.tanelpoder.com


 



  
  
  From: oracle-l-bounce@xxxxxxxxxxxxx 
  [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew 
  Kerber
Sent: Thursday, January 03, 2008 21:56
To: 
  satheeshbabu.s@xxxxxxxxx
Cc: 
  oracle-l@xxxxxxxxxxxxx
Subject: Re: Server 
  Architecture



  
It does sound like a real maintenance nightmare.  What is the 
  problem they are trying to solve that requires 5 identical sets of binaries 
  under 5 different users, as opposed to (worst case normally), 1 set of 
  binaries and 5 instances? 


  On Jan 2, 2008 11:49 PM, Satheesh Babu.S <satheeshbabu.s@xxxxxxxxx> 
  wrote:

  
    All,
 We have been proposed with following architecture by our 
    consultant. I need your expert opinion on this.
 
 Assume a 
    server got 5 database and all the databases running in same oracle version 
    and patchset. 
They are proposing to create 5 unix account. Each unix 
    account will have one oracle binaries and corresponding oracle DB. Apart 
    from that each unix account will have dedicated mountpoints. In broader 
    sense each unix account will be logically considered as one server. 
  




Other related posts: