Re: Server Architecture

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_at_state.pa.us> To: satheeshbabu.s_at_gmail.com; oracle-l_at_freelists.org 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_at_state.pa.us    

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Satheesh Babu.S
Sent: Thursday, January 03, 2008 12:49 AM To:
oracle-l_at_freelists.org
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

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