RE: Server Architecture

Virtualization is useful, but doesn't really solve this problem. It simply shifts the complexity from one set of shoulders (the DBA) to another set (the sysadmin). Instead of lets say 10 servers to provision, patch, troubleshoot, configure, manage, etc., there's now 50. On top of that, it doesn't really solve the performance implications of having a number of databases share the same hardware, as in reality, they're *still* sharing the same hardware, it's just now invisible to the DBA why something is running slow, or what else might be contesting for resources.  

The real answer to dealing with this type of problem is automation (full disclosure: I am one of the founders of a database automation software company). By automating the process of provisioning, patching, configuring, changing the database environments, you can dramatically reduce the complexity involved with this process. In an automated environment, there's no reason not to have separate binary installs, other than the disk space, because the maintenance overhead is negligible. There's no reason not to have separate UNIX accounts for each user, because automation solutions will abstract the different users from a management perspective (for example, when you need to patch 20 databases across 4 servers, even though there's 20 different user IDs and ohomes to contend with, the automation can deal with that complexity).  

Even from an operational/ongoing maintenance perspective, when the time comes to change passwords, or grant privileges to a user across multiple databases at once, having automation makes that process simple, predictable, and reliable. All this while you still get the security and separation benefits of having multiple OHOMEs, multiple users, on a single server.  

Whether you purchase a solution, build what you need in-house, or whatever - automation is the real way to manage environments on an ongoing basis.  

Thanks,

Matt  

--

Matthew Zito

Chief Scientist

GridApp Systems

P: 646-452-4090

http://www.gridapp.com 

 

________________________________

From: oracle-l-bounce_at_freelists.org


[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Freeman, Donald

Sent: Thursday, January 03, 2008 8:26 AM
To: satheeshbabu.s_at_gmail.com; oracle-l_at_freelists.org
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