Re: Two instances?

From: DA Morgan <damorgan_at_psoug.org>
Date: Mon, 13 Jun 2005 09:19:55 -0700
Message-ID: <1118679615.952932@yasure>

fitzjarrell_at_cox.net wrote:
>
> Randy Harris wrote:
>

>>"David & Sarah Grove" <dg_at_ieee.org> wrote in message
>>news:11aqgnp7s38v0df_at_corp.supernews.com...
>>
>>>Folks,
>>>
>>>Consider a single machine (Sun V480/Solaris 10) running Oracle 10g.  Two
>>>parties are interested in cooperating (one brings the machine, the other
>>>brings the Oracle license).  Disk space (>500 GB) is more than enough for
>>>both. Memory (16 GB) is more than enough for both.  There are no common
>>>users.  There are no common applications.  There are no common schemas.
>>>There will be separate administration with possibly separate DBAs.  Each
>>>party will have several schemas (total of 10 - 20 schemas).  Three of one
>>>party's schemas each have in excess of 1000 tables and 1000 stored
>>>procedures.
>>>
>>>We are considering whether to just put both parties schemas together in a
>>>single instance, or, perhaps, make two instances.
>>>
>>>Might I be able to determine from vmstat whether there is sufficient
>>>"headroom" in cpu usage for a second instance?  In other words, if I get
>>
>>one
>>
>>>of the parties set up, can I use vmstat to determine whether, assuming
>>>everything else is adequate, there is enough horsepower to bring the
>>
>>second
>>
>>>party in as a second instance?
>>>
>>>Thanks for any thoughts.
>>>
>>>DG
>>>
>>
>>IMO, the most significant statement you've made is "There will be separate
>>administration with possibly separate DBAs".  Potential for differing
>>performance management, differing backup/recovery management, possibly
>>differing patch/upgrade needs.  I'd use separate instances.

>
>
> On a single server, with a single software user, you are advocating TWO
> INSTANCES? I think not. Each DBA will have access to the 'oracle'
> user account, meaning they will have access to each other's instances.
> This sends security sailing straight out the proverbial window. And,
> with ONE software installation how can TWO DBA's implement differing
> software patch/update strategies? Patches applied to the software
> apply to BOTH instances. Arguments may ensue over WHICH patches are
> relevant, but, in the end, the patches applied affect ALL instances
> running on that server. So, patch management differences don't really
> matter.
>
> I can agree differences in performance management may arise due to
> multiple DBAs on a single server. The issue is not with differing
> ideas on performance between the two instances, the issue here is one
> of licencing and security. Only the person or enterprise holding the
> Oracle licence can legally operate an instance for production purposes;
> as stated in the original post only ONE of the two parties legally
> possesses a valid Oracle licence. Also, as I've proven in another
> thread where two instances were created in the hope of data security,
> neither instance is secure and violates Sarbanes-Oxley and HIPAA if
> you're in the United States. Also, there is the liability issue, as
> stated by Daniel Morgan, should either DBA damage data or any
> functionality inherent in a database instance for which he/she is not
> responsible. Truly, two instances on the same server is folly, and I
> can't understand how anyone could possibly recommend such an 'option'
> with a straight face. Such a recommendation is a certain recipe for
> disaster.
>
>
> David Fitzjarrell

Actually David there is no requirement that multiple installations of the Oracle binaries be installed with the userid Oracle or that any of them are installed as Oracle. Nor is there a requirement that the users belong to groups named OINSTALL and DBA.

One possible workaround would be something like this:

Root is given to a single person agreed upon by both parties.
Two installations of Oracle binaries into separate Oracle homes with separate user name (neither Oracle) and separate groups (neither oinstall or dba).
Two listeners (one on port 1521 the other on 1526 for example).
After installation root password is changed with the first four characters of the root password entered by someone from one company and the next four by someone from the second company. etc.

But I don't like it and before I'd touch it I'd want the attorney's, not the CIO's, of both companies to sign off on it along with their auditors.

-- 
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)

Received on Mon Jun 13 2005 - 11:19:55 CDT