Oracle Consulting Oracle Training Oracle Support Development
Oracle Books
SQL Server Books
IT Books
Job Interview Books
Rampant Horse Books
911 Series
Pedagogue Books

Oracle Software
Write for Rampant
Publish with Rampant
Rampant News
Rampant Authors
Rampant Staff
Oracle News
Oracle Forum
Oracle Tips
Articles by our Authors
Press Releases
SQL Server Books

Oracle 11g Books

Oracle tuning

Oracle training

Oracle support

Remote Oracle


Privacy Policy



Oracle Server Consolidation

It is ironic that the old mainframe architectures of the 1970ís and 1980ís are now brand new again. Back in the days of data processing, it was not uncommon for a single server to host a dozen databases.

The advent of the inexpensive Itanium2 servers is leading the way back to server consolidation.  There was nothing inherently wrong with a centralized server environment, and in many ways it was superior to the distributed client-server architectures of the 1990ís.

When companies first started to leave the mainframe environment, it was not because there were particular benefits to having a number of tiny servers.  Instead, it was a pure economic decision based on the low cost of the UNIX-based minicomputers of the day.

These minicomputers of the 1980ís could be purchased for as little as $30k which was a bargain when compared to the three million dollar cost of a mainframe. As minicomputers evolved into the UNIX-centric Oracle servers of the 1990ís, some shops found themselves with hundreds of servers, one for each Oracle database.

In fact, the break down of the mainframe was a nightmare for the Oracle DBA.  Instead of a single server to manage, the DBA had dozens or even hundreds of servers, each with its own copy of the Oracle software.

The 1990ís was the age of client/server computing, where multi-tiered applications were constructed with dozens of small servers.  Systems might have been comprised of a Web server layer, an application server layer, and a database layer, each with dozens of individual servers as shown in Figure 12.8.


Figure 12.8:  The multi-server Oracle architectures of the 1990ís


The example in Figure 12.8 shows a multi-server architecture that employs Oracle Real Application Clusters (RAC) which is a processing architecture that allows multiple Oracle instances on separate servers that access a common Oracle database.

One of the issues associated with single server Oracle systems was the deliberate over-allocation of computing resources. Each system would experience periodic processing spikes, and each server had to be equipped with additional resources to accommodate the irregular frequency of the demands of various applications. This led to a condition in which Oracle servers had unused CPU and RAM resources that could not be easily shared.

The client/server Oracle paradigm had many serious problems:

  • High Expense: In large enterprise data centers with many servers and many instances, hardware resources must be deliberately over-allocated in order to accommodate the sporadic peaks in CPU and RAM resources.
  • High Waste: Since each Oracle instance resides on a separate single server, there is a significant duplication of work which results in sub-optimal utilization of RAM and CPU resources.
  • Very Time Consuming for the Oracle DBA: In many large Oracle shops, a shuffle occurs when a database outgrows its server. When a new server is purchased the Oracle database is moved to the new server, leaving the older server to accept yet another smaller Oracle database.  This shuffling consumes considerable time and attention from the DBA.

This waste and high DBA overhead has lead IT managers to recognize the benefits of a centralized server environment, and there is now resurgence in popularity of large monolithic servers for bigger Oracle shops.  There is also a rapid depreciation rate for servers, which has also contributed to the movement towards server consolidation.  For example, three year-old Oracle servers that cost over $100k brand new are now worth less than five thousand dollars.

These new mainframes may contain 16, 32, or even 64 CPUs and have processing capabilities that dwarf the traditional mainframe ancestors of the 1980s.  These new super-servers are capable of blistering performance, and a recent UNISYS benchmark exceeded 250,000 transactions per minute (TPM) on a Windows based server using Oracle10g and nearly a million TPM on large Linux servers.  The new Oracle10g benchmarks of server performance make use of many of the new features of Oracle including:

  • Multiple blocksizes
  • 115 gigabyte total data buffer cache
  • 78 gigabyte KEEP pool 
  • 16 CPU Server - Each a 64-bit Itanium 2 Processor

There are those who argue that it is not a good idea to throw everything onto a single server because it introduces a single point of failure.  Even Oracle Corporation says that itís not a good idea to place all of the our eggs in one basket; therefore, they advocate the grid approach in Oracle10g.

Many of these concerns are unfounded.  In reality, these large systems have redundant everything, and with the use of Oracle Streams for replication at different geographical locations, they are virtually unstoppable.

In the new server architectures, everything from disk, CPU, RAM, and internal busses are fully fault tolerant and redundant which makes the monolithic approach appealing to large corporations for the following reasons:

  • Lower costs - Monolithic servers are extremely good at sharing computing resources between applications, making grid computing unnecessary.
  • Lower Oracle DBA maintenance - Instead of maintaining 30 copies or more of Oracle and the OS, DBAs only need to manage a single copy.

Cost savings aside, there are other compelling reasons to consolidate Oracle instances onto a single server:

  • Oracle server consolidation: Server consolidation technology can greatly reduce the number of Oracle database servers.

  • Centralized management: A single server means a single copy of the Oracle software. Plus, the operating system controls resource allocation and the server will automatically balance the demands of many Oracle instances for processing cycles and RAM resources. Of course, the Oracle DBA still maintains control and can dedicate Oracle instances to a single CPU thereby utilizing processor affinity or adjust the CPU dispatching priority using the UNIX nice command.

  • Transparent high availability: If any server component fails, the monolithic server can re-assign the processing without interruption. This is a more affordable and far simpler solution than Real Applications Clusters or Oracle DataGuard, either of which requires duplicate servers.
  • Scalability: Using a single large server, additional CPU and RAM can be added seamlessly for increased performance.
  • Reduced DBA workload: By consolidating server resources, the DBA has fewer servers to manage and need not be concerned with outgrowing server capacity.

So, what does this mean to the Oracle DBA? Clearly, less time will be spent installing and maintaining multiple copies of Oracle.  This will free time for the DBA to pursue more advanced tasks such as the SQL tuning and database performance optimization in this look.

Following this information on the impact of the new server environments for Oracle, it is logical to look at the overhauled Oracle Enterprise Manager and see how it now displays AWR server-side metrics.



This is an excerpt from my latest book "Oracle Tuning: The Definitive Reference". 

You can buy it direct from the publisher for 50%-off and get instant access to the code depot of Oracle tuning scripts:




 Copyright © 1996 -2017 by Burleson. All rights reserved.

Oracleģ is the registered trademark of Oracle Corporation. SQL Serverģ is the registered trademark of Microsoft Corporation. 
Many of the designations used by computer vendors to distinguish their products are claimed as Trademarks