Consolidating databases in Oracle systems: Methods and tips
A well-planned consolidation strategy can help overcome Oracle database sprawl. But there are different ways to consolidate your databases, each with pros and cons.
There are hundreds of databases in many Oracle environments, supporting different applications and running on a variety of server platforms. But running all those databases separately makes an environment difficult to manage and secure, which is a good reason to develop a strategy for consolidating databases in your Oracle systems.
That's according to James Olsen, a database and infrastructure solutions architect at Oracle. Olsen spoke about database sprawl and how to combat it via database consolidation in a recent Oracle webinar.
"Today, there's a lot of emphasis on consolidation ... and getting the most bang for your buck [on the use of system resources]," he said.
Database sprawl occurs when a database architecture grows unchecked. Olsen said the ultimate goal of Oracle database consolidation is to keep costs down. That includes both capital equipment costs and operational expenses, which he described as the "care and feeding" of database systems.
In general, Olsen said, the less complicated your systems are, the less time and money you'll end up spending to maintain, support and repair them. "Let's keep this environment simple," he advised listeners.
Three main ways to consolidate databases
Olsen identified three primary database consolidation methods to consider: virtual machines (VMs), dedicated databases and shared databases.
Using VMs involves deploying a large database server and dividing it into smaller virtual ones that isolate the various databases from one another. Virtual machines are a good choice for retaining high levels of isolation while consolidating databases on a single server, Olsen said.
He noted, though, that this approach can introduce more points of management for Oracle database administrators (DBAs) and IT teams. If each database has its own virtual machine, users potentially could find themselves with hundreds -- or even thousands -- of VMs to monitor and maintain.
"It becomes very complex to maintain a virtual machine consolidation environment," Olsen cautioned. Each VM has its own operating system, home directory and database and needs backups for business continuity and disaster recovery, he said. Managing all of them can be taxing and tedious -- not to mention expensive.
One step to help simplify VM deployments is to break them down into groups of similar databases. Olsen also recommended limiting installations to a maximum of five VMs per host server in order to keep processing overhead and costs in check.
Not a panacea for all consolidation needs
Because of the management complexities, VMs typically aren't the only method of consolidating databases that Oracle users will want to employ, according to Olsen. "Virtualization is a tool in our consolidation strategy for isolation," he said. "But virtualization is not the consolidation strategy."
With dedicated databases, a server will run a specific set of databases under a shared OS, Olsen said. Users are then able to take advantage of that server and its resources by adding more databases as needed. This method also works well for isolating databases because it keeps different groups of them in their own servers with no overlaps, he added.
Virtualization is a tool in our consolidation strategy for isolation. But virtualization is not the consolidation strategy.
James OlsenDatabase and infrastructure solutions architect, Oracle
However, there isn't much flexibility in the dedicated databases approach, Olsen said. That can lead to wasted or mismanaged system resources, which, in turn, can hinder the ability to expand databases to accommodate increased processing workloads, he warned. Because of the potential for servers to be either overutilized or underutilized, DBAs should monitor dedicated databases carefully.
Shared databases put different applications into a single database, dividing it up between them -- for example, through the use of session-level schema controls that support multi-tenancy. Deploying many databases on one server allows for more efficient use of the machine from an operating standpoint, Olsen said.
A potential downside that Olsen cited is the databases aren't inherently well isolated from one another. As a result, DBAs need to evaluate how to properly isolate them and keep them secure. "It's not a problem," he clarified. "It's just a piece that we have to think about."
Oracle Multitenant's database consolidation role
Avoiding the need to buy more servers by consolidating databases plays a big role in keeping overall costs down in Oracle systems. "If we can do more with the equipment we have ... then we don't have to put as much resources behind it to get to the same environment and the same processing as we would without this type of consideration," Olsen said.
A good way to optimize your system's performance as part of a database consolidation strategy is to use the optional Oracle Multitenant architecture, Olsen advised. Oracle Multitenant, which was introduced with Oracle Database 12c in 2013, allows users to run multiple pluggable databases that hold data and look separate to applications inside a multi-tenant container database for easier management and administration. The pluggable databases use the same CPUs, memory structures and background processes, and DBAs can easily add new databases and clone and delete them as needed.
Using Oracle Multitenant reduces both overhead costs and CPU consumption while also helping memory to run more efficiently, Olsen said. And because many databases can be managed as part of one unit, maintenance work is reduced, as are potential intrusion points into systems.
