Tuesday Mar 11, 2014

TomAsks - About Multitenant

Tom Kyte and I recently got together to discuss Oracle Multitenant. Our conversation has just been published in Oracle Magazine in the AskTom column. Not many people can claim to have turned the tables on Tom, but this was more of a "TomAsks" than the other way around. That's my claim to glory, and I'm sticking to it!

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Thursday Feb 06, 2014

Multitenant Buzz @RMOUG

There's a lot of buzz about Multitenant at RMOUG. Thank goodness! It's so darned cold in Denver we needed something to thaw us all out. Just got back to my hotel room from a very good dinner with the ACE Directors. Tom Kyte promised me that despite talking about Multitenant in his keynote and deep-dive sessions he's left me a little thunder for my session tomorrow at 11:15. I'd hoped to catch Leighton Nelson's talk on DBaaS but unfortunately we are on at the same time. I'm looking forward to Bryn Llewellyn's talk "Self-Provisioning Pluggable Databases Using PL/SQL" at 9:45.

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Thursday Jan 23, 2014

MicroStrategy Supports Multitenant

I've been away from the blogging game for too long and looking for a way back in. Today's announcement that MicroStrategy has certified its analytics platform for Oracle Database 12c and Oracle Multitenant is too good an opportunity to miss. This is a great example of the huge momentum towards Oracle Multitenant. MicroStrategy's announcement explains that their motivations included:

  • Increased scalability and server utilization
  • Management of multiple databases as one
  • Isolation of separate databases (as PDBs) 
  • No need to change applications or access rights


Don't just sit on the sidelines and watch the big boys like MicroStrategy enjoy these benefits! You should adopt Oracle Multitenant yourselves!

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Thursday Sep 26, 2013

OOW13 Going out with a Bang!

It's the final day of Open World 2013 today but we Multitenant types are going out with a bang, not a whimper! See our Focus on Multitenant page for today's events. 
  • DemoGrounds are all closed up now but we have a double header of presentations:
  • 1st up CON8726 Instantaneous Database Clones w/ #OracleMultitenant Option. Moscone South 200 12:30pm. I'll be joined by CMTS Margaret Susairaj.
  • My final presentation of #OOW13. Duet with Mr RAC, aka Markus Michalewicz. CON8706 #OracleMultitenant meets RAC. What a great combo! 
  • Sandwiched in the middle there is our final hands-on-lab. 
And that's all for Open World 2013! What a great event this has been! Many thanks to all our customers and partners for your interest, enthusiasm and support. We're delighted that Oracle Multitenant has been so well received. We look forward to working with you and hearing about your success stories as you roll this exciting new technology out in your organizations.

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Wednesday Sep 25, 2013

Wednesday is Appreciation Day!

Focus on Multitenant shows that we have no presentations today. However, this is the last day of our DemoPod #SL023. If you haven't picked up your Oracle PDB USB stick, this may be your last chance.

We've been giving out copies of Oracle Multitenant for Dummies in our Hands on Labs. In case you haven't had a chance to participate in a lab, you can download a PDF version of this from here.  

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Tuesday Sep 24, 2013

Tuesday in San Francisco

See our Focus on Multitenant page for today's events. 

I'm really looking forward to a deep-dive session with Architect Kumar Rajamani and Consulting Member of Technical Staff Jaebock Lee. Session CON8725 Behind the scenes of Oracle Multitenant. Noon today in Moscone South 252. There's a lot to cover in an hour but we plan to get in to several topics in depth. 

If you are lucky enough to see Andy Mendelsohn's keynote yesterday you were probably wowed by that Multitenant Self-Service Provisioning App. Have you see it yet? It's awesome. 

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Monday Sep 23, 2013

First Full Day of Open World 2013

Several sessions of interest to Multitenant enthusiasts today. Details are in our Focus on Multitenant page but here are some highlights:
  • Catch my presentation CON8707 Consolidating Databases with Oracle Database 12c. 12:15pm today in Moscone South 102.
  • Of course, don't miss Andy Mendelsohn's keynote presentation this morning. 
  • Have you got your own Oracle PDB USB stick yet? If not, come on over to our DemoPod, #SL023, to talk to our engineers and pick one up. You've seen them flying around in the PowerPoints. Time to get one in your own hands - or better still, plugged into your computer. 
  • Yes of course there's a PDB on there! If you've got a CDB all ready to go, you should be set to plug it in. 

Don't worry if you haven't got a CDB, though. There's also a VM on the USB stick. Open the ReadMe and follow the instructions to download and install Oracle Virtual Box. Then you can import this appliance and you're ready to go. It's a VM running Oracle Linux with a CDB and all sorts of PDB goodies in there. I don't want to spoil the surprise… have a look for yourself! 

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Sunday Sep 22, 2013


The build-up is finally over! Oracle Open World San Francisco kicks off today with Larry Ellison's keynote address at 6pm. Some fabulous announcements in store... Just in case you miss it here are some about Oracle Multitenant. We've got an Oracle PDB USB stick waiting for you at Demo Pod SL023. You can also go to the OTN Lounge Sunday afternoon or else Monday & Tuesday at 10am for guidance on how to set it up. It looks great but the beauty is more than skin deep. 

You can check our Focus on Oracle Multitenant Page for some of the major Multitenant-related events during the week. There are separate sections for sessions, demos and hands-on-labs. 

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Sunday Sep 01, 2013

Single Tenant Configuration

In Oracle Database 12c, Multitenant is a pure deployment choice. It is possible to upgrade from, say, Oracle Database 11g to Oracle Database 12c, non-CDB and stop there. Of course I wouldn't recommend it! I would encourage every customer to take the next step and adopt that database as a PDB by plugging it into a CDB. Note that if that is the only PDB plugged into the CDB this is what we call the single tenant configuration (using the multitenant architecture). The single tenant configuration does not require nor trigger the Multitenant licensed option. 

So, in summary, with Oracle Database 12c you have three choices:
  1. Non-CDB (the old architecture).
  2. Multitenant architecture in single tenant configuration (one PDB per CDB). No license required.
  3. Multitenant architecture with multiple PDBs per CDB. Requires licensed option but of course you can manage many as one and get all the other benefits.
An interesting question of course is, what's the point of the single tenant configuration? Well, there are still some advantages:
  1. You will be able to upgrade (beyond - say to via unplug/plug, which we expect to be significantly faster than a "full upgrade".
  2. Unplug/plug has intrinsic value as what my colleague, Distinguished Product Manager Bryn Llewellyn (author of the excellent Multitenant White Paper), calls "Third generation Data Pump". In other words, if Data Pump (using "full database" exp/imp) is valuable (and we must assume that it is!) then unplug/plug is yet more valuable for the same use cases. This by no means implies crossing Oracle Database software version. But that is among the use cases (also for Data Pump, of course).
  3. You can clone from a PDB in a single tenant configuration CDB into a different, as yet empty, CDB.
  4. It enforces the "separation of duties" between the CDB Admin and the PDB Admin.
  5. Eventually there will only be one architecture and if you don't pay for the Multitenant option you'll have to run in single tenant configuration. Get used to it now!

Each of these is an advantage over the non-CDB architecture. What I like about the single tenant configuration is that, even without requiring a license, it demonstrates a few of the key benefits of the new multitenant architecture. In this way customers can become confident of the new capabilities at no cost. Of course many of the key cost-savings benefits - CapEx reduction by consolidating multiple applications per server and OpEx reductions by managing many as one (retaining granular control where appropriate) only come from the true multitenant use case. But the single tenant configuration is a great way to dip one's toes in the water.

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Thursday Aug 15, 2013

How Many CDBs?

Fact: A CDB can contain up to 252 PDBs. 

Trick question: If I have 200 PDBs, how many CDBs do I need? 
Easy, right? One CDB! 
Wrong! (At least, probably!) 

With Multitenant, we can plug many PDBs into a single CDB, sharing overheads of background processes and SGA. This can increase hardware utilization - dramatically in some cases - and so reduce capital expenses by supporting more applications per server. Great! But wait, there's more! We also reduce operating expenses by managing many as one. But that doesn't mean that you should only have one CDB. In fact, we think you're likely to want several. Let me explain. 

I've talked to a lot of customers in the last few weeks about their consolidation plans - specifically using Multitenant, of course. For a few there has been a hesitation… "We don't want to consolidate all these applications because we don't want our air traffic control app running alongside our eBusiness Suite and certainly not alongside all those smaller departmental apps!"

"Well," I tell them, "that's ok. I probably wouldn't want to do that either - at least that's not where I'd start my consolidation project!"

I've also heard a complaint that "this 'manage many as one' business is too inflexible. Why can't I configure NOARCHIVELOG mode at a PDB level?"

Those apparently unrelated concerns end up with the same answer: It's ok to have more than one CDB!

A prominent reason to have more than one CDB is to support different Service Level Agreements (SLAs). SLAs typically include specifications of availability and recoverability; things which tend to correspond to Oracle options such as Real Application Clusters (RAC), Active Data Guard (ADG) or perhaps settings like ARCHIVELOG mode (my customer's question above). Remember that with Multitenant these things are defined at the CDB level and all PDBs plugged into the CDB inherit these characteristics. This is the "manage many as one" message.

So you'd typically have at least one CDB per SLA. Perhaps you'd have a CDB configured for your "Bronze" SLA with weekly full RMAN backups. For your "Silver" SLA you might have a CDB with Active Data Guard and daily incremental backups. (Of course there'd be a corresponding CDB on the standby side.) For the "Gold" SLA maybe you'd have all that and Real Application Clusters (RAC) as well for even higher availability and scalability. Of course you could configure additional CDBs to support any number of SLAs but in general you'd want to standardize on a few. 

With Multitenant, don't think in terms of configuring these things at the application database level. Instead think in terms of the SLA requirements of the application and plug the application's PDB into the appropriate CDB to achieve the required SLA. It's so much easier because there are far fewer moving parts. Of course you can easily unplug/plug to move the PDB to a different CDB if the SLA requirements change!

Besides supporting various SLAs, here are some other reasons you'd want to create additional CDBs.
  • (Active) Data Guard - one primary CDB and one standby CDB
  • One for each combination of incompatible system parameters (Oracle version, character set, endianness…)
  • One spare for each CDB above, for patching/upgrading via unplug/plug
  • One for low throughput (but still business-critical) applications; one (in single-tenant configuration) for each mission critical one (and maybe one for a few medium-scale apps)
So you could easily end up with one or two dozen CDBs - and you'd be doing it right. Of course you'd still be getting the benefit of Multitenant because companies with a legitimate need for this many CDBs are used to managing hundreds of databases... some of our customers have thousands of them! With Multitenant, by using this approach, this nightmare is replaced by the relatively simple requirement to manage a few groups. 

I really like the message "manage many as one" but perhaps I should be looking for a new slogan... Entries on a postcard, please.

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler

Tuesday Jun 25, 2013

Introducing Oracle Multitenant

The First Database Designed for the Cloud

Today Oracle announced the general availability (GA) of Oracle Database 12c, the first database designed for the Cloud. Oracle Multitenant, new with Oracle Database 12c, is a key component of this – a new architecture for consolidating databases and simplifying operations in the Cloud. With this, the inaugural post in the Multitenant blog, my goal is to start the conversation about Oracle Multitenant. We are very proud of this new architecture, which we view as a major advance for Oracle. Customers, partners and analysts who have had previews are very excited about its capabilities and its flexibility.

This high level review of Oracle Multitenant will touch on our design considerations and how we re-architected our database for the cloud. I’ll briefly describe our new multitenant architecture and explain it’s key benefits. Finally I’ll mention some of the major use cases we see for Oracle Multitenant.

Industry Trends

We always start by talking to our customers about the pressures and challenges they’re facing and what trends they’re seeing in the industry.

Some things don’t change. They face the same pressures and the same requirements as ever: Pressure to do more with less; be faster, leaner, cheaper, and deliver services 24/7. Big companies have achieved scale. Now they want to realize economies of scale. As ever, DBAs are faced with the challenges of patching and upgrading large numbers of databases, and provisioning new ones. 

Requirements are familiar: Performance, scalability, reliability and high availability are non-negotiable. They need ever more security in this threatening climate. There’s no time to stop and retool with new applications.

What’s new are the trends. These are the techniques to use to respond to these pressures within the constraints of the requirements. With the advent of cloud computing and availability of massively powerful servers – even engineered systems such as Exadata – our customers want to consolidate many applications into fewer larger servers. There’s a move to standardized services – even self-service.


Consolidation is not new; companies have tried various different approaches to consolidation of databases in the cloud.

One approach is to partition a powerful server between several virtual machines, one per application. A downside of this is that you have the resource and management overheads of OS and RDBMS per VM – that is, per application. Another is that you have replaced physical sprawl with virtual sprawl and virtual sprawl is still expensive to manage.

In the dedicated database model, we have a single physical server supporting multiple databases, one per application. So there’s a shared OS overhead, but RDBMS process and memory overhead are replicated per application. Let's think about our traditional Oracle Database architecture. Every time we create a database, be it a production database, a development or a test database, what do we do? We create a set of files, we allocate a bunch of memory for managing the data, and we kick off a series of background processes. This is replicated for every one of the databases that we create. As more and more databases are fired up, these replicated overheads quickly consume the available server resources and this limits the number of applications we can run on any given server.

In Oracle Database 11g and earlier the highest degree of consolidation could be achieved by what we call schema consolidation. In this model we have one big server with one big database. Individual applications are installed in separate schemas or table-owners. Database overheads are shared between all applications, which affords maximum consolidation. The shortcomings are that application changes are often required. There is no tenant isolation. One bad apple can spoil the whole batch.

New Architecture & Benefits

In Oracle Database 12c, we have a new multitenant architecture, featuring pluggable databases. This delivers all the resource utilization advantages of schema consolidation with none of the downsides. There are two parts to the term “pluggable database”:

  • "pluggable", which is new, and
  • "database", which is familiar. 

Before we get to the exciting new stuff let’s discuss what hasn’t changed. A pluggable database is a fully functional Oracle database. It’s not watered down in any way. From the perspective of an application or an end user it hasn’t changed at all. This is very important because it means that no application changes are required to adopt this new architecture. There are many thousands of applications built on Oracle databases and they are all ready to run on Oracle Multitenant.

So we have these self-contained pluggable databases (PDBs), and as their name suggests, they are plugged into a multitenant container database (CDB). The CDB behaves as a single database from the operations point of view. Very much as we had with the schema consolidation model, we only have a single set of Oracle background processes and a single, shared database memory requirement. This gives us very high consolidation density, which affords maximum reduction in capital expenses (CapEx). By performing management operations at the CDB level – “managing many as one” – we can achieve great reductions in operating expenses (OpEx) as well, but we retain granular control where appropriate. Furthermore, the “pluggability” capability gives us portability and this adds a tremendous amount of agility. We can simply unplug a PDB from one CDB and plug it into another CDB, for example to move it from one SLA tier to another.

I'll explore all these new capabilities in much more detail in a future posting. 

Use Cases

We can identify a number of use cases for Oracle Multitenant. Here are a few of the major ones.

  • Development / Testing
    • where individual engineers need rapid provisioning and recycling of private copies of a few "master test databases"
  • Consolidation of disparate applications
    • using fewer, more powerful servers
  • Software as a Service
    • deploying separate copies of identical applications to individual tenants
  • Database as a Service
    • typically self-service provisioning of databases on the private cloud
  • Application Distribution from ISV / Installation by Customer
    • Eliminating many typical installation steps (create schema, import seed data, import application code PL/SQL…) - just plug in a PDB!
  • High volume data distribution
    • literally via disk drives in envelopes distributed by truck! - distribution of things like GIS or MDM master databases
  • …various others!



Previous approaches to consolidation have involved a trade-off between reductions in Capital Expenses (CapEx) and Operating Expenses (OpEx), and they’ve usually come at the expense of agility. With Oracle Multitenant you can have your cake and eat it:

  • Minimize CapEx
    • More Applications per server
  • Minimize OpEx
    • Manage many as one
    • Standardized procedures and services
    • Rapid provisioning
  • Maximize Agility
    • Cloning for development and testing
    • Portability through pluggability
    • Scalability with RAC
  • Ease of Adoption
    • Applications run unchanged

It’s a pure deployment choice. Neither the database backend nor the application needs to be changed.

In future postings I’ll explore various aspects in more detail. However, if you feel compelled to devour everything you can about Oracle Multitenant this very minute, have no fear. Visit the Multitenant page on OTN and explore the various resources we have available there. Among these, Oracle Distinguished Product Manager Bryn Llewellyn has written an excellent, thorough, and exhaustively detailed White Paper about Oracle Multitenant, which is available here

Follow me 

I tweet @OraclePDB #OracleMultitenant

+Patrick Wheeler


The is blog is about Oracle Multitenant, new with Oracle Database 12c. It is written by members of the development team. Our goal is to provide an insight into the new architecture, the capabilities it enables, some primary use cases and its major benefits. The views expressed on this blog are our own and do not necessarily reflect the views of Oracle and its affiliates. The views and opinions expressed by visitors on this blog are theirs solely and may not reflect ours.


« July 2014