Oracle Scratchpad

October 17, 2012

Pluggable 12c

Filed under: 12c,Oracle — Jonathan Lewis @ 9:03 am BST Oct 17,2012

For anyone looking for information on 12c, there are several posts about OpenWorld at the dbi Services blog (see links at right). In particular there’s a summary post about the “pluggable database” describing how you could plug a database into a “container” database, clone it inside the container database, then unplug it and put it somewhere else.

When I heard about the feature, it crossed my mind that there were two “obvious” targets for this technology that Oracle had in mind – in no particular order:

  • Consolidation onto Exadata – I’ve seen an Oracle presentation about a customer who moved 18 databases from 14 servers onto 2 Exadata quarter racks; that’s a lot of processes that have to be running per rack simply to keep the many instances idling. If you plugged all the database into a single instance you should get no application interference between databases and a minimal set of background processes.
  • Applications as a Service (or should that be Software as a Service – SaaS): if a 3rd party wants to run your Peoplesoft system for you, they would probably prefer to run one database with multiple Peoplesoft databases plugged into it.

Currently “real” consolidation means lots of work to change multiple databases into multiple schemas in a single database, and worrying about public synonyms; running multiple copies of the same application in the same database demonstrates the most extreme example of how pluggable databases bypass the problem. Just think how nice it would be, as a service provider, to keep a single “empty” Peoplesoft pluggable database in your container database which you clone whenever you sign up with a new customer. And, as a customer, if you want to change your service provider, perhaps you could insist that you supplier unplugs your Peoplesoft database so that you can plug it in at your new service provider.

23 Comments »

  1. Jonathan,

    Sure looks like a great and promising feature. It may also mean, the way we connect to the database may also change. The questions that immediately sprang up to my mind, will there be multiple listeners servicing each of these pluggable databases. If not, does the SQL *Net connection has to go through the container database. I guess we will have to wait and see.

    Knowing Oracle’s history with the bugs in new releases, hope that 12c will be ready for prime time at the time of its release,

    Thank You

    Vijay Manthena

    Comment by Vijay Manthena — October 17, 2012 @ 9:52 am BST Oct 17,2012 | Reply

    • Vijay,

      One of the nice things about early information of this type is that we can start to think of questions to ask about the sorts of problems we’ve seen in the past.

      For example I asked one of the Oracle reps about the threat of latch (or mutex) contention when you had 20 databases all running the same application and sharing the same library cache. Wouldn’t there be a problem when every SQL statement would have a copy for each database, and they would all be sharing the same library cache chain and latch/mutex.

      The answer was that the library cache chain would be dictated by the combination of dbid and sql_id.

      Comment by Jonathan Lewis — October 17, 2012 @ 10:08 am BST Oct 17,2012 | Reply

  2. Looks very much like Oracle is catching with some goodies of Sybase/MS SQL Server. Pluggable seems to be an answer to upgrade(migration) headache (though it remains unclear to me how Oracle is going to handle DD upgrade.) At least SQL Server DBA’s claim that SQL Server upgrade happens instantly once you’ve got new binaries.

    Comment by laimisnd — October 17, 2012 @ 10:07 am BST Oct 17,2012 | Reply

    • it does seem remarkably similar in concept to the SQL Server attach/detach process. It’s not strictly true that a DB Upgrade happens “instantly” though for attached SQL databases, they retain the compatibility setting (I forget its exact name now) and certain features require certain compatibility levels. Much like the compatible and optimizer_features_enable parameters in Oracle.

      Comment by nlitchfield — October 17, 2012 @ 10:16 am BST Oct 17,2012 | Reply

    • laimisnd,

      One thought that crossed my mind for upgrades is that (once everything has got to containerhood) is that you could upgrade by creating an instance and container d/b as the new version, then take your time unplugging each database from the older instance and plugging it into the newer instance.

      Comment by Jonathan Lewis — October 17, 2012 @ 10:23 am BST Oct 17,2012 | Reply

    • Actually MSSQL does not upgrade any db instantly. What it does is put it in compatibility mode with the older release, running under new code. Very close to what Nial described with the Oracle compatibility parameters. It is then up to the user to start using the new features after toggling the database off the old mode. In some abnormal cases there may be a need to run a script to upgrade the db but I have yet to see one being absolutely needed since SQL2K5. Can’t see why it should be any different with Oracle 12c.

      Comment by Noons — October 18, 2012 @ 2:57 am BST Oct 18,2012 | Reply

  3. Seems with every version of Oracle Database DBA Responsibility Begin Less and Less , Where’s The Clone its also easy

    Comment by Osama — October 17, 2012 @ 11:12 am BST Oct 17,2012 | Reply

  4. Interesting that you should mention PeopleSoft. You can put multiple PeopleSoft ‘databases’ into a single Oracle database. Each PeopleSoft database exists in a single schema, so you just create several schema. In fact this option has not been supported for several versions. It looked like an attractive idea, but there were many drawbacks (shared resources, shared tablespaces, shared database initialisation parameters).
    However, many PeopleSoft customers use different PeopleSoft products, and some even use multiple versions of the same product to access new functionality without doing a full upgrade. All the products can be gathered together through a portal (often the PeopleSoft Enterprise Portal) to produce a single experience for the user. For example, you might have HR, Financials, CRM (as an HR helpdesk), and EPM all glued together with Portal. Each product has its own database, so in the example you would have 5 databases that all have to work together. Plugging each one into a container database would seem to have lots of benefits while avoidong most of the old drawbacks.

    Comment by David Kurtz — October 17, 2012 @ 8:41 pm BST Oct 17,2012 | Reply

    • David,

      Thanks for the comments.
      I chose Peoplesoft as a name because it was the first one that I could think of that would be fairly commonly recognised and sound like the sort of application that a company might outsource.

      Comment by Jonathan Lewis — October 18, 2012 @ 9:25 am BST Oct 18,2012 | Reply

  5. From what I’ve seen so far it looks like a catch-up to the multiple databases per instance that have been in MSSQL for quite a few years now. But I fear it’s going to be done the wrong way.
    One of the big advantages of pluggable dbs in MSSQL is that each may keep its own log files. This allows for locating such log files to avoid bottlenecks.
    The info I have now is that Oracle’s implementation once again is going to squeeze all log activity through a single set of redo logs. That is a recipe for disaster in any move to facilitate consolidations.
    The argument that it’s needed to “keep database consistency” is worthless: no one looking for consolidations is asking for cross PDB consistency over and above what two-phase commit already provides.
    As such, putting all redo logs in a single set for multiple dbs is asking for serious trouble. Which of course I expect will have a solution if everyone buys Exadata.
    Guess how far that is gonna get Oracle? I’ll give you an answer now: as far as the nearest MS sales rep…

    Comment by Noons — October 17, 2012 @ 9:01 pm BST Oct 17,2012 | Reply

    • Noons,
      Regarding the redo log question – that was such an obvious design flaw that I raised it at (I think) one of the Engineered Systems breakfast seminars. The point I made was in reply to the statement “you only need one of each background process for the whole system rather than one of each for each database”.

      The answer I got later that day was that you are able to define multiple log writers (not just I/O slaves for a single log writer). At that point I should have asked whether these multiple writers would behave like the multiple log writers you get in RAC, viz: separate log file groups that have to be resynchronized on recovery – but I didn’t ask that question because it was such an obvious implementation detail that it never crossed my mind as a question that needed to be asked.

      Comment by Jonathan Lewis — October 18, 2012 @ 9:27 am BST Oct 18,2012 | Reply

      • Thanks for that, Jonathan. If it ends up being like the RAC redo groups, that’s not half bad. In fact, it’s beginning to look like the PDB concept is similar to extending the “single-node RAC” idea.
        Not as flexible as MSSQL, though: that one can restore/recover and roll-forward each PDB because each set of logs is exclusive. Let’s hope the PDB in 12c whenever it comes out will allow something similar. Otherwise it’s won’t be very useful in true consolidation.
        One area where it could improve on MSSQL for example would be in keeping the access to multiple temp tablespaces. Which Oracle supports now and MSSQL doesn’t. It’s proven to be an invaluable feature in my efforts to consolidate the multiple fractional app dbs I had here into multiple schemas in a single instance: each gets its own temp and I never have to worry about one app causing another to exhaust temp space because some duhveloper decided to code a huge SELECT DISTINCT instead of joining tables!

        Comment by Noons — October 18, 2012 @ 10:22 pm BST Oct 18,2012 | Reply

        • “Not as flexible as MSSQL, though: that one can restore/recover and roll-forward each PDB because each set of logs is exclusive. Let’s hope the PDB in 12c whenever it comes out will allow something similar. Otherwise it’s won’t be very useful in true consolidation”

          A related observation – that may give you some hope – was a comment (with the usual “safe harbor” slide) that you could upgrade by creating a new container database in the new version of Oracle, then unplug your databases one by one from the old container database and plug them into the new. This, surely, requires some interesting and significant engineering that could include the features necessary to allow differential recovery. (Bear in mind, you can recover a tablespace in situ, already).

          Comment by Jonathan Lewis — December 13, 2012 @ 10:35 am BST Dec 13,2012

    • interesting… From the glance it looks like implementing one stream of redo is more difficult than keeping them separate (?)

      btw: does MS SQL server have AWR equivalent of Oracle? Because if one starts thinkink about fundamental Oracle and MS SQL server differencies then the DD(data dictionary) and all SYSTEM packages come into mind. It’s no problem to have packages like SQL server has in the master database.
      But packages operating over DD tables of attached (“plugged inn”) database would automatically be Data Dictionary version specific meaning they can not be upgraded by a simple plug-inn.
      Now for the Data Dictionary… Well, some new features like say introducing new type of tables (subpartitioned tables for example) require DD upgrade. Can binaries be designed so that they work both for the new and old dictionary ? Hmmm, everything is possible but that is a legacy which will take it’s toll in development costs and bugs. On the other hand DD changes are not so frequent and complex, actually.

      Comment by laimisnd — October 18, 2012 @ 11:50 am BST Oct 18,2012 | Reply

      • “does MS SQL server have AWR equivalent of Oracle?”
        Not as far as I know – but they’ve been developing all sorts of monitoring and instrumentation that is going in the same direction. I’m fairly sure I’ve seen 3rd party applications that have then been supplied to sample and capture what’s available. (Remember bstat/estat ?)

        One of the big issues of adding any enhancements to anything, anywhere, is the need to avoid breaking other bits that you didn’t realise were related. Some extensions are less likely to cause problems than others, but I wouldn’t particularly pick on the data dictionary as the killer problem.

        Comment by Jonathan Lewis — December 13, 2012 @ 10:38 am BST Dec 13,2012 | Reply

  6. i agree with noons & nlitchfield with regards to catch-up with MSSQL which has the feature since 2k. For years MS was trying to catch Oracle while Oracle started vice-versa….. now everything is clear….

    Comment by DanyC — October 17, 2012 @ 9:42 pm BST Oct 17,2012 | Reply

    • by analogy: if French and English had missed each other under English channnel there would have been two tunnels (actually there are three I think ?)

      Comment by laimisnd — October 18, 2012 @ 11:40 am BST Oct 18,2012 | Reply

  7. [...] [thanks to Jonathan Lewis - Pluggable 12c] [...]

    Pingback by Oracle Database 12c and its features… « musingdba — October 18, 2012 @ 7:21 pm BST Oct 18,2012 | Reply

  8. Hi,
    i wondered about a few things as i have heard of that new behavior and as i have seen the presentation:

    * How many oracle databases/instances are running as a SaaS, so that the customers (mostly service providers) can get a benefit of it? Is this just to follow up the “Cloud hype”?
    * Several “kind of” databases (OLTP and OLAP) were plugged together In the presentation. How should this work with one instance? Usually DW databases got a oppositional configuration (just think about dynamic sampling, etc.).
    * How to protect one database from going crazy of the others? Today you can easily implement something like Solaris Resource Manager or other kind of OS features in a consolidated environment. With such a consolidated approach you have to use Oracle Resource Manager (??), which can make things more complex.

    I guess there are so many pitfalls :-)) .. let’s see ..

    Regards
    Stefan

    Comment by Stefan K. — October 21, 2012 @ 10:43 am BST Oct 21,2012 | Reply

    • Stefan,

      Good questions. Both political and technical

      Apart from the SaaS and Cloud stuff, there’s also the “consolidate everything onto a couple of Database Machines (formerly Exadata)” idea – and given the ever increasing number of background processes (something like 30 when I last checked 11.2.0.3), something needed to be done to massively long queues for CPUs even when the processes were doing virtually nothing when they got to a a CPU.

      Comment by Jonathan Lewis — December 13, 2012 @ 10:50 am BST Dec 13,2012 | Reply

  9. Jonathan, I think there is additional option (benefit?) for using this “pluggable” databases(s): having a single redo stream provides SCN consistency across N separate database/IT systems. Reality shows (e.g. in deployments of multiple separate but interconnected systems) that having consistent replica for DR across 2+ systems from point datacenterA to datacenterB was almost impossible in real life without high end storage solutions (e.g. EMC consistent groups with SRDF or some other form of snapshot replication). With “PDB” it can be as simple as putting everything into “one” box… I’m just wondering how they are going to handle “PDB” with RMAN and so on? If i would like to intentionally perform TSPITR/Flashback db for just single of the container database, will it be possible at all?

    Comment by Jakub Wartak — October 23, 2012 @ 4:11 pm BST Oct 23,2012 | Reply

    • Jakub,

      Again, a set of good questions to ask (either of the salesman, or as you design your proof of concept).
      The SCN thing is interesting – but thinking about RAC and Distributed systems, they re-syncronize all the time anyway – having to put all the databases in one basket for a small improvement in synchronisation may be too much risk for too little reward. One thought that crosses my mind is that the first question should be “why did I have separate databases to start – so would I be happy with just one (container) database now?” (There are all sorts of good answers to that question, of course, but it should still be asked.)

      Comment by Jonathan Lewis — December 13, 2012 @ 10:54 am BST Dec 13,2012 | Reply

  10. If somebody are interested still in 12c Pluggable Database insights, read here a few articles:

    http://www.dadbm.com/2013/02/oracle-12c-pluggable-database-plug-unplug-and-clone/

    — Kirill

    Comment by Kirill Loifman — February 25, 2013 @ 3:01 pm BST Feb 25,2013 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 4,011 other followers