Re: same application on multiple schemas
From: <stevedhoward_at_gmail.com>
Date: Sun, 12 Apr 2009 15:20:32 -0700 (PDT)
Message-ID: <cb9a244b-6463-4eb1-9b87-0e2481af06f2_at_k38g2000yqh.googlegroups.com>
On Apr 10, 2:54 pm, joel garry <joel-ga..._at_home.com> wrote:
>
> I'm with you, Jeremy, as I have this scenario In Real Life. A
> department was spun off to a separate company, the software is able to
> handle multiple companies within a schema, but eventually the company
> could possibly be moved off to its own hardware. So I chose to
> migrate to another schema, with the explicit expectation it could
> change to an instance which may be elsewhere. The political issues
> involved are much more difficult than the technical issues.
>
Date: Sun, 12 Apr 2009 15:20:32 -0700 (PDT)
Message-ID: <cb9a244b-6463-4eb1-9b87-0e2481af06f2_at_k38g2000yqh.googlegroups.com>
On Apr 10, 2:54 pm, joel garry <joel-ga..._at_home.com> wrote:
>
> I'm with you, Jeremy, as I have this scenario In Real Life. A
> department was spun off to a separate company, the software is able to
> handle multiple companies within a schema, but eventually the company
> could possibly be moved off to its own hardware. So I chose to
> migrate to another schema, with the explicit expectation it could
> change to an instance which may be elsewhere. The political issues
> involved are much more difficult than the technical issues.
>
We used this for what I consider to be valid reasons as well. The only real issue we ever experienced was when we didn't use fully qualified schema object names, and a high number of shared cursors that differed only by authorization (the text was of course exactly the same) caused a bazillion soft parses.
Other than that, it was nice because it allowed us to change schema objects such as packages and views easily without impacting other users, while everyone used the same infrastructure (dataguard, RAC, hardware, etc).
Regards,
Steve Received on Sun Apr 12 2009 - 17:20:32 CDT