|
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
- 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:
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.
SEE CODE DEPOT FOR FULL SCRIPTS
 |
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: |
http://www.rampant-books.com/book_1002_oracle_tuning_definitive_reference_2nd_ed.htm
|
