RE: Server Architecture

From: Matthew Zito <>
Date: Thu, 3 Jan 2008 12:10:23 -0500
Message-ID: <>

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.  




Matthew Zito

Chief Scientist

GridApp Systems

P: 646-452-4090 




[] On Behalf Of Freeman, Donald
Sent: Thursday, January 03, 2008 8:26 AM To:; 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 ________________________________ From:
[] On Behalf Of Satheesh Babu.S
Sent: Thursday, January 03, 2008 12:49 AM To: 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 --
Received on Thu Jan 03 2008 - 11:10:23 CST

Original text of this message