Re: Sorry, but...

From: Noons <wizofoz2k_at_gmail.com>
Date: Mon, 9 Jan 2012 13:22:18 -0800 (PST)
Message-ID: <cb972f9a-cf17-412e-9b5a-95cc12cf7242_at_f33g2000yqh.googlegroups.com>



On Jan 10, 4:52 am, "Gerard H. Pille" <g..._at_skynet.be> wrote:
>

> What exactly do you guys understand by "shared db server"?  I don't mind an RTFM for an answer,
> just say which one.

I think there is a bit of confusion here. Mladen seems to be meaning the Oracle shared connection facility, usually called "shared server" and sometimes "multi-threaded server". As opposed to dedicated connections, one per individual login. Logins can of course be pooled by the applications, but that is another story.

I'm talking about simply using the same database instance for more than one application/schema. Consolidation. Which is possible with either shared or dedicated server, pooled or not pooled. It's just a matter of organizing and managing disk, memory and CPU resources. As well as authorizations. Simple, really.

I've now got up to 5 applications consolidated in a single server/ instance and they all work fine and don't trod over each other's space/ resources. Almost perfectly isolated. And yes, I have tables with the same name in each application/schema. Not a problem at all.

I've also got test and development databases of each application living in the same server/instance. Not a problem at all.

I wish Oracle allowed me to have multiple undo tablespaces active at the same time and life would be peachy. As is, multiple temps are very effective but of course not a perfect solution. A few other touches needed. But that's for another occasion.

The only one I can't share is Peoplesoft but that one has never been sucessfully shared, AFAIK: too many dependencies on a single "PS" login. Received on Mon Jan 09 2012 - 15:22:18 CST

Original text of this message