cancel
Showing results for 
Search instead for 
Did you mean: 
sai_mukundan
Level 4

Storage Foundation provides the ability to consolidate Oracle databases to increase server utilization, simplify database infrastructure and reduce operational costs. This white paper provides an overview of the Cached Oracle Disk Manager (CODM) capability of Storage Foundation to achieve these business objectives.

Introduction

Moore's Law states that the number of transistors on a chip will double approximately every two years. The traditional technology refresh cycle of enterprises has the net effect of ever-faster processors entering the data center on a regular basis. However, the potential benefits of energy efficiency and reduced footprint yielded by the newer servers will be realized only at relatively high levels of server utilization. The impact of these benefits is an issue solely from an economic perspective. Energy costs increase as a percentage of datacenter spend and this increase is compounded by increasing energy costs. Consolidation onto a decreased number of servers is vital to increasing server utilization and realizing the predicted return on investment of the technology refresh process. More recently, in these tighter times, companies have been laboring to pare IT infrastructure costs. Even as they do so, they are expected to maintain or improve service quality.

Oracle Databases are a major component of providing such high service levels for many enterprise applications and constitute a big portion of the operational IT budget in terms of personnel and hardware.  Therefore, the consolidation of databases and database servers is becoming a priority for many organizations. Database consolidation refers to running multiple databases on a single server. Because databases are characterized by large memory and I/O throughput requirements, it is imperative that the underlying infrastructure is capable of hosting multiple database instances that were previously hosted across many underutilized servers. In addition, most database systems are designed for peak or worst-case scenarios since it is difficult to provide elasticity in both compute and storage capacity to meet the varying demands of database workloads. Cached Oracle Disk Manager is applicable in such workload environments and helps consolidate Oracle databases while maintaining the ease of management and operation. Such smart improvements in the efficiency of database management without comprising service levels can yield fast economic returns to build credibility with business users and senior management.

Audience

This article is applicable to those interested in leveraging the benefits of greater CPU and memory horsepower available in today’s servers to simplify Oracle database infrastructure and to manage operational costs.

Technology Overview

Oracle Databases can be characterized as having the following characteristics: large memory footprint, high physical I/O, high throughput to satisfy a large number of concurrent users, deterministic workloads that generally do not fluctuate beyond certain boundaries, and High Availability (HA). Given these characteristics, database servers are therefore configured with large memory, optimized storage, high end processors, and an HA architecture. When looking at consolidation of such Oracle databases, three phases are involved:

  1. The first phase is the data collection phase which requires an inventory assessment of all servers, databases and applications. It is useful to understand historical server utilization and database workload trends. This will map out systems which may be heavily loaded during daylight hours due to database Online Transaction Processing (OLTP) workloads and systems which run data warehouse workloads that may be more active during overnight batch processing times.
  2. The second phase of consolidation involves an analysis of the phase one data to determine consolidation ratios. Consolidation greatly depends on the available memory levels in a system to accommodate database memory requirements. It is also useful to consolidate databases that have peak infrastructure requirements at different times.
  3. The third phase involves the actual process of consolidating the Oracle databases.   

In order to effectively follow such a phased consolidation approach, it is important to understand Oracle database memory requirements that will clearly highlight the benefits of Cached Oracle Disk Manager. Each Oracle database instance has a System Global Area (SGA) dedicated to hold information related to Oracle processes. The SGA is used to store incoming data and internal control information that is needed by the database. There are three main areas associated with the SGA - Buffer cache, Shared pool, and Redo log buffer. The Buffer Cache is where Oracle stores data blocks. The shared pool is used to hold SQL executable code and the log buffer specifies the amount of memory that Oracle uses when buffering entries to the log files. Typically the aggregate Oracle SGA gets sized to consume most of the available memory in a system. However, the drawback is that these SGA sizes cannot be dynamically changed to accommodate the varying memory demands of the consolidated databases. With CODM, the memory available in a system can be used across all databases. Think of it as secondary SGA. Thus, it is possible to stack more instances per server because the memory can be dynamically allocated as the aggregate workload varies over time. The result is higher throughput, leading to increased server utilization and better mixed workload performance since CODM can be enabled for specific Oracle database files that will benefit from this technology.

Figure 1 below details the benefit of Cached Oracle Disk Manager for Oracle database consolidation. Note that the size of the server in the picture is intended to depict the server horsepower.

  

Figure 1: Database consolidation (before and after scenarios)

Result – Reduce TCO

The cost reduction is achieved through an increase in the physical server utilization and a corresponding reduction in the number of physical servers required while still meeting existing service levels. The reduction in the number of physical servers can in turn lead to a reduction in aggregate infrastructure management and energy costs. Also, there are potential cost savings from an Oracle Database licensing perspective as well. Oracle Database can be licensed by physical CPU or user count. With database consolidation, fewer processors are needed to run the given database workload thereby reducing the Oracle licensing cost. However, reducing the number of database servers may not necessarily reduce the total Oracle license cost because newer licensing models from Oracle charge on a per-core basis with a premium for more powerful processors. In that case, consolidation aims to minimize the overall Oracle database license cost by combining all low user count databases onto a single physical server and then licensing this server by maximum user count. Another way that the TCO can be reduced is through optimal alignment of all the additional Oracle database license options that are needed across the various databases. An example of such a strategy will be to consolidate all database instances that need the Oracle partitioning option on one server, instead of having to license partitioning for multiple servers.

Cached Oracle Disk Manger was introduced in Storage Foundation 5.1 release and supports Oracle 10gr2, 11gr1 and 11gr2 database versions. For more information about Symantec Storage Foundation and Availability products, please visit go.symantec.com/ha.

 

Resources

Database Management and High Availability

Cached Oracle Disk Manager: Usage Guidelines and Best Practices

 

Written by: Sai Mukundan, Senior Product Manager, Symantec Storage and Availability Management Group

Copyright © 2011 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.

Version history
Last update:
‎12-19-2011 09:31 AM
Updated by: