Database consolidation means running databases on a common set of infrastructure, most often to reduce costs and increase operational efficiency. The business drivers and approaches to consolidation are the same, regardless of whether consolidation is done in an on-premises data center, or in the Cloud.
In this article, we will look at why organizations choose to consolidate databases, options for how to achieve consolidation, and addressing the following questions and issues:
This article is intended to give the reader a better understanding of the business drivers behind consolidation as well as the tools available to strike the best balance between consolidation and isolation to meet business goals. The overly simplistic approaches advocated by some often result in higher costs and increased work for operations teams.
Business considerations are the primary driver behind database consolidation. Organizations are constantly driving toward greater efficiency, accomplishing more work with less effort, while still meeting business goals. The main business drivers of consolidation are:
Costs are lower with consolidation because the same databases run on less hardware. This also applies in Cloud deployments because companies are still paying for use of the underlying hardware. It might be harder to track and visualize in some Cloud environments, but more hardware means higher cost. Regardless of whether you databases are deployed on hardware in your on-premises data center or in a Cloud data center, utilization of those systems will drive costs.
Simplicity is essentially another cost reduction factor because simplicity results in less labor. We prefer to focus on the simplification aspects because there is not always a straight line from labor reduction to cost reduction. Simplifying one area typically means that personnel are shifted to other areas and focus on higher value work. Consolidation means fewer configuration items an organization needs to manage, which takes less effort and allows people to focus on other, higher value work. Simplifying Information Technology also makes an organization more agile and more able to respond to business needs rather than focusing on managing the complexity inherent in divergent systems.
Application Developers also gain benefits from simplification through standardization on the Oracle converged database. Oracle Database meets the needs of ALL application developers because it's a single converged database rather than multiple, incompatible technologies. One technology to learn and develop with rather than many technologies.
Developers don't have to choose a specific database that meets a single purpose, making development decisions easier and allowing developers to focus on new business requirements.
Security is improved by consolidation and standardization, which minimizes the number of vulnerabilities an organization has to protect themselves against. Consolidation forces companies to standardize on fewer technologies, which allows the organization to focus on employing best practices needed to secure those technologies. Consolidation also results in fewer instances of each, giving companies fewer points of vulnerability as well as commonality across systems. Consolidation also allows organizations to deploy security fixes more quickly, simply because there are fewer systems to manage.
Exadata is the ideal platform for consolidating databases because it builds upon and strengthens the fundamental business drivers outlined above. Exadata includes a wide range of innovations specifically designed to make it the most effective platform for consolidation. With more than 10 years on the market and with thousands of systems deployed, Exadata is the best choice for database consolidation due to considerations of:
Cost is a fundamental business driver, and costs are reduced by fully utilizing the capabilities of Exadata. The high performance of Exadata allows it to service more databases, resulting in lower costs. Many organizations deployed their first Exadata systems only for mission critical systems, where over-investment was often justified. For example, one customer runs over $1B worth of business on a single large Exadata system, so if that system is only 20% used it's easily cost-justified by the business critical nature of the application. Making better use of Exadata systems results in much lower costs, and make Exadata cost-competitive with other platforms. Any asset that is only 10% or 20% utilized will not be cost-effective, so we lower the cost of Exadata simply by using it more through consolidation.
Simplicity of operations is improved by consolidation alone, but consolidation onto Exadata results in further simplification. Exadata is a single platform that can run any Oracle Database, at any scale, with any workload. Exadata is the only fully integrated enterprise scale system that includes servers, storage, operating system, drivers, logical volume manager, Clusterware, and Oracle Database in a single package. Other converged (or hyper-converged) platforms also lack critical components such as RDMA over Converged Ethernet and Persistent Memory that Exadata contains by default. With more than 11 years of development, Exadata includes standardized operational practices that contribute to the simplicity of operation. The standardized care & feeding of Exadata has been built into the Oracle Cloud (and Exadata Cloud at Customer) to drive even greater simplicity.
Security is improved simply through standardization and consolidation, but Oracle Database and Exadata provide even greater security than other solutions. The reason is because Exadata is a "full stack" system, comprised of servers, operating system, networking, storage, virtual machines, logical volume manager, and the Oracle Database software. Only Oracle provides a single full-stack solution that include the Oracle Database. Oracle then ensures security by executing the most commonly used security scanners against the full stack, and Oracle works to address any security concerns through each successive product release. No other product on the market provides such a secure foundation, and this same foundation is then used in the Oracle Cloud to provide the most comprehensive database security solution possible.
Availability is always a concern in consolidated environments because more databases and more business applications are reliant on fewer systems. The scope of failure impact is potentially increased when databases are consolidated, so availability is always a concern. Exadata addresses these availability concerns through the tight integration with Oracle Maximum Availability Architecture (MAA) principals. Exadata is able to deliver the highest levels of availability in the industry. Exadata also provides multiple levels of consolidation vs. isolation, so consolidating onto Exadata is not simply an either/or proposition. All of the tools needed to address availability requirements are included in Exadata as we will discuss in later sessions.
Performance of databases does not always mean delivering the highest levels of performance, which Exadata certainly can achieve. The unequaled performance of Exadata is leveraged to achieve greater density in database consolidation environments. Exadata also allows administrators to deliver the appropriate level of performance for the needs of each business application. The level of performance can be easily controlled with Exadata simply by controlling the amount of resources allocated to each database.
Database consolidation and isolation are not mutually exclusive. It is still possible to meet isolation requirements in a consolidation environment. Exadata (on-prem or in the Cloud) includes all of the capabilities necessary to consolidate databases, while still providing isolation where necessary between those databases. The goal is to reduce costs, simplify management, and improve security, while still delivering the needed availability and performance that businesses require. We need to first consider WHY databases need to be isolated, then we will look at HOW we use the tools available on Exadata to provide the needed isolation.
There are 6 factors that govern why databases need to be isolated vs. consolidated within the operating environment as follows:
Physical Location includes placement of databases and systems within certain geographic regions or data centers, as well as within specific sub-divisions of the region or data center, commonly referred to as Availability Domains. Businesses typically require production and disaster recovery systems to be placed in different physical locations. Business needs may also dictate that "local standby" systems reside within a different Availability Domain adjacent to the location of either the production or disaster recovery system. Business requirements may also dictate the physical location of development and test systems. The physical location of a system may also be dictated by location of users, or location of application-tier systems.
Administrative Separation refers to organizations that have multiple DBA teams or other needs to separate databases from an administrative standpoint, such as having different administrators for development, test, and production systems. This is also common in SaaS (Software as a Service) providers, where customers of the service provider have administrative access, or the service provider has separate teams that administer databases for their clients. In either case, multiple administrative teams means those databases need to be isolated from each other administratively.
Security Separation means applying different security controls on more sensitive data, often including the use of dedicated networking to service specific databases (quarantine LAN, etc.). These more sensitive databases are typically subjected to higher security standards such as for regulatory reasons (HIPAA, PCI, PII, etc.). These higher security standards typically raise the cost of these systems, so these databases are typically isolated from other databases for reasons of cost containment. Databases must be isolated from each other in cases where security requirements differ widely between them.
Maintenance considerations include patching and upgrades of servers, databases, and any supporting infrastructure. The biggest concern with maintenance is major version upgrades at the infrastructure layer (O/S, database, etc.), where there is greater potential for functional changes that might impact how services operate, as well as longer potential downtime to perform those upgrades. Maintenance also includes application of individual patches or product updates, which can also impact database availability. Databases or groups of databases therefore need to be isolated from each other for the purposes of maintenance.
Blast radius (or fault isolation) considerations refer to the scope of impact any failure has. Grouping databases together means the scope of impact can be wider and affect more parts of the business. Blast radius is a consideration when consolidating databases into physical servers, virtual machines, or when consolidating databases as Pluggable Databases into Container Databases.
Resource Management refers to ensuring each database receives the resources it requires, as well as guarding against the “noisy neighbor” problem. One approach to resource management is to isolate databases onto dedicated physical or virtual machines, but we recommend to simply use Oracle Resource Manager instead. Exadata automatically manages prioritization of work through the entire stack of system resources, from CPU to I/O, including prioritizing critical I/O requests over non-critical I/O, and prioritizing OLTP over analytics workloads. Exadata also gives administrators control over prioritization through resource plans.
Now that we have established why to isolate databases outlined, there is also the question of how databases are deployed in an isolated manner. With Exadata (either on-prem or in the Cloud), we have 5 options for how to isolate databases as follows:
We recommend a judicious use of ALL these approaches for deploying databases across your Information Technology infrastructure, whether deployed on-prem or in the Cloud. Managers of the infrastructure must determine how and when to isolate vs. consolidate databases. Excessive isolation such as the “one database per virtual machine” approach results in high cost of operation, so we recommend a more balanced approach. Over-use of virtualization leads to what is known as "virtual sprawl" as outlined in the next section.
Data Centers in the past often suffered from sprawl (physical sprawl), where each application and its database(s) ran on their own physical servers. Virtual Machine technology has allowed IT organizations to stem the tide of physical sprawl, but this has often resulted in what is known as virtual sprawl. Increasing compute and storage density has also allowed more workload to be laid on top of the same physical footprint, using virtualization to maintain the same (or even greater) isolation between workloads.
You will quickly build an administrative nightmare and higher costs if each database is deployed on a dedicated Virtual Machine. You can easily meet the needs of your business application users by taking a more judicious approach to deploying databases by using the full range of options at your disposal. The fundamental guidance is to use the right tool for the task such as using Oracle Resource Manager to manage resources.
There is no reason to isolate Oracle Databases simply for the purposes of resource management. Isolate databases for the right reasons, such as for administrative separation, security separation, maintenance purposes, and blast radius, not for resource management. We can easily ensure each database receives the appropriate amount of resources using Oracle Database Resource Manager (DBRM), and deploy systems that are much simpler to manage compared to over-use of virtualization. There are 4 primary resources that need to be managed in any system:
CPU is managed using Oracle Database Resource Manager (DBRM), using shares & limits (or Dynamic CPU Scaling in 19c) inside of a Container Database, Instance Caging (CPU_COUNT) across containers and non-pluggable databases, and within databases using Consumer Groups. DBRM gives us control of ALL types of databases and workloads, and it’s integrated with IORM (see below for detail).
Memory usage for Oracle databases is managed by controlling SGA (System Global Area) and PGA (Process Global Area) settings, which is covered extensively in The MAA Database Consolidation White Paper here.
Processes within Oracle databases are managed by controls for sessions and parallel query servers, which is also covered in the MAA Database Consolidation White Paper mentioned above.
I/O resources are much simpler to manage on Exadata because we have IORM (I/O Resource Manager). Exadata is integrated hardware and software, spanning both compute and storage. Using IORM Objective “auto” allows IORM to inherit the same resource ratios set for CPU in DBRM, so you have one set of controls that handles everything.
See our demo series on Resource Management (starting here) that shows how you can manage resources between pluggable databases, between container databases and non-pluggable databases, and even within databases using Consumer Groups.
Of course we recommend establishing a standardized set of “resource shapes” to choose from rather than making each database a unique and special snowflake. It’s much easier to manage a large population of databases if they all follow some standards, including the resources assigned to them. Using Resource Shapes means you establish shapes with the same ratios for the following resources:
I covered this in detail in the MAA Best Practices white paper on Database Consolidation available here. The white paper includes different allocations for DW vs. OLTP databases, so you’ll see 2 different tables of Resource Shapes. DW systems need larger PGA memory and more processes are devoted to parallel processing than on OLTP systems. You will see those differences in the resource shape tables.
Reducing the “blast area” by isolating databases onto different physical servers or virtual machines doesn’t ELIMINATE the blast (meaning “failure”). What a smaller blast area gives you is pieces that are smaller and easier to fix, simply because they are smaller. Deploying smaller systems as virtual machines reduces the blast area, but is only one piece of the puzzle. In short, reducing the blast area doesn’t necessarily increase availability, but might help in reducing the duration of an outage. Larger numbers of smaller (virtual) systems also increases labor associated with managing those systems, so we still need to consider the full range of tools that ensure systems remain available. We therefore need to focus on the full set of tools available to deliver high availability for Oracle Databases.
Availability is even more important when databases are consolidated. There can still be a “blast” that takes down a database or set of databases, which will impact at least some of your users if not all of them depending on how your application uses that data.
Core HA features of Oracle Database have become something that we almost don’t even consider these days, but are still huge differentiators compared to other databases on the market. Oracle experts often take for granted things like online index rebuilds, online table move, and other features that have been developed over the years. I am often surprised to find other databases haven’t caught up, and some of the newer database engines are still years behind.
Oracle Real Application Clusters (RAC) is still unique in the market after all of these years. We often think of RAC for scalability, but it’s a huge part of the Oracle Database availability solution as well.
Oracle Active Data Guard is the Oracle solution for providing Read Replicas (or “reader farms”), but it’s also a critical part of the Oracle Database availability solution. Active Data Guard provides for availability when a “blast” (failure) occurs, but it’s also used to provide availability during proactive maintenance.
Oracle Application Continuity hasn’t gotten enough press over the past 5+ years, but it’s yet another completely unique capability that Oracle offers. People seem to remember TAF (Transparent Application Failover), but Application Continuity is a completely different animal. TAF required application code changes, while AC has essentially pushed much of that complexity into the SQL driver for Oracle. For more information on Application Continuity see here.
Oracle Database has long exceeded the capabilities of applications, and Application Continuity closes the gap. Applications need to tolerate rolling outages of a RAC Cluster, and Application Continuity is what makes this happen. Application Continuity is implemented through CONFIGURATION changes, not within application code.
The Oracle converged database brings a number of critical advantages for data driven applications compared to point-solution databases. See Juan Loaiza’s talk on Data Driven Apps at OOW London 2019 for a great talk on this topic. Although point-solution databases are sometimes referred to as “best of breed”, many of them don’t live up to that claim. You would suppose a database with a narrow focus might do that job better, but that’s not necessarily the case. The Oracle converged database advantages include:
Data Modeling Flexibility comes from having a single database that provides the full range of data modeling needs. While developers might make the perfect decision and choose the exact point-solution database needed, requirements often change. A development team might choose a relational database, only to find that some data really needs a different modeling approach such as JSON Documents.
While Oracle Databases can be deployed using a SINGLE modeling technique (Relational, Document, Star Schema, Property Graph, etc.) you can also use MULTIPLE modeling approaches within the same Oracle Database. I have worked with data that didn’t fit easily into the relational model, so it’s great to be able to use JSON Documents or another technique that fits better for certain portions of your data model.
Simplified Data Movement comes from using the same Oracle Database on both the sending and receiving side. That data movement is made vastly easier if the data resides with a single shared database, but is easier between Oracle Databases because both databases use the same tools, same drivers, same datatypes, etc. Data movement can be completely eliminated in cases where applications share the same data, such as combined OTLP and Reporting in a single database (yes, this is possible and quite common with Oracle). Data Movement can also be quite costly in Cloud environments, which is another benefit of using Oracle converged database rather than multiple point-solution databases.
Portable Developer Skills are a key benefit of the Oracle converged database, allowing developers to work on ANY application or microservice that uses the same database without extensive re-training. Developers who write analytic or Data Mining code can easily move into a development team working on transactional applications or vice-versa.
Increased Developer Productivity comes from having a common set of interfaces for all databases, regardless of what features are used within each database. Any feature provided by the database represents code that DOES NOT have to be written by a developer.
Any Workload, Any Data includes traditional OLTP and Analytic applications, but also includes Machine Learning, block chain, property graphs, Time Series analysis, Spatial, Internet of Things, and Event Processing. Oracle Database includes robust capabilities in these areas that have been proven over many deployments at customer sites worldwide.
Simplified Consolidation & Isolation comes by having databases that all run the same converged Database. Administrators have the flexibility to isolate databases where needed, or consolidate them to ease the administrative burden as well as to improve resource efficiency. Oracle Databases can even be consolidated into a Container Database, for much greater density and lower cost of operation. Yes, this also applies to Cloud environments, where costs can easily escalate. The bottom line is you simply can’t do this with multiple divergent database engines such as one for Relational OLTP, one for Relational Star Schema DW, one for JSON Documents, etc.
Any Size, Any Scale database or workload can be handled by Oracle Database. It’s amazing to me that other databases haven’t caught up to Oracle after all these years. We still encounter customers who are faced with a database migration (to Oracle) because their chosen database engine simply can’t keep up. Oracle Database is able to easily support databases at least 10X larger than our competitors can handle, and the Exadata platform simply takes that number higher.
There are common business drivers behind database consolidation including the need to reduce costs, simplify information technology, and improve the security posture of the organization. Database consolidation typically raises concerns over the impact on availability and risk to the business that can accompany any consolidation effort. Exadata addresses these concerns by providing benefits in terms of cost, simplicity, and improved security, while still delivering the level of availability that organizations require. The high performance of Exadata can be used to deliver world-class application performance, and can also be used to drive higher consolidation density in order to lower costs. We recommend using the full range of capabilities available to achieve the needed levels of database isolation when consolidating on Exadata, including use of physical isolation, Virtual Machines, Multiple Container Databases, and Oracle Resource Manager to control noisy neighbors. Finally, it is the use of the converged Oracle Database that allows organizations to standardize as well as to consolidate.