FreeLists / oracle-l / Re: Server Architecture

[Dan Norris <dannorris@xxxxxxxxxxxxx>]

The only reason (or at least the only one I can think of right now) I would 
consider an architecture like this is if you had some requirement to segregate 
the DBA responsibilities for one or more of these databases. The oracle user 
account can be separated, but, perhaps more importantly, the OSDBA group 
(usually "dba") can be different for the different ORACLE_HOMEs. Since this 
value is linked in to the binaires in the ORACLE_HOME, you'd require separate 
ORACLE_HOMEs installed by different users (that also have different group 
memberships) in order to effect this change. 

I agree that this would have a serious effect on manageability and patching 
would become a full-time job for someone in this environment (assuming you at 
least keep up with quarterly CPUs). I can't imagine this would impact your 
licensing unless you license the database(s) from an application vendor and not 
from Oracle directly since the vendor-included licenses sometimes have serious 
restrictions on how Oracle can be installed and used. 

So, without some business justification for using this type of architecture, I 
would not implement it. There would have to be a requirement to do this and it 
would have to be a strong one. As it is being reviewed with management, it 
would be important to include a statement about the impact (in terms of how 
many FTE DBAs you would have to add to manage the environment). If your 
consultant keeps this recommendation in their report, you should request that 
they add such a statement to their documentation. 

I'm curious if you have such a business requirement. Without the requirement, 
you'd be left to assess this recommendation based on best practices and I think 
most would agree that this is definitely NOT a best practice. 

Dan

----- Original Message ----
From: "Freeman, Donald" <dofreeman@xxxxxxxxxxx>
To: satheeshbabu.s@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Sent: Thursday, January 3, 2008 7:26:01 AM
Subject: RE: Server Architecture




 

I'm certainly not the most experienced DBA on this 
board but It sounds like virtualization without the virtual.   It 
sounds like a single point of failure for 5 databases and, yes, it sounds like 
a 
big maintenance headache.  I don't see a  licensing impact.  You 
have to license for the number of processors on the box 
regardless.    Why not virtualize? 

 

Donald Freeman

Database Administrator II

Commonwealth of 
Pennsylvania

Department of Health

Bureau of Information 
Technology

2150 Herr Street

Harrisburg, PA 17103

dofreeman@xxxxxxxxxxx

 

 




From: oracle-l-bounce@xxxxxxxxxxxxx 
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Satheesh 
Babu.S
Sent: Thursday, January 03, 2008 12:49 AM
To: 
oracle-l@xxxxxxxxxxxxx
Subject: Server 
Architecture





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. 

 I am slightly worried about this architecture. Because when this 
architecture goes to production, the impact it will have on maintenace going to 
be huge. Assuming i am having minimum 100 db in production( ours is a very 
large 
shop) and if i need to apply one patch to all these servers going to kill us. 
Secondly, will there be a impact on licensing. I don't think so, but like to 
check it up with you guys. I know it has got some advantage too. But is this 
approach is suitable for large shop like us? 

Regards,
Satheesh Babu.S
Bangalore