RE: 12c pluggable database shared SGA question
Date: Tue, 16 Sep 2014 18:24:52 +0100
Message-ID: <020c01cfd1d3$2093b750$61bb25f0$_at_go-faster.co.uk>
PeopleSoft apps on an Oracle DB essentially live in a single schema. It used to be supported to have multiple PeopleSoft 'databases' in a single Oracle database by installing them in different schemas. It complicated things like backup and tablespace utilisation and people tended to make a mess of things, so it hasn't been supported since we were all using Oracle 8i.
Multi-tenant looks very attractive for PeopleSoft (I am still waiting for someone to go there). Take the staffing companies as an example - they have 5 databases: HR, Financials, CRM, EPM and Portal. They could be consolidated, and you can better manage the load of heavy batches (eg Payroll and T&L in HR -v- Financials). A single redo stream is no problem, because you would never consider recovering or cloning them other than as a set because of the application messaging between them.
regards
David Kurtz
tel: +44 (0)7771 760660
mailto:david.kurtz_at_go-faster.co.uk
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Jeremy Schneider
Sent: 16 September 2014 17:03
To: my42clips; fuzzy.graybeard_at_gmail.com; Freek D'Hooge
Cc: oracle-l_at_freelists.org
Subject: Re: 12c pluggable database shared SGA question
Importance: High
On Tue, Sep 16, 2014 at 11:03 AM, Kevin Closson <dmarc-noreply_at_freelists.org> wrote:
"you may get 50% reduction in CPU usage, or you may get 5% reduction."
... Does anyone have an AWR report showing background DB CPU greater than, say, 10% of cpu count? I'd like to study such a workload.
I'm also skeptical about significant cpu reduction.
IMHO, the main point of pluggable is memory rather than CPU. Many apps (ebusiness? peoplesoft?) have multiple schemas and really it's just too complicated to do schema-level consolidation of multiple instances of the app. So you end up with one database for each instance - test, dev, qa, etc. Which means one SGA for each database. If you have a lot of these instances, you might have underutilized servers just because of the memory limitations on your company's standard hardware platform. With pluggable, you can now get the memory efficiencies of schema-level consolidation but from the app's perspective it thinks that it still has it's own DB. If it reduces the number of physical servers you need, then that can cut licensing costs. But the core reason isn't a cpu usage reduction, it's a bunch of idle CPUs in the first place because memory constraints were preventing the optimal level of consolidation.
Also, if your app already can do schema-level consolidation, then you've already got something better than pluggable in many ways.
-J
--
<http://about.me/jeremy_schneider> http://about.me/jeremy_schneider
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Sep 16 2014 - 19:24:52 CEST