RE: Server Architecture
Date: Thu, 3 Jan 2008 07:40:17 -0700
Message-ID: <KEEDIPJOJLCHPPAIDPDOGELDGBAA.robertgfreeman@yahoo.com>
Zoinkies, why? What is the benefit of this architecture? It requires more
disk space, more effort to manage and really is not a standard approach to a
host with multi-databases. What is the thinking here, because I see few
benefits and lots of headaches.
Robert
Robert G. Freeman
Oracle Consultant/DBA/Author
Principal Engineer/Team Manager
The Church of Jesus Christ of Latter-Day Saints
Father of Five, Husband of One,
Author of various geeky computer titles
from Osborne/McGraw Hill (Oracle Press)
Oracle Database 11g New Features Now Available for Pre-sales on Amazon.com!
BLOG: http://robertgfreeman.blogspot.com/
Sig V1.2
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Satheesh Babu.S
Sent: Wednesday, January 02, 2008 10:49 PM
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-lReceived on Thu Jan 03 2008 - 08:40:17 CST