Get started Bring yourself up to speed with our introductory content.

Five reasons to migrate to an Oracle Multitenant architecture

Oracle's Multitenant technology enables users to plug multiple databases into a single container database. Is it time for your organization to consider a migration?

I've begun to move my company's development and test databases to an Oracle Multitenant architecture. Multitenant...

isn't new, having debuted in 2013 with the initial release of Oracle Database 12c, version 12.1.0.1. So, why am I moving to it now?

Below is a list of reasons, ranging from end-of-life technology concerns to easier administration and the ability to deploy more databases on our existing systems. Read on to see if your organization should consider joining mine in adopting Oracle Multitenant, which -- for those not already in the know -- enables you to put multiple pluggable databases into a single container database. Think of Multitenant as virtualization moved to the database level.

Oracle has deprecated the non-Multitenant architecture in 12c. That's right! You will be forced to move to an Oracle Multitenant architecture at some point in the future, though there's no known plan for a version of Oracle Database in which non-Multitenant configurations will cease to exist. Even if you don't need the multi-tenant capabilities now, you can start getting used to the new approach by putting one pluggable database into a container -- what Oracle calls a single-tenant configuration.

That doesn't mean you have to pay for the extra-cost technology -- if you only have one pluggable database, Oracle Multitenant is free. But if you do want to run more than one pluggable database in a full multi-tenant architecture, you will need to pay the extra licensing fees.

Our VMware environment is approaching end-of-life. We currently run our development and test databases in VMware, licensing Oracle Database on the processors in our Oracle-only VMware ESX cluster. However, we're running ESXi 5.5, which will lose general support in September 2018. We can't upgrade to the newer ESXi 6.0 or above without being forced by Oracle License Management Services to license Oracle Database on all processors in all of the ESX clusters in our enterprise. Oracle's position is that it's too easy to live-migrate our virtual machines (VMs) to other ESX clusters, so they must all be licensed.

While running Oracle on VMware ESX has been great for us, it's clear that we can't continue to do so for the long term. My company needs to find a different solution and still remain agile in our database infrastructure. Running Oracle Multitenant on physical servers can enable us to remove VMWare from our Oracle infrastructure, while not only retaining, but also improving our agility.

Database administration gets easier. An Oracle Multitenant architecture forces a big change in how database administrators (DBAs) approach their jobs. They must understand whether particular administrative tasks need to be performed at the container or pluggable database level. However, once DBAs overcome that learning curve, they'll find their time spent administering a database is reduced.

When I started with my company, we had a dozen nonproduction databases. In seven years, that count has grown to more than 30 databases. But tasks at the container database level only need to be performed once, no matter how many pluggable databases I have. And tasks at the pluggable database level are easily scripted to loop through all of the databases for execution.

We can add more databases. My company has always struggled with the limited number of databases at our disposal. As I said, I've seen the number of nonproduction databases grow from 12 to more than 30. Our management would love for us to have even more databases for our application developers, but we're constrained by resource issues at the VMware hypervisor host.

In order to spin up another VM, we would need more memory -- it's the amount of available RAM that seems to be our bottleneck. With our Oracle Multitenant architecture, we can eliminate the overhead of memory and other system resources from every VM. This enables us to deploy even more databases than before with the same physical hardware.

Clones can be created more quickly. We have scripts in place to create a database clone. We use disk-based snapshots and clone our multi-terabyte database on the disk storage. We then mount those clone volumes to a VM and open the database.

With our current setup, we can create multiple clones of our production databases in our virtual machines. These clones are used to create test databases and many development databases that are copies of production.

Oracle Multitenant can clone a pluggable database, but also has the ability to perform a snapshot clone. A regular clone duplicates all of the data files in a database. This works great for small databases, but our primary production database is over 15 TB in size.

A regular multi-tenant clone would require duplication of the data files, but a snapshot clone completes in under a minute without duplicating them. Any changes to the clone result in new blocks on disk; the original pluggable database uses the original blocks, while the clone gets a copy of the change block only. This allows for very fast cloning, while also reducing the disk space requirements. 

Next Steps

Tips for an easier Oracle 12c upgrade

Learn how to use the Oracle Database Upgrade Assistant

An overview of Oracle Database 12c

This was last published in May 2017

Dig Deeper on Oracle database installation, upgrades and patches

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Have you migrated to an Oracle Multitenant database architecture yet?
Cancel

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close