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.
Improvements to My Organization
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.
Room for Improvement
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.
Use of Solution
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.
Customer Service and Technical Support
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!
Pricing, Setup Cost and Licensing
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).
Other Solutions Considered
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.
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor. The reviewer's company has a business relationship with this vendor other than being a customer: We're partners.
Oct 01 2016