Re: Server Architecture
- From: Dan Norris <dannorris@xxxxxxxxxxxxx>
- To: dofreeman@xxxxxxxxxxx, satheeshbabu.s@xxxxxxxxx, oracle-l@xxxxxxxxxxxxx
- Date: Thu, 3 Jan 2008 05:59:52 -0800 (PST)
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
Other related posts:
