Re: Sharing an Instance vs Using Separate Instances??

Richard A Papaj wrote:
>
> I'm curious if having apps share an instance (separate schemas) is a common
> practice? We do some of it here (we have some small OLTP apps sharing
> instances, DSS apps sharing others) but there are issues; different software
> packages may be ok under the same version of the dbms when you start but
> eventually separate instances may be required for app/dbms compliance (i.e.
> you may want to upgrade the dbms and that may be ok for certain apps but not
> for others), availability (downtime for one could mean downtime for all),
> contention, etc.
>
> On the other hand, for small apps, a separate instance per app may be
> overkill in terms of resources. And you end up having to administer a
> larger quantity of instances; 20 small instances vs 5 larger, shared
> instances for example (i.e. viewing 20 alert logs vs 5, etc). And multiple
> instances per UNIX machine will consume available memory more quickly (ever
> have to balance the "processes" init parameter between multiple instances on
> a machine?)
>
> Any feedback is appreciated. Thanks.
> -Rick P

I prefer large shared instances to many small instances. However, I try to not share different query/transaction types. OLTP apps would share one or more instances while DSS apps would be in separate instances. This is because some of the Oracle parm tuning is different depending on the workload characteristics. With less instances you can also spend more time looking at each one and do a better job of maintaining the systems.

As for the app/dbms compliance issue, you need to set the stage. Work with your management so they understand the tradeoffs and that you can perform a better job with less instances. Then, hopefully you will have some backing in turning down requests for dbms upgrades as soon as they are available. We do a structured rollout plan. When the first application starts talking about a new dbms release, we begin talking to all the apps about what releases are supported by their application and when the next application release is due. Then we can usually create a schedule that works for most of them, although we have had to leave an application behind in a separate instance when they can't upgrade with the others.

One other note is that our current minor upgrade was requested by me and approved by the apps instead of the other way around. We are upgrading from Oracle 8.0.5.2.1 to 8.0.6 for support purposes. Before anyone asks, it's 8.0.6.0.0 because there's no patchset available yet for the 64 bit version on HP/UX.

Big Al Received on Tue Oct 10 2000 - 18:56:08 CDT