Oracle Multitenant Reviews

The feature that I like about Multitenant is the ease - it is very easy for my team to run the database.

In terms of what can be improved, the interface is ok. I don't know what can be better. I don't see any problem. 

I would say that the portable database should not be open as the default. That causes you to lose time.

I would also like to see an easier way to give answers when I'm working, but I think that is more about my understanding of how to work the container database. This solution is a bit complicated when collecting from containers - that feature should be a bit better.

I have been using Oracle Multitenant for less than one year.

In terms of stability, I don't see any bugs.

Regarding the initial setup, I think some people who are using the Oracle DB find it is easy, not so difficult. I installed it only for a test on a computer, not on a server. 

When I installed it on some machines, it was easy and took one hour, I think.

I would recommend this solution to anyone considering it. Oracle is a more automated database. Everywhere now I see more and more automation and it is the best administration. You can always use Multitenant.

On a scale from one to ten, I would rate Oracle Multitenant a nine.

We are not using this product in-house. We are using Oracle for the implementation of products for our customers.

Maintaining databases is a valuable feature for us.

It would be beneficial to include this solution with Oracle Enterprise, but Oracle charges additional fees for it. 

I have been working with Oracle for twenty-five years now, but two years with this solution.

This solution is stable.

This solution is scalable.

This is a good product for consolidation purposes.

We are currently using many Oracle products for Data Warehousing and Communication, but they are expensive, so we are looking for alternatives.

I would rate this solution an eight out of ten.

I primarily tested on the cloud but I tried the on-premises version once.

It's about consolidation. They are trying to solve all the issues. Oracle has many solutions for managing resources. For example, if you have many applications to maintain, some applications share the same database. They need to restart, which will impact the other applications. You will have to stop all the services and that adds to downtime.

To solve this issue, Oracle Multitenant provides one container database. It is set up with many databases within each other as in a schema database. You will make each application connected to the pluggable database.

The database becomes pluggable. Inside this container is called a pluggable database and each application contains this pluggable database inside multitenant. We can then share resources like control files, memory, etc. This lets you stop and start each application without impacting the others. This resource sharing is the most valuable feature

If you would like to do this with the older version or another system, you would have to install many databases and each database will get a resource. Then you have to buy resources for the license, CPU, server, etc.

This is the main feature they use this solution for. Of course, if you get a cloud database service, they may not give you a dedicated database. If so, they will provide a pluggable one for part of the container like virtualization or clone. You can use this solution in that way also.

According to my point of view, this is the main feature with 12c compared to 11. It is called 12c for the cloud since they are preparing to move more to the cloud.

In the cloud, you're sharing resources. Not every database has a high load, so they distribute resources from one controller to this pluggable database.

They are sharing resources because there are usually wasted resources otherwise. There are companies that check the vitalization of your server, memory, hardware, and infrastructure. You will find that 70% or 80% of your resources are wasted.

I'm not using it in production yet. It's easy to test a product. You can test it, play with it, and use the trial, but to put it into production is another story. 

That said, Oracle, in general, doesn't invest in their UI for any of their applications. If we're talking about the dashboard or other user experience, there is room for improvement. I'm talking about on-premises. The cloud version has started to improve.

The latest release is not as stable for anyone that has experience using the previous solution.

No one was using the latest version. Everyone was going to the previous version. For example, the latest version now is 12, so I'm going to work with version 11. I would then continue to work with the previous version until the stability of the new product is better, then we migrate or upgrade to that. This is the golden rule. If you got only this from me, it's enough.

Technical support takes a very long time and they aren't so cooperative.

When I was upgrading from version 11 to 12, the budget was limited, so I didn't get the latest version for production.

For me, I will go with it if I have the budget. Some features are nicer than before, but at the end of the day, you always have a limited budget. I prefer to upgrade and get specific hardware when possible. In the end, you will have to make a compromise. You will not get everything you would have liked to have.

I will give it an eight out of ten. The feature set is good, but Oracle is too complex. Anyone that has experience with Oracle knows that their product design or idea may be very good, but when you go to work it will take you hours because it is very complex.

Nothing is complete. I know that when I work with them I'm stuck with the product. Oracle is tough to implement and get it utilized for everything, but once it's implemented, it becomes stable. They give you a lot of promise, but you will face a hard journey when working with this product. It's not an easy product.

We are a solution provider, and we have implemented this solution for our customers.

One of the use cases is in a banking institution, with an on-premises deployment.

The most valuable features are the speed and ease of use.

This solution has more features, for example in security, than competing products.

The user interface for this solution can be made better.

This solution is a little bit pricey. It costs a lot of money.

This is a stable solution.

This solution is scalable.

Oracle support is ok, although I have not needed to contact them for this solution.

I have also used MySQL, but this solution has more features, tools, and is also more secure.

The initial setup of this solution is easy. For us, it went fine and took about thirty minutes.

One person is enough for deployment and maintenance.

I deployed this solution for my customer.

With respect to ROI, it is too early to say.

This is a solution that I recommend.

I would rate this solution a nine out of ten.

It's very helpful for cloning. The pluggable databases and everything works super easy, because we clone the databases every week. This saves time and effort.

In the past it would take about five hours for us, on a weekly basis, to clone one database or one environment. Now it takes less than two hours. It saves a lot of time over the weekends. Got better things to do!

I can't think of anything right now, I've been pretty content with what we have.

Less than a year.

It's pretty stable, pretty strong.

We are all stand-alone right now. We are not interact, so I'm hoping, with the kind of product Oracle comes up with, that it will definitely be scalable.

I would rate technical support at Oracle a three out of five. They're good, but not good always. It's about finding the right, knowledgeable person to talk to.

Response time is not that great. You have to say, "My production system is down." Sometimes we escalate it to our Account Manager, who's tied up with the Oracle Account Manager. Sometimes the escalation is needed, especially when it's rough. 

But I'm happy. Not overly happy, but happy with the support.

It was all a manual process. 

It took a while for us to get it, because of the new technology, but once we got the whole of it, it's pretty straightforward.

They didn't send a team. Everything's money. If they send people, it is money, and I work for the government, and we don't have that much money lying around, so it wasn't easy.

It's a pretty good product. Go for it.

1. The ability to create multiple databases without using any additional memory and CPU, and reallocating resources among these databases as needed, dynamically, without restarting.

2. The marriage of snapshot technology with this alleviating the need for additional storage for the containers.

Database development along several parallel projects used to be nightmarish when trying to keep the various tracks of development separate in a single database. With this, it is really easy to spin up a container for each project and then combine that in a separate container as needed.

The ability to integrate with every feature of Oracle Database as, for example, it doesn't currently work with Audit Vault.

I've used it for three years.

No

There have been no significant issues.

We have had no issues with scalaing it.

In the beginning it was a challenge, like any new product with teething issues. It has been much stable since.

Oracle Support is relatively unprepared for this. It have improved; but it still has a lot of room for improvement

We used to use virtual machines. However, in VMs, we couldn't allocate resources dynamically and resources (CPUs, memory, etc.) are fixed at creation time regardless of the demand. In the multitenant solution, the resources automatically adjusts to the demand, if available. For instance, in a VM solution, CPUs of VM are fixed; so if a database running in one VM needs more CPU cycles and other VMs are relatively free, the demanding VM will not get the spare CPU cycles even though they go to waste in other VMs. In a multitenant solution, the virtual database will get the spare CPU cycles if no one is using them.

It's very simple to install.

Inhouse.

That is confidential.

Since there is no additional cost for one PDB in a CDB, you should always create a single PDB in a CDB even if you plan on using only only one database. This allows you to practice management of this option and develop expertise in it.

There is no equivalent product, and the closest are virtual machines; but as I mentioned earlier, VMs are truly not substitutes.

Definitely consider this for non-production databases. Create multiple PDBs for development, QA, etc. which lets you test multiple projects in their own independent environments without additional CPU, memory or storage.

We have been working on consolidation projects. Earlier, as anybody else did, we were co-locating databases on servers, creating VMs. Now, we have moved away from that and gone to creating multi-tenant databases, so that we can consolidate. Predominately, we are using it for consolidation projects.

Even though we say Unplug Plug Upgrade is a very good feature and it does work, we are seeing that sometimes it takes longer than what we expect for larger databases. Secondly, it does have that prerequisite of first upgrading in place to 12, and then you migrate. If you have a lot of non-multitenant databases as a source, the process of making them into multi-tenant databases is sometimes a bit longer and tedious, especially if you are at the pre-12c version. That's the only place where I would see if they can directly convert maybe an 11g database to pluggable 12c. That would be great. Right now, we are upgrading in place to 12c, non-multitenant, and then making it ready for the plug in.

I have been using it for close to two years.

It has been pretty stable. We have not found any issues in terms of ease of implementation, as well as mainly performance. We are not seeing any issues.

Of course, we have been a bit cautious, moving non-production databases first, in terms of consolidation. Nonetheless, we have found it pretty reliable, so we have now gone ahead and started using it for production databases.

I feel that it is a scalable solution, but we have not reached that stage where we will start choking on the capacity. We have not reached that 255 in one, single container database, but I hope it will not choke. We have not reached that stage yet where we are reaching that limit.

Support is hit or miss, depending on who you get on the support line. I've been working with Oracle for a long time, since the 1990s. I'm pretty familiar with Oracle support, as it is with other products.

Overall, I would say this product itself is so stable that you don't require a lot of support. However, support is always a question; sometimes, you get phenomenal support. It depends on who you get. We have a lot of expertise internally, so we don't really require that much support.

As I’ve mentioned, we are long-time Oracle database users. The predominant driving factor was to find something that would get rid of creating a lot of VMs and co-locating databases. This was really an ideal solution for us. We didn't really select the product, the product selected itself.

Initial setup and configuration is so simple; one of the simplest things to do. There are no issues configuring multi-tenant; very simple set up.

Go for this. As far as this product is concerned, we are happy with this product. Definitely, if you solve the licensing part of it, the product, capability-wise and features, is phenomenal. There's no question about that. I would wholeheartedly recommend this product to anyone.

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.