RE: Server Architecture

  • From: "Matthew Zito" <mzito@xxxxxxxxxxx>
  • To: <dofreeman@xxxxxxxxxxx>, <satheeshbabu.s@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 3 Jan 2008 12:10:23 -0500

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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Freeman, Donald
Sent: Thursday, January 03, 2008 8:26 AM
To: satheeshbabu.s@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
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

Other related posts: