RE: Server Architecture
- From: Tanel Poder <tanel.poder.003@xxxxxxx>
- To: "'Dan Norris'" <dannorris@xxxxxxxxxxxxx>, "'Oracle L'" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 04 Jan 2008 01:03:02 +0800
Dan,
Nothing wrong from purely technical set-up perspective. And I agree with
your other point - if it works, don't fix it...
However the OP asked about future strategy and the present state of
installations should be just one of many inputs to the future strategy.
Often when radical changes are made to standards, the old systems remain as
they are as "legacy" setups, once they're upgraded to new standards due
software/hardware upgrades, data centre migrations or are eventually
decommissioned.
In order to keep thousands of databases manageable in a big enterprise with
global "anonymous" DBA teams you need some kind of uniform standards of
database setups & builds.
One way is to install one oracle home (per db version) per server, save the
space and if you're lucky then avoid additional patching hassle.
However from the moment you need to patch or test upgrade you need to:
1) get new storage for the new home - may not be that easy in practice if
storage consolidation & utilization improvement intiatives are going on in
the company
2) deploy software / patch it - easy part
3) change configuration files to point to new home - there's a maintenance
risk as depdendencies between datbaase & software installations are not
immediately obvious (there's no 1-1 matching between a db and its software).
Another way is having one oracle home for each database in server.
Having strictly one home for each database means more storage and
potentially more patching work - but this setup itself is simpler - and
uniform. Thus you lower the risk of creating a configuration jungle where
no-one understands the dependencies between components within a server.
The latter way may be less efficient in storage and some maintenance work
sense, but at least its configuration complexity is stable, thus lower risk
when managing these databases.
As I said earlier, YMMV... but i've become an advocate of "self-contained"
systems for flexibility & lower risk over last few years. The baseline is,
make sure you think your standards through based on YOUR requirements and
make sure you follow that standard, otherwise it's useless.
Btw, a little less known performance thought supporting the
single-oracle-home-per-server approach. If you use a single home for let say
20 dev databases in a server, then all Oracle processes will be sharing the
same physical pages of the Oracle executable text section. This means less
memory utilization, potentially less executable page TLB misses and warmer
instruction caches when context switching to another instance's process
running the same binary... so you could save a tiny amount of CPU ;-)
--
Regards,
Tanel Poder
http://blog.tanelpoder.com <http://blog.tanelpoder.com/>
_____
From: Dan Norris [mailto:dannorris@xxxxxxxxxxxxx]
Sent: Friday, January 04, 2008 00:26
To: tanel.poder.003@xxxxxxx; Oracle L
Subject: Re: Server Architecture
If they're all on the same patch level today, why introduce all the
ORACLE_HOMEs today? Personally, I'd keep them all on the same ORACLE_HOME
now and when one wants to patch and the others aren't ready, spin up a new
ORACLE_HOME, patch it, then migrate the DB in question to use the new
ORACLE_HOME at that point. That way, if you don't run into patching
conflicts, you'll never need the extra ORACLE_HOMEs. Is there something
wrong with my logic?
Dan
----- Original Message ----
From: Tanel Poder <tanel.poder.003@xxxxxxx>
To: oracle-l@xxxxxxxxxxxxx
Sent: Thursday, January 3, 2008 10:05:40 AM
Subject: RE: Server Architecture
One good reason for separate sets of binaries is patching and patch testing
on one database without affecting others.
Having all installations under different Unix users (and also groups in this
case!) may be better for security but will make the everyday maintenance,
refreshes etc probably harder... as you'll have various problems with
permissioning and file access, need to constantly su between users,
chmod/chown files etc... that's unless you want to chmod 777 all your
directories & files, which would heavily go against the security principles
again.
I know quite many shops which use a separate software installation (and set
of database directories) for each database and it works well. You need to do
more manual work for applying patches for all software installations (unless
you use automatic provisioning of some sort), but you win in flexibility to
patch/upgrade only selected databased in the server instead of all.
Regarding different users for each database - this may be useful if you want
fine-grained separation of duties - by database. However this approach will
be useless if all your DBAs have access to all accounts anyway, in this case
you will just make your life harder without gaining any benefit. So you
should figure out if you really need all your Oracle installations under
different unix usernames and whether the benefit outweighs the maintenance
overhead.
In summary (YMMV):
- different oracle homes for each instance - YES
- different unix user for each oracle installation - NO ( use single unix
user and separate environment files for each instance ).
--
Regards,
Tanel Poder
http://blog.tanelpoder.com <http://blog.tanelpoder.com/>
Other related posts:
