Oracle Multitenant Reviews

The cloning features are outstanding. It’s easy to clone an existing database in the same CDB into another CDB running on-premise or even to a CDB running in a private or public cloud. This opens new doors database consolidation with an easy deployment or change of the underlying hardware.

I’ve created tons of scripts for my customers to deploy databases, set up RAC instances, and Data Guard configurations. To verify such a script takes weeks and is very error-prone. Now, I’m able to set up a database once and just add pluggable databases to it with a single command. That’s incredibly useful and, in addition, there is no longer a need for virtualization as you can simply run one CDB with more than 100 pluggable databases without the need to change your hardware.

The main area for improvement is regarding backup and recovery. Today, it’s difficult to set a pluggable database to a former point in time because flashback pluggable database doesn’t exist. Another important feature will be to support multiple character sets in one Multitenant database.

I’ve been working with this feature since 2012 while it was in beta. I’ve done some installations, but the installation rate is not that high yet because they are a bit worried about the changes in the architecture.

There are some issues when you use Multitenant with Oracle Managed Files. Unfortunately RMAN duplicate does not take care of the parameter create_file_dest.

Over the past few years, the stability of the Oracle database has improved with every new version, even though the new Multitenant database is a dramatic shift in the architecture, I did not encounter many issues with stability except some with naming conventions and commands. It isn’t simple to plug in a PDB in a database where it already belonged to, but you must first drop it – no DBA likes the command “Drop Database.”

I compared the performance of a CDB with 10 PDBS with 10 distinct databases, and the Multitenant databases in total run much faster.

5/10 - They need to improve the customer experience as there is not yet a high enough number of implementations of the Multitenant database in production.

Some of my customers are using virtualization (mainly VMware), while others are running up to 20 databases on one server. Two of them have consolidated their schemas into two big databases. The reason for all of them is to make better use of the hardware. Virtualization is nevertheless a waste of space because every guest has its own memory allocated as well as its own software stack with OS and Oracle software. Running many databases on one server has huge impacts on the availability, especially for maintenance and consolidation on schema-level, which will even make maintenance worse. This is because you need to find one window where you can patch your database for all applications – that's a lot of discussions. So for all of them, we are now testing and implementing Multitenant database.

You need to understand the concept of Multitenant database because it’s a massive architecture shift. Your scripts might no longer run and you need to change the monitoring. As I said, some namings are little confusing (like Container can be named as PDB or CDB while CDB stands for Container Database). You can unplug a PDB but can’t plugin a PDB (you need to recreate it in that event). But if you get that, it’s easy!

Oracle needs to increase the implementation rate and really allow their customers to get some benefit. I would like to allow a maximum of four or five PDBs per CDB for every customer for free (and not limited to Enterprise Edition, but for Standard Edition two as well).

Oracle database is the best you can get, and before there was no alternative to Multitenant database except Virtualization.

You need to test it. It takes some time to get familiar with the functionality, but then you will see how beneficial the option is. A DBA will save a lot of time managing databases – even more because with Multitenant it’s easy to define Application DBAs so that you can offload the nasty parts, like user management or tablespace management to the application owner.

I have found that its top-down approach from container database to the pluggable database is seamless, logical and gets aligned to business rules pretty easily. This is very valuable for our business.

I have used it for various clients and it's been working like a breeze. Its very beneficial.

It needs to have some more granular control over IO resource allocation.

I have been using it for the last two years.

We've had no issues with deployment.

We've had no issues with the stability.

There have been no issues scaling it for our needs.

Oracle Support is always helpful and reliable.

I was using the same resource manager in Oracle 11g.

The learning curve is a bit steep for Oracle RDBMS 12c Multitenant Option when it comes to resource management, but once you get the hang of it, it's simple.

It is worth every penny of investment.

It naturally aligns with other Oracle product so there was no need to evaluate other products.

Test and test it again. Make sure it aligns with business rules.

The plug/unplug is the great feature, that doesn't even need the Multitenant option. Oracle introduced Transportable Tablespaces in 1999 to move physically the user data, but metadata was still imported though Data Pump. Pluggable databases go beyond that; metadata is also transported because each PDB has its own SYSTEM tablespace. This is the faster data movement and allows copy-on-write snapshots.

Multitenant is just at the beginning in 12c R1. More features have been announced for the next generation, such as the online unplug/plug. That goes far beyond what transportable tablespaces do because they require the source to be read-only.

I've been working with Oracle Multitenant since 2012, and am in the beta program for 12c R1. 12.1 has been released, but very few customers are using Multitenant in production, and it is still in adoption phase.

Multitenant is easy to implement as it is the default, but what is not easy is that a few administration habitual procedures and scripts may have to be updated. This is why it is not yet deployed widely on production. It is in the learning phase for most customers in 12c.

Let's be clear, Multitenant architecture was a big change introduced in 12.1 and came with bugs and features that were not yet implemented. Stability and full feature coverage will come with future release.

Scalability of Multitenant architecture comes with the Multitenant option. You need Enterprise Edition plus Multitenant in order to have multiple pluggable databases managed by the same instance. Without the option, and in Standard Edition, you can create at most one pluggable database in a container database (CDB).

Good when we can provide a reproducible test case

Without the Multitenant option, consolidation is often done at server level with virtual machines, or with multiple Oracle instances in the same physical server. However, there are still a lot of resources that are duplicated for each database: software, memory, processes and system dictionary. The other option is schema consolidation, one database hosting multiple application, but isolation is not as good as pluggable databases.

Oracle Multitenant setup is not complex but can change the way the DBA interacts with the database. Some DBA scripts must be adapted. However, with the multitenant option, further administration is simplified. Once backup and HA has been defined for a CDB, new pluggable databases benefit from it without additional configuration.

I'm a good advocate of schema consolidation, but lot of applications make it impossible to do because they use fixed schema name, or public synonyms, for example. Multitenant offers better isolation of namespaces, resources and credentials.

You need to learn what changes are needed with multitenant architecture. Start to use it on a test database.

It's a really great new option for Database 12c. I think there's huge potential because it allows a container database to hold many pluggable databases. I love using it, even though there's not much information out there about it. People will realize how good it is at adopting databases without application changes.

Oracle has a lot of work to do with Multitenant because it's a new feature. For example, it prevents you from actually using it if your database has certain features that it doesn't yet support. We'll have to wait and see if the next release fixes some of these issues.

Multitenant came out with Database 12c release 12.1, which was about two years ago. I've been using it since then.

We've had deployment issues because it's so new that there are some features of our database that aren't supported.

It's stable, but it takes a lot of time to adopt all other products to use it as well. It's sad that Oracle's killed off some support for Multitenant with some features, such as Streams, CDC, and others. Release 12.2 covered some of the gaps, but feature releases need more coverage.

Release 12.2 has really improved on scalability. If you put 250 pluggable databases on one machine and the resource manager isn't up to par, you can't really move it around much.

It was a fairly straightforward initial setup. We didn't have much trouble with it.

We implemented it ourselves.

In our financial software for investment companies, we use Oracle Database. Oracle Multitenant simplifies management by consolidating multiple databases into one, optimizing resource use, ensuring security, and enabling rapid provisioning.

The best thing about Oracle Multitenant for us, as a software development company serving many clients, is its ability to consolidate multiple databases into one engine. This simplifies management and allows us to easily handle different client versions on our servers by creating copies of their databases.

While the product is overall excellent, it is quite expensive.

I have been working with Oracle Multitenant for two years.

I would rate the scalability of Oracle Multitenant as a ten out of ten. We have approximately 15 users at our company.

Technical support for Oracle is very good. They are fast and responsive.

The initial setup is not overly complex.

Oracle Multitenant is suitable mainly for large enterprises due to its high cost and resource demands. There are additional fees beyond standard licensing, which makes it expensive.

Before choosing Oracle Multitenant, evaluate your needs and Oracle Database compatibility carefully. It is great for efficient management and resource utilization, but ensure it suits your requirements and follows Oracle's recommendations.

Overall, I would rate Oracle Multitenant as a ten out of ten.