Oracle Multitenant Reviews

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.

It's database software, so it's usually used for enterprise applications, for example, to ensure that you mostly use Oracle. In our country, it's mainly used by financial institutions.

I do like the security features and data recovery for features that were enabled there. With the right configurations, you can maintain an environment without retaining the risk of losing any kind of data. 

There's also a point in time recovery, et cetera. This is quite useful. 

The initial setup is simple. 

It is a stable product.

You can scale the solution as needed. 

It is very feature-rich.

Technical support could be faster. 

It's a nice product. It rarely disappoints anyone, but when it disappoints, support takes a lot, a bit of time before they sort you out. If they could improve that, then it'll be a very good experience using it.

I've been using the solution for three years.

The solution is stable. There are no bugs or glitches and it doesn't crash or freeze. It is reliable. 

It's really scalable. The licensing is easy. As you continue having more workloads, you continue to license for more calls. It moves up with you.

We are a bank and we have many, many users. 

Technical support is okay.

With support, you have an issue where you find there are these prerequisites for procedures that take a lot of time. There are logs that they need and all that. There are prerequisite procedures they usually have that usually take some time which slows down resolutions. 

Neutral

I've used MySQL in the past. 

I didn't choose Oracle. After I got certified, I got a job in a place where they already use Oracle.

It is easy to set up the solution. 

There's a GUI pop-up. It's mostly clicking  next, next, next, unless where you just specify certain items in some configurations.

The deployment time depends on the setup. If it's one single use of a database, it can take a matter of just two to three hours.

I'd rate the setup a four out of five in terms of ease of setup. 

If you have a certified DBA, it can be done in-house.

I can't speak to the cost. I don't handle licensing. 

I'd rate the solution nine out of ten. 

If well configured, it's a really nice. One should consider it. For databases, it's got very high transactions and is very low to tolerant on losing any kind of data.

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

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