RE: 12c pluggable database shared SGA question
Date: Tue, 16 Sep 2014 13:03:36 -0400
Message-ID: <01b301cfd1d0$28e34720$7aa9d560$_at_rsiz.com>
So, if you have a hardware box with much more capability than your largest individual database provides load, and if the service levels are compatible and won't stress the shared services at peak load (as Kevin mentioned redo generation, for example, which I thought was a spot-on observation regarding NOT putting multiple high redo generation rate databases in the same tenement <- just made that up as a pithier description of the container), then the big savings is the process count for the Oracle background processes NOT being run by having more databases instead of multiple tenants in one tenement.)
Now, what if you had a couple redo crunchers and dozen little reporting databases that you didn't want to figure out whether they had, oh, say, overlapping public synonyms (or any of the laundry list of things that made database consolidations go BUMP in the night prior to multi-tenant).
Then you might have three databases instead of 14 and operate much better than with the 14. How much better? How many? Well now, your actual mileage is going to vary. It really would help for Oracle to publish some technical guidance on the squeeze points of load types on various background processes and which ones can be effectively multi-threaded and which ones are expected to hit various capacity "bottlenecks" (pacing resources). Maybe they have - I haven't been paid to look hard yet. But I would not expect that sort of analysis in a marketing sheet.
What to put together in a multi-tenant database is going to require some careful thinking about what should go together. I am aware of nothing in the architecture that prevents you from still having multiple databases on a machine, in fact having databases at different releases and doing a plug upgrade is one of the capabilities that may work out well in some situations, so I'm pretty sure nothing stops you from having multiple tenements, each with zero or more tenants.
(One thing you want to be really aware of is the backward recoverability limit if you do a plug upgrade. You'll need to understand that before you can decide whether a given tenant's service level agreements permit a "plug in upgrade."
For someone with 40 modest client databases they are hosting, none of which drive a big load compared to the hardware capability, it seems like this multi-tenancy would be VERY effective.
As for taking marketing and sales brochures without a grain of salt, I don't think many denizens of oracle-l just fell off the turnip truck.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Jeremy Schneider
Sent: Wednesday, September 10, 2014 4:29 PM
To: Glenn.Travis_at_sas.com
Cc: rajendra.pande_at_ubs.com; sethmiller.sm_at_gmail.com; Oracle-L_at_freelists.org
Subject: Re: 12c pluggable database shared SGA question
On Wed, Sep 10, 2014 at 2:56 PM, Glenn Travis <Glenn.Travis_at_sas.com> wrote:
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?
If you're talking about systems with a heavy workload, then they probably shouldn't be on the same server anyway. And in most cases they shouldn't share storage either.
I think the slides you're linking are generic product slides though. Those slides look like they were put together by someone in sales - they're just trying to think of some generic example database names. Probably "DW" was a poor choice... but these slides are meant to be a generic illustration of PDB separation and shouldn't be taken seriously as any kind of architectural advice.
-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:03:36 CEST