Select Journal - First Quarter 2013 - (Page 33)

A Multilayered Approach to Oracle Database Availability By Tom Sager Edited by Arup Nanda N ot too many years ago, there were few choices to be made when it came to deploying critical Oracle Database servers. Physical servers were purchased, usually highend RISC UNIX boxes, and some manner of clustering and/or log shipping was implemented to provide for availability. Today, there are many more choices available to an IT organization when it comes to Oracle infrastructure, mostly due to the rise of Intel architecture in this space and its ability to provide the level of performance that was once strictly the domain of high-end servers. This new world of choices has also opened the door to new ideas and new ways of thinking about old problems. One such new idea is a reconsideration of high-availability (HA) and disaster recovery (DR). HA and DR the Oracle Way RAC has been the first choice for high-availability for years now, and it is high-quality software that does an exceptional job. However, it comes at a high price, including: • Licensing costs • Infrastructure needs (storage and networking far beyond what you can get by with on a standalone non-clustered database server) • Labor (far above and beyond what it takes to support non-RAC databases) Data Guard is most often considered as a solution for DR rather than HA. However, it does provide for automatic Fast-Start Failover via the observer role feature. The issue with implementing this is the need for a third location for the observer, in addition to robust, reliable networking among all three nodes. Oracle’s recommendation for a combined HA/DR environment is RAC in two different data centers and Data Guard between them (refer to their MAA white papers). This is certainly a workable approach, but it’s also an expensive one. Another approach is to configure four physical servers (two in each location), with one primary and three standbys. One of the standbys (in the opposite location from the primary) can also have the observer installed. In this manner, HA is implemented in the local data center via Data Guard Fast-Start Failover while DR redundancy is maintained via additional standby servers (two in this example, because HA redundancy will be needed at the DR site should it ever become primary) in the alternate data center. Most would consider this approach overly complicated and somewhat wasteful of resources, but it does save the expense of RAC licenses. The Rise of Database Server Virtualization It has always been a struggle to find the “sweet spot” between cost, complexity and functionality for Oracle Database HA and DR. Adding to the cost component is the fact that the number of cores per processor has been steadily increasing (especially Intel architectures), from two, to four, and now to six and eight. Since Oracle is licensed by core, there are significant ramifications to license costs as databases make their way to these new multicore architectures. The Intel multicore growth is commonly a deciding factor when organizations start making the move to virtual servers. When this move is made, Oracle licensing is “moved up” to the physical host level, allowing for the provisioning of as many virtual Oracle Database servers as the hosts can support. If managed carefully, this approach is a very effective way to get maximum utilization out of the physical servers. Once this migration is under way, some important added benefits beyond license management become evident: • • • • • Automatic hardware HA Virtual switch networking Load balancing Very fast server reboots Dynamic resource provisioning (CPU, memory, disks can all be added “on-the-fly”) • Very quick and easy server deployment (server templates) This paper is not about the merits of virtualization for Oracle Database servers, so details on the above points will be omitted. They are mentioned here because they have a bearing on how and why new approaches to Oracle HA and DR might be considered. Subject matter experts should be consulted to discuss and verify these aspects of the specific virtualization technology implemented in an organization. For the purposes of this paper, VMware© server virtualization is assumed. New Storage Options Most organizations have been using storage area networks (SAN) for their database storage for years now. One feature that most SANs offer is storage replication. This is often a hardware-level feature, licensed by amount of data being replicated. So although it is neither a new option nor a free one, its deployment against virtual servers opens up new possibilities. In the VMware world, a virtual machine (VM) server is completely contained in a physical “datastore” (there are other options, but this is the default). Thus, the entire server (OS, DB kernel, DB, logs, etc.) is contained in a small collection of files in a single folder. Each folder represents a distinct server and is itself contained in a datastore (which can loosely be thought of as the VMware counterpart to the SAN LUN). continued on page 34 1st Qtr 2013 ■ Page 33

Table of Contents for the Digital Edition of Select Journal - First Quarter 2013

Select Journal - First Quarter 2013
Table of Contents
From the Editor
From the IOUG President
Enterprise Manager 12c Cloud Control: What’s Changed, What’s New
Introduction to Oracle Enterprise Manager Command Line Interface
Users Group Calendar
Retrieving Large Volumes of Data
A Multilayered Approach to Oracle Database Availability
Advertisers’ Index
Ask an Oracle ACE

Select Journal - First Quarter 2013