RE: 12c pluggable database shared SGA question

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 J  

Have not checked or read enough on resource manager's ability to deal with capping at the PDB level  

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Kevin Closson
Sent: Wednesday, September 10, 2014 2:54 PM To: Glenn.Travis_at_sas.com; Oracle-L_at_freelists.org Subject: Re: 12c pluggable database shared SGA question  

Shared REDO *should* be the end of the conversation, really.      

From: Glenn Travis <Glenn.Travis_at_sas.com> To: "Oracle-L_at_freelists.org" <Oracle-L_at_freelists.org> 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?

--
http://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.
--
http://www.freelists.org/webpage/oracle-l