More than separate ORACLE_HOMEs, you might also consider individual "oracle"
software owner accounts and "dba" and "oper" groups for each database...
Folks often install all Oracle distributions under a single account,
"oracle", specifying a single SYSDBA group ("dba") and a single SYSOPER
group ("oper"). The intent is usually to have database instances share
ORACLE_HOMEs where possible...
There are several practical downsides to this:
* different applications may require different patch levels of the same
version (i.e. same ORACLE_HOME)
* it is difficult to track resource consumption (i.e. cpu, memory, I/O)
using OS utilities if numerous Oracle database instances run under the
single "oracle" account
* if administration of different database instances is to be performed
by separate individuals or teams, there is no way to isolate/protect each
team's "territory" from another
Although HW vendors (including Sun) have developed "partitioning" schemes
for servers, it is perhaps overkill. A form of "server partitioning" has
always been possible by making creative use of OS accounts and groups. The
major difference between the HW vendors "server partitioning" scheme and
using OS accounts to separate things is the fact that the former actually
assigns groups of CPUs and allocates memory to each partition. Dividing by
OS accounts allows all resources to be shared amongst the "partitions". The
trade-offs should be obvious...
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Wednesday, October 09, 2002 3:18 PM
> Others have addressed the performance issues.
>
> What about the admin issues?
>
> If consolidate to a single server, consider a separate
> ORACLE_HOME for each database. You may need
> to apply different patches to fix different problems in
> various databases.
>
> You have this ability now, but will lose it if you consolidate
> without separate ORACLE_HOME's.
>
> Something else you will lose is the ability to reboot the
> server if needed for a single database.
>
> Since you may be moving to a 15k, investigate server
> partitioning to retain this functionality.
>
> Jared
>
>
>
>
>
> "Miller, Jay" <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 10/09/2002 11:53 AM
> Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
> cc:
> Subject: Advice needed on move to Sun 15K (losing spindles)
>
>
> Our CIO has suggested that we get a Sun 15K to house all of our
> databases. This has some advantages (communication between the various
> boxes would be much faster) but I have some performance concerns.
>
> Specifically, our main OLTP database would go down from 18 spindles to 8
> spindles. Mirroring will take away 4 of those leaving 4 spindles. The
> vendor (Sun) was recommending striping across all 4 spindles. He said we
> don't need to worry about i/o issues because there will be a large cache.
>
> I'm skeptical and argued for cutting them in half (striping 2 and 2). We
> could then at least seperate the redo logs from the datafiles (probably
> putting them with the oracle executables and some other files).
>
> The Sun rep kept talking up how much more powerful the CPUs were and I
> kept
> saying, "but we're not CPU bound, we don't need any more CPU".
>
> If anyone can either
>
> a) tell me I'm worrying for nothing
> b) recommend a better way to stripe/distribute my files
> c) provide references or experience to show this is a bad idea
>
> I'd really appreciate it.
>
>
> Thanks,
> Jay Miller
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Miller, Jay
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
