Oracle Multitenant Review

Offers better isolation of namespaces, resources and credentials.


Valuable Features

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.

Room for Improvement

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.

Use of Solution

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.

Deployment Issues

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.

Stability Issues

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 Issues

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).

Customer Service and Technical Support

Good when we can provide a reproducible test case

Previous Solutions

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.

Implementation Team

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.

Other Solutions Considered

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.

Other Advice

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

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 are an Oracle Platinum Partner and provide consulting and training.
Add a Comment
Guest
Sign Up with Email