8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Misc » Here

Oracle Database Consolidation Comparison

Having read numerous comments by people who blindly extol a one-size-fits-all approach to database consolidation, I felt compelled to produce a more reasoned overview.

Before deciding on a database consolidation method, you really need to have a clear picture in your mind of what your goals are and what compromises you are willing to make in pursuit of those goals. There are several possible ways of achieving database consolidation, but all of them have specific pros and cons. The trick is to find one that has all the pros you need, with as few cons as possible. Invariably, no one consolidation method will be perfect for all your needs, so you will have to use multiple or compromise.

To keep things simple, this article will attempt to ignore high availability, except for the odd passing mention.

Related articles.

Basic Resource Consolidation

At its simplest level, any type of consolidation will only work if there are enough resources available to complete the total workload. This is true of all resources, including CPU, memory, disk and network. When you are looking to consolidate databases you must make sure that all the workload profiles are compatible.

The following graph shows two databases, both with high resource requirements at different times of the day. Since the high workloads don't overlap, these workloads are suitable to be consolidated.

Consolidation 1

In the next case, the workloads run throughout the day, but the combination of the workloads does not exceed the capacity of the server at any point. These workloads are also suitable for consolidation.

Consolidation 2

In the following case, the combination of the workloads takes the resource usage above the maximum capacity of the server, which means these workloads are not suitable for consolidation.

Consolidation 3

Whenever you are considering any form of consolidation, you have to always keep in mind the total workload that will result from it.

Virtualization

Splitting the physical hardware into several virtual machines provides hardware consolidation, not database-specific consolidation. For example, we may start off with 10 databases, each on its own physical server and end up with 10 databases, each on its own virtual machine, but running on a single physical server. This maintains the separation between the systems, with each able to run at a different OS and database version if required. There is of course resource associated with running the operating system in each of the 10 VMs, so this could be seen as wasted resources. What's more, there is no reduction in the amount of patching, upgrading and monitoring necessary as each VM feels like, and is handled like, a separate machine. The relative performance of the different databases is controlled by the hypervisor and the definitions of the virtual machines.

Virtual Consolidation

Pros:

Cons:

Containers

Containers can be thought of as providing a "thinner" version of virtualization, giving some of the application separation, but with less overhead compared to virtualization. For example, on a single server we might have 10 containers, each with its own Oracle installation and database. All these containers will actually be based on a single shared operating system.

Container Consolidation

Pros:

Cons:

Multi-Instance

In the multi-instance approach, we might have a single server running 10 separate databases, each with its own instance. Since there can be multiple Oracle installations on a single machine, these could be running at different database versions, but they would all be running on the same version of the operating system. This does not have the added overhead of the virtualization layer, but does ultimately have reduced flexibility as any change to the operating system affects all databases. The relative performance of the databases can be controlled based on their memory allocations and instance caging. Each database is still independent, so the total amount of database patching required is unchanged.

Instance Consolidation

Pros:

Cons:

Schema Consolidation

Some database applications are built with very few dependencies outside the main schema owner. For example, the application server may connect to the database using a single database user and handle security internally or externally using LDAP. Provided the application does not make use of public database resources, like public database links or public synonyms, then it is possible to consider schema consolidation. If we consider 10 such schemas, each currently housed in their own database, these could be consolidated into a single database as separate schemas with no loss of functionality or reduction in security. Oracle Resource Manager can provide some control over CPU and I/O between these schemas, but there is no control over memory usage. Since the 10 databases have now been consolidated to 10 schemas in one database, there is even less flexibility, since all must be running on a single version of the database. There is a reduction in administration though, since there is now only a single database to patch.

Schema Consolidation

Pros:

Cons:

Multitenant Option

The multitenant architecture introduced in Oracle database 12c makes consolidating databases into a single instance significantly easier than attempting to do basic schema consolidation. Having said that, many of the pros and cons are closely aligned with schema consolidation, except that pluggable databases provide namespace separation, allowing each pluggable database to make use of public database links, public synonyms and matching database user names, without any name clashes with the other pluggable databases. Oracle Resource manager can prioritise resources between PDBs.

Multitenant Consolidation

Pros:

Cons:

Cloud

There are several ways to run Oracle databases in the cloud, as discussed here. Depending on the cloud service you choose, some of the consolidation methods discussed here may be useful in reducing the total cost of your cloud environment.

If you are running Oracle databases on a self managed virtual machine in the cloud, the following consolidation methods are still available to you.

If you are using a Database as a Service (DBaaS) offering, you will probably be limited to one of the following.

Conclusion

As you can see, there are lots of options, each with their own pros and cons. As I mentioned previously, you will undoubtedly use a variety of techniques. Using the company I currently work for as an example, at the time of writing, we use all of them with the exception of the paid multitenant option.

In short, if someone tries to tell you there is one best solution to consolidation, they are either trying to sell you something, or they don't really know what they are talking about!

For more information see:

Hope this helps. Regards Tim...

Back to the Top.