If you have struggled with scaling database services, you're not alone. For some database administrators, dedicated database deployments have them at a breaking point. For others, schema-based shared deployments have had limited success. Well, relief is here. Oracle Database 12c
The success of more than two decades of database deployments has created an IT dilemma -- a lot of databases and an increasing total cost of ownership (TCO). The proliferation of databases, sometimes referred to as database sprawl, is expensive and difficult to manage. To reverse this trend, you must move to a multitenant database deployment model by consolidating databases.
Oracle database consolidation reduces the number of databases, effectively pooling database resources. Figure 1 shows how.
Don't confuse database consolidation with server and storage consolidation. Server consolidation -- implemented as operating system virtualization -- and storage consolidation -- implemented as shared storage -- put the same number of databases on fewer physical servers and storage systems. Database consolidation actually reduces the number of databases.
The benefits are lower cost, reduced complexity and increased efficiency. Fewer databases sharing resources increase utilization, in turn requiring less infrastructure and management. Less infrastructure lowers costs for software licensing, hardware and data center facilities. Fewer databases and less infrastructure are easier to manage, saving operational costs. Administrators spend less time on system management and more time on application management. Ultimately, the business realizes these benefits as improved service and speed to market at a cheaper cost (see Figure 2).
To understand Oracle database consolidation, let's simplify the architecture to its basic construct, the database server. A database server has at least one instance and a database. An instance includes memory structures and processes running on a node, which manages physical data files. Oracle can be architected as a single instance or a multi-instance cluster referred to as a Real Application Cluster (RAC). A database is physical data files residing on storage media, i.e., solid state or spinning disk, shared among one or more instances. Data files include application data, control files and redo logs, as shown in Figure 3:
Remember, the goal of Oracle database consolidation is to reduce the number of physical database servers. There isn't just one deployment model to achieve this. In fact, most organizations will probably employ several different models to maximize consolidation density. There are a number of consolidation levers that shape your models: service-level agreements (SLAs), line of business (LOB), applications, software development lifecycle (SDLC) environment, database version, database character set, Oracle options, workloads and so on. Practically speaking, one should not expect to end up with a single database in each consolidation target:
For most databases, consolidation makes sense. However, Oracle database consolidation is not a good fit for all applications. Here are some guidelines for when to isolate an application or limit consolidation:
- Third-party applications where you can't control the database version, operating system or platform
- Applications requiring nonstandard char/code sets
- Database sizes that reach server constraints such as CPU, memory or administrative time windows
- Applications with performance requirements that necessitate dedicated resources
Oracle database consolidation implies multi-tenancy. Database multi-tenancy is an architecture in which a single instance of a database serves multiple customers. Each customer is called a tenant. Tenants are logically isolated, but physically integrated. In a typical multi-tenant database, tenants that do not share or see each other's data share the same database while running on the same operating system, using the same hardware and storage system. In cloud computing, a database-as-a-service (DaaS) provider, for example, can run one instance of its database and provide access to multiple customers.
Oracle 12c's multi-tenant option is a high-density Oracle database consolidation platform implemented as a single multi-tenant container database (CDB) and many pluggable databases (PDBs). The operating system views a physical CDB as the database while customers or tenants view a virtual PDB as the database. A container database provides the ability to manage many pluggable databases as one. Pluggable databases share the instance Figure 5 shows SGA memory and background processes of the container database while retaining security, isolation and resource control of separate databases:
In-database virtualization simplifies consolidating databases onto the cloud. The major benefits of reduced cost and complexity along with increased efficiency are the results of fewer physical databases, higher density and lower operational overhead. Best of all, moving to Oracle multi-tenant is straightforward, requiring no changes to applications. You'll need to be on Oracle 12c, pay an additional license cost and migrate your databases to "pluggable" databases. Then applications will be ready to go.
About the author:
Jeff McCormick is an IT senior principal at a major health service company and former president of the Connecticut Oracle User Group. Jeff has worked in IT for more than 20 years as a data and infrastructure architect/administrator, focusing the last 5 years in enterprise business intelligence and information management.
This was first published in February 2014