Glenn, I don't disagree with you, although DB In-Memory makes it much more feasible to do this and DBIM can be managed at a very granular level. I would not agree with you, however, that you would not put DSS and OLTP together. It depends on the circumstances. Seth Miller On Wed, Sep 10, 2014 at 2:56 PM, Glenn Travis <Glenn.Travis@xxxxxxx> wrote: > 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 > <sethmiller.sm@xxxxxxxxx>] > *Sent:* Wednesday, September 10, 2014 3:48 PM > *To:* Pande, Rajendra > *Cc:* dmarc-noreply@xxxxxxxxxxxxx; 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> 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 J > > > > 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] *On Behalf Of *Kevin Closson > *Sent:* Wednesday, September 10, 2014 2:54 PM > *To:* Glenn.Travis@xxxxxxx; 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> > *To:* "Oracle-L@xxxxxxxxxxxxx" <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. > > >