RE: 12c pluggable database shared SGA question
- From: Glenn Travis <Glenn.Travis@xxxxxxx>
- To: "rajendra.pande@xxxxxxx" <rajendra.pande@xxxxxxx>, "sethmiller.sm@xxxxxxxxx" <sethmiller.sm@xxxxxxxxx>
- Date: Wed, 10 Sep 2014 19:56:28 +0000
Seth, AHA! You just supported my argument.
You would NOT put a heavy DSS type application in the same database as a heavy
OLTP application. And by application, you can assume ‘schema’. These are two
entirely different beasts with entirely different tuning challenges/strategies.
So, to follow, you would not put a DSS PDB in the same CDB as a OTLP PDB.
Correct?
Yet, that is EXACTLY what Oracle is proposing with their promotional materials,
and NOWHERE does it explain the ‘sharing’ aspect of the CDB/PDBs. You have to
dive much deeper to get this info.
Bad Oracle. Bad boy.
From: rajendra.pande@xxxxxxx [mailto:rajendra.pande@xxxxxxx]
Sent: Wednesday, September 10, 2014 3:50 PM
To: sethmiller.sm@xxxxxxxxx
Cc: dmarc-noreply@xxxxxxxxxxxxx; Glenn Travis; Oracle-L@xxxxxxxxxxxxx
Subject: RE: 12c pluggable database shared SGA question
I did not mean to plug in a 11g into 12
I meant migrate a 11G into a 12c as a PDB
Regards
- Raj Pande
UBS AG
Platform Services - Operations
Global Service Delivery (GSDM)
480 Washington Blvd. Jersey City, NJ 07310
TEL# - External - +1 201 318 7597
Internal - 19 436 7597
From: Seth Miller [mailto:sethmiller.sm@xxxxxxxxx]
Sent: Wednesday, September 10, 2014 3:48 PM
To: Pande, Rajendra
Cc: dmarc-noreply@xxxxxxxxxxxxx<mailto:dmarc-noreply@xxxxxxxxxxxxx>;
Glenn.Travis@xxxxxxx<mailto:Glenn.Travis@xxxxxxx>; Oracle-L Freelists
Subject: Re: 12c pluggable database shared SGA question
Glenn,
Think of PDB's as schemas that are completely isolated and obscured from one
another. How would you manage the memory if you were adding another schema to
the database? Any database clients that have access to that new schema have the
potential of hogging all of the resources of the database, including the
memory. It is the DBA's and the developer's job to put into place the controls
that would prevent that from happening. The same goes for a multi-tenant
environment.
Rajendra,
I think the simple answer to your question is, you cannot plug an 11g database
into a 12c container. The more detailed explanation is that the redo in a
multi-tenant environment is tagged with the PDB information to which it
belongs. When a PDB datafile recovery takes place, any redo that does not
belong to that datafile is skipped.
Seth Miller
On Wed, Sep 10, 2014 at 2:32 PM,
<rajendra.pande@xxxxxxx<mailto:rajendra.pande@xxxxxxx>> wrote:
Yes
Redo being essentially a recovery structure is not that much of an issue in my
mind
Where redo does become interesting I think is when recovery needs to be done
for a truly plugged database
What I am thinking of is a PDB say taken from a 11G database and plugged into a
12C database
When you then have to do a PITR then it could get interesting because the redo
in the 12C are not applicable to that PDB.
I wonder what happens in 12C. Also you will likely also have to do a PITR in
11G (or the source database) and then replug it into 12C and then do a recovery
there…
Need some play time to try this out ☺
Have not checked or read enough on resource manager’s ability to deal with
capping at the PDB level
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>] On
Behalf Of Kevin Closson
Sent: Wednesday, September 10, 2014 2:54 PM
To: Glenn.Travis@xxxxxxx<mailto:Glenn.Travis@xxxxxxx>;
Oracle-L@xxxxxxxxxxxxx<mailto:Oracle-L@xxxxxxxxxxxxx>
Subject: Re: 12c pluggable database shared SGA question
Shared REDO *should* be the end of the conversation, really.
________________________________
From: Glenn Travis <Glenn.Travis@xxxxxxx<mailto:Glenn.Travis@xxxxxxx>>
To: "Oracle-L@xxxxxxxxxxxxx<mailto:Oracle-L@xxxxxxxxxxxxx>"
<Oracle-L@xxxxxxxxxxxxx<mailto:Oracle-L@xxxxxxxxxxxxx>>
Sent: Wednesday, September 10, 2014 9:11 AM
Subject: 12c pluggable database shared SGA question
12c shared resources:
"PDBs share UNDO, REDO and control files."
"PDBs share common SGA and background processes."
The selling point is that only small increments of memory are added as
additional PDBs are added. BUT
A problem I have with the 12c 'pluggable' database, is that is shares an SGA -
that is library cache, and buffer cache. The diagrams used in all the promo
(and training) materials show an ERP, CRM and DW type databases sharing the
same memory. This seems counter intuitive to everything we as DBAs have been
taught for many years. Those databases have completely different users and
usage patterns/requirements. I realize the PDBs are not sharing the buffers
and statements between them, but they ARE sharing the memory footprint, and
there is only so much memory.
See slides here :
[11g] http://goo.gl/wQ612C vs. [12c] http://goo.gl/eshQTA
Obviously an ERP is queried (and tuned) differently (single transactions, high
volume, key values, shared sql) than a DW (multi, complex transactions, low
number of users, long running statements, full table/index scans, low key value
usage, and non-sharable sql). Co-existence of these types of environments will
not only be impossible to tune in one SGA, but the cache will be useless. The
DW will flush out all the 'good' buffers/pages used by the ERP/OLTP application
users, and the non-sharable sql will flush out and fragment the library cache.
So the ERP will have nothing left in memory and constantly re-parse the
'sharable' sql and go to disk for all the data. This just doesn't seem logical.
What am I missing here? How can you possibly have this kind of shared
environment? I agree that 'same' type environments may work as pluggable
databases in a shared SGA, provided you have enough memory, but not disparate
databases like those in the examples.
I have asked several people, including Oracle instructors the following
question, but have not yet received a definitive, convincing answer. Comments?
--
//www.freelists.org/webpage/oracle-l
Please visit our website at
http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
for important disclosures and information about our e-mail
policies. For your protection, please do not transmit orders
or instructions by e-mail or include account numbers, Social
Security numbers, credit card numbers, passwords, or other
personal information.
Other related posts:
