Introducing Oracle Multitenant
- by OracleMultitenant
0
0
1
1142
6510
Oracle Corporation
54
15
7637
14.0
Normal
0
false
false
false
EN-US
JA
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-language:JA;}
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
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.
0
0
1
113
650
Oracle Corporation
5
1
762
14.0
Normal
0
false
false
false
EN-US
JA
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-language:JA;}
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!
Benefits
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
