Achieving Oracle Database
Scalability using SharePlex
Complement or replace RAC with enterprise-class database replication technology.
Written by Sujith Kumar, Chief Technologist, Dell Software
Introduction
Users demand high performance, but databases are constrained by hardware limits.
Due to the so-called “Google effect,” users have come to expect rapid response from applications, and that demand for performance trickles down to the underlying databases. But the hardware supporting traditional relational databases has a finite limit in terms of system resources: hardware resources such as CPU, memory, network and storage have a vertical scalability limit.
Oracle RAC enables IT organizations to scale horizontally using cheaper hardware—but it is costly.
To help, Oracle introduced Oracle Parallel Server (OPS) in
servers. Specifically, RAC supports seamless deployment of one or more servers accessing the same database within the same cluster, providing fault tolerance, high availability and horizontal scalability within the same data center. However, RAC has important drawbacks, including platform options, geographical availability and, most importantly, cost.
SharePlex delivers cost-effective database replication that overcomes RAC’s shortcomings.
This tech brief offers a better option: SharePlex from Dell Software. SharePlex is an enterprise-class logical database replication technology that allows data to be replicated between databases in the same data center or across data centers with no distance limitations. With SharePlex, IT
RAC requires
specialized and
expensive hardware,
not only for the
servers but also for
the network and
storage layers.
This tech brief is aimed towards Oracle DBAs, disaster recovery and high availability (DR/HA) architects, and application architecture architects responsible for engineering, creating and managing application infrastructure stack interested in achieving highly available and scalable Oracle databases focusing on data replication needs at the same time. It assumes readers are familiar with Oracle database technology and Oracle RAC and that they have a rudimentary understanding of data replication options.
Why consider RAC?
Traditionally, the only option available to IT organizations facing increasing database size and load was to scale vertically. Vertical scaling involved investing in expensive proprietary hardware. With the release of Oracle 9i in 2001, Oracle unveiled the re-invigorated and re-designed version of Oracle Parallel Server (OPS) called Oracle Real Application Cluster. Oracle RAC enables transparent and concurrent access to a single database by multiple servers, each with its own independent instance, thereby providing fault
tolerance, high availability and aff ordable horizontal scalability. RAC is included as part of the Oracle Standard Edition database license, and RAC is considered a paid add-on with Oracle Enterprise Edition database.
Benefi ts of RAC
• Scalability—RAC allows seamless horizontal scaling by enabling transparent deployment of servers into a cluster that supports user and data growth.
• Availability–Since multiple instances running on diff erent servers are accessing the same database, the database itself is impervious to server and network failures; the user workload gets shifted from the failing or failed node to one of the other surviving nodes. This is accomplished using RAC technologies such as Single Client Access Name (SCAN), Transparent Application Failover (TAF) and Failover Application Notifi cation (FAN).
• Load balancing–Since there is more than one node within a cluster, workloads can be distributed across multiple servers, thereby optimizing system resources. • Consolidation–The shared-everything
architecture of RAC allows for
consolidation of disparate databases within the same cluster, enabling better utilization and scheduling of system resources based on the needs of the diff erent databases.
Drawbacks of RAC
• Single point of failure (SPOF)—Oracle RAC’s shared-everything architecture makes the database a single point of failure. If the RAC experiences a storage failure, it will stop working and cause the whole database to fail. Moreover, all the instances and the database within a given RAC are orchestrated by Oracle Clusterware, which constitutes another SPOF.
• Downtime during upgrades—Since all the instances in RAC are accessing the same database, downtime is required for upgrades to the database server (such as hardware changes, operating system upgrades, Oracle upgrades, storage replacement and application upgrades). The rolling upgrades features in Oracle 10g, 11g and 12c support only minor version upgrades of the Oracle binaries in RAC instances.
• Geographic limitations—All the nodes in a cluster must be hosted in the same data center. This is a requirement since all the nodes will have to be connected to each other using expensive network interconnects such as GigE or Infi niband network interfaces. RAC supports extended distance clusters (that is, clusters across data centers); however, the maximum distance between data centers is 100 kilometers. For longer distances, Oracle recommends using Oracle Data Guard between the source and target data centers. • Performance limitations—RAC allows
the same workload distribution across multiple nodes within the cluster. However, because all the instances are accessing the same database, there is no way to tune each instance or node for a diff erent type of workload, such as online transaction processing (OLTP), data mining or reporting.
SharePlex from
Dell Software is an
aff ordable logical
replication solution
that can either
complement Oracle
RAC or completely
replace it.
• Platform limitations—RAC does not support heterogeneous hardware within the same cluster, such as a mixed platform of a combination of HP-UX, Oracle Solaris, IBM AIX or Linux x86 servers. A cluster also cannot span multiple versions of Oracle, such as 10g, 11g and 12c.
• Costs—Due to its shared-everything architecture, RAC requires specialized and expensive hardware, not only for the servers but also for the network and storage layers. It also requires an additional highly skilled IT professional to implement, manage and maintain it. Furthermore, Oracle charges an additional licensing fee for the RAC add-on when it is used with Oracle Enterprise Edition database.
The cost-eff ective
alternative: SharePlex
SharePlex from Dell Software is an aff ordable logical replication solution that can either complement Oracle RAC or completely replace it. Easy to use and manage, SharePlex can help IT organizations achieve horizontal scalability by providing one or more real-time copies of the production RAC or single-instance databases with no distance limitations.
SharePlex has been a leading database replication product since 1998 and boasts a global customer base. In its November 2012 report, Worldwide Database Development and Management Tools 2011 Vendor and Segment Analysis (Doc #237963), IDC
placed SharePlex as the #1 third-party database replication solution, with over 19 percent of the database replication market compared to Oracle’s native tools at 25.5 percent (inclusive of GoldenGate, Data Guard, Active Data Guard and Oracle Streams).
What is SharePlex?
SharePlex is an aff ordable, easy-to-use logical data replication solution for Oracle databases. It provides a real-time copy of production data without impacting the primary database’s performance and availability.
The data is replicated from the source database to one or more target database servers. SharePlex runs continuously on the database server itself, replicating data in real time with sub-second latency and no perceivable impact on the source database performance. On the source database, the transactional data changes are captured directly from the Oracle redo logs or archive log fi les using a proprietary capture mechanism. Applications are able to access multiple copies of the database seamlessly—an analogue to receiving e-mails in desktop Microsoft Outlook client and mobile devices simultaneously. SharePlex can replicate the database in its entirety or can be limited to specifi c schemas, tables, columns or rows within tables. It also has the ability to modify or transform replicated data on the fl y prior to posting it to the target database.
Figure 1. SharePlex captures changes to the source database and keeps the replica in sync in real time.
Source Export queue Capture queue Post queue SQL Target Cloud target Export Import Capture Read Post Post Redo/archive logs
How does SharePlex work? SharePlex operates on both source and target database servers. It spawns capture, read and export processes on the source database server, and import and post processes on the target database server. The capture process scans the Oracle redo logs for any changes to the data and captures the changes. If necessary, the capture process has the ability to scan the archive logs instead of the online redo logs. The read process prepares the data to be transported across the network after processing it and hands it over the export process. The export process transports the data to one or more target database servers via TCP/IP across the LAN or WAN.
On the target database server(s), the import process intercepts the TCP/IP packets and process the data received from the source database server and hands it over to the post process. The post process constructs SQL statements for the DML operations based on the data changes observed on the source database and executes them by connecting to the target database(s). SharePlex also has the ability to encrypt and compress the data while being transported across the network to enhance security and performance. High throughput and resiliency is achieved by transmitting the data in memory under ideal circumstances. Organizations that need fault tolerance and high availability can persist the data in proprietary disk-based queue fi les.
Benefi ts of SharePlex
SharePlex off ers some of the same benefi ts as Oracle RAC while eliminating its drawbacks:
• No single point of failure (SPOF)–As we saw, with RAC, if the database goes down, the entire cluster will fail. SharePlex eliminates this single point of failure by creating one or more replicas of the database; if the database goes down, you can simply fl ip the users or the application to a copy of the database with no downtime.
• Optimization for diff erent workloads– RAC allows for the same workload to be distributed across various nodes operating within the same cluster and does not allow disparate workloads to be run on diff erent nodes. SharePlex maintains multiple copies of the same database in real time, so each replica database can be customized for diff erent workloads. For example, even if the main source database is optimized for online discrete transactions, you can optimize a replica for reporting by creating a diff erent set of indices that will run reports and queries more effi ciently. • Geographic fl exibility–As noted earlier,
RAC cannot span data centers over long distances. SharePlex, on the other hand, uses TCP/IP to communicate between data centers via LAN/WAN with no distance limitations, thereby reducing the total cost of implementation.
• Heterogeneous platform & version support–Oracle RAC requires homogeneous hardware architecture and all nodes must run the same version of Oracle. Since SharePlex is agnostic with respect to operating system, CPU architecture and database version, it can support any mix of operating system and database versions, including Oracle 9i to Oracle 12c. Replication between Oracle Enterprise Edition and Oracle Standard Edition is also supported.
• ZeroIMPACT upgrades & migrations–As we saw, rolling upgrades in RAC are limited, and schema object changes, network or storage infrastructure upgrades, and application upgrades require downtime. Since SharePlex maintains two or more distinct copies of the same database, it can fully support all types of upgrades and migrations with near zero downtime. You can upgrade the operating system, storage and network infrastructure, servers, databases and applications with no impact to your applications or users.
• Database consolidation–A single implementation of RAC allows multiple databases to run on the same node, sharing the same storage, so if the storage fails, all the databases will become unavailable. SharePlex allows you to consolidate databases on the same node using diff erent storage mount points. This eliminates
With RAC, if the
database goes
down, the entire
cluster will fail.
SharePlex eliminates
this single point
of failure by
creating one or
more replicas of
the database; if
the database goes
down, you can
simply fl ip the users
or the application
to a copy of the
database with no
downtime.
the single point of failure: even if one of the storage mount points fails, the other databases and the associated instances running on a given node will continue to function. Moreover, since the database can be replicated to more than one node at the same time, total failures are prevented. • Reduced costs–As noted above, RAC
requires specialized and expensive hardware. SharePlex, on the other hand, can run on low-cost or re-purposed hardware, allowing it scale horizontally at an aff ordable cost. You can add new commodity servers without incurring the cost of replacing the existing more expensive and older servers, so you can scale up more cost eff ectively.
• Load balancing– Since all the nodes within a RAC access the same physical databases, even though the user load can be spread across multiple nodes, the users access the same database, which will end up being a bottleneck at some point. With SharePlex, the database and its replica(s) can be set up in multi-master or bi-directional replication mode, so you can spread the user load across multiple databases and also across multiple data centers.
How SharePlex complements RAC In IT organizations where Oracle RAC has been implemented and is an integral part of the enterprise, SharePlex can overcome some of the shortcomings of RAC at a much lower cost. By providing one or more copies of the primary database on separate servers within the same data center or across data centers, SharePlex:
• Provides a shared-nothing architecture that eliminates the single points of failure discussed above
• Supports replication to and from a virtually unlimited number of nodes using the cascading confi guration, overcoming Oracle 11gR2’s limitation restricting each RAC implementation to a maximum of 100 nodes
• Eliminates geographic limitations by removing RAC’s distance limits
• Supports multiple operating system types, CPU architectures (x86, x64, SPARC and RISC) and database versions
• Enables you to take advantage of new
failover technologies, such as FAN and TAF, without re-writing application logic,
unlike RAC, which requires application modifi cation
What about Oracle Standard Edition? Small to medium size companies often implement RAC as part of Oracle Standard Edition. They therefore face certain limitation, including the number of CPUs in a server, that SharePlex can help them overcome.
SharePlex will also help create low-cost Oracle Standard Edition deployments that can be used for development and testing without incurring additional cost overhead.
How organizations are using
SharePlex today
Overview
Organizations use SharePlex for a wide range of purposes. Here are a few examples on how some customers use SharePlex in a RAC environment. Case study 1: Dell IT: Siebel 10g to 11g database migration
Dell needed to migrate a 10TB business-critical database running a Siebel application from Oracle 10g RAC to 11g RAC. The application served both internal users and 22,000 customers worldwide, so it required 99.99% uptime—only 4.38 hours of annual downtime were available for maintenance and upgrades. To upgrade the database while
minimizing downtime, IT staff followed this procedure:
1. RMAN was used to perform the initial copy of the 10g database from the old hardware to the new hardware. Since Linux was the operating system on both the old and new hardware platforms, the OS was not a concern.
2. SharePlex was installed on both source and target servers and was confi gured to capture data on the source while the post or apply process on the target server was stopped and the transactional data was allowed to queue up on the target server.
In IT organizations
where Oracle
RAC has been
implemented,
SharePlex can
overcome some of
the shortcomings
of RAC at a much
lower cost.
3. Oracle Data Guard was established between the source 10g database and the target 10g database running on the new hardware platform. Once Data Guard caught up with the logs, it was stopped and the database was recovered. At the time of database recovery, the SCN number of the last transaction was noted and the 10g database on the new server was upgraded to 11gR2.
4. The transactions in the SharePlex queue were reconciled (duplicate transactions were eliminated from the queue) to the SCN noted in the earlier step, and the remaining data was applied to the new database.
5. Once the SharePlex queue was empty, the 10g and the 11g database were considered to be in sync and users were switched over to the new 11g database.
Reverse replication from Oracle 11g to 10g was confi gured as a failback option, in case it would be required.
The Dell DBA team summarized the benefi ts of using SharePlex for the migration as follows:
• SharePlex allowed the migration and upgrade to be completed six weeks ahead of schedule, and allowed enough time for extensive testing.
• The team was able to reclaim 1.2TB of storage space in the 11g environment by performing archive/purge. They paused SharePlex during the archive/purge process and restarted it after the process was complete.
• The project resulted in an improved user experience.
• SharePlex enabled the team to test multiple environments in the new platform with no downtime.
One team was able
to reclaim 1.2TB of
storage space in an
11g environment
by performing
the archive/
purge during the
migration.
Figure 2. SharePlex migration with reverse replication for failback, if required
Figure 3. Using SharePlex active-active replication across multiple data centers
10g, 4-node RAC, RedHat Linux 4, Siebel application 11g, 5-node RAC, RedHat Linux 5, Siebel application
Case study 2: Horizontal scaling with HA & DR options
A Dell customer has multiple data centers spread across the U.S., with multiple RAC implementations at each data center. However, the limitation of RAC make it impractical, if not impossible, to link the RAC implementation in each data center either to work in tandem to service the user load or to be confi gured in HA/DR mode.
Using SharePlex in active/active replication confi guration mode, the customer was able not only to scale horizontally within the same data center but also to have each data center act as HA/DR for the others. The confi guration of data replication between multiple data centers using SharePlex is shown in Figure 4.
In addition to providing the HA/DR functionality, SharePlex replication also enabled application, OS and Oracle version upgrades with near-zero downtime.
Case study 3: Peer-to-peer replication using RAC
A well-known e-commerce company uses SharePlex to replicate data between two RAC databases residing in two diff erent data centers. One of the RAC environments has two databases for processing transactions and queries from booking agents, direct channels and online customers supporting the fi rst product off ering. The second RAC environment has another two databases for handling transactions and queries from booking agents, direct channels and online customers supporting a second product off ering.
Using SharePlex
in active/active
replication
confi guration mode,
the customer was
able not only to
scale horizontally
within the same
data center but also
to have each data
center act as HA/DR
for the others.
Figure 4. SharePlex peer-to-peer replication using a RAC confi guration
Figure 5. RAC replicating to reporting single instance
RAC 1: Airline reservations RAC 2: Hotel reservations
Data center 1 Target 1: Billing (internal users) Target 2: Reporting (external users) Data center 2
Using SharePlex peer-to-peer replication, the customer has been able to offl oad querying and report processing to the least loaded environments without impacting the user experience on the source database. In addition, the customer can perform customized database backups, upgrades and
maintenance activities without impacting users, and site outages due to database malfunction have been eliminated. Case study 4: Replication from Oracle RAC to Oracle single instance
An online collaboration company with a data center in San Jose, California, and another in Denver, Colorado, has implemented multiple RACs in both data centers to handle online meetings by users. Each data center acts as a HA/DR site for the other. Both data centers are considered to be active, since they are used for load balancing of users as well. SharePlex is used to replicate data between the RAC environments in the two data centers in a bi-directional confi guration. In addition, SharePlex replicates selected data from both data centers to two separate single instance databases, which are optimized for customer billing and external reporting. Using SharePlex in this confi guration has enabled this customer to achieve unparalleled high availability that Oracle RAC cannot provide, leading to a better user experience and enhanced
customer satisfaction.
Conclusion
It’s inevitable that your user load and data size will grow along with your business. At some point, vertical scaling of your databases will become cost prohibitive or physically impossible to attain. Oracle’s answer to this problem is Oracle RAC. However, RAC has important disadvantages, including high hardware and support costs, a single point of failure, downtime for upgrades and migrations, and limited ability to tune for performance based on user workloads. SharePlex can be used either in conjunction with RAC or as a replacement for RAC to provide seamless horizontal scaling within the same or across data centers without the costs or other drawbacks associated with RAC.
About the author
Sujith has more than 20 years of experience in a variety of database technologies. For the past 15 years, he has been working on SharePlex, architecting custom data management solutions for Fortune 500 companies. As one of Dell’s chief technologists, he has been involved in acquisitions and mergers of other software companies. Sujith holds a M.S. in Engineering from Texas A&M University and a B.S. in Engineering from Bangalore University.
SharePlex can
be used either
in conjunction
with RAC or as a
replacement for RAC
to provide seamless
horizontal scaling
within the same or
across data centers
without the costs
or other drawbacks
associated with RAC.
© 2014 Dell, Inc. ALL RIGHTS RESERVED. This document contains proprietary information protected by copyright. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose without the written permission of Dell, Inc. (“Dell”).
Dell, Dell Software, the Dell Software logo and products—as identifi ed in this document—are registered trademarks of Dell, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners.
The information in this document is provided in connection with Dell products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Dell products. EXCEPT AS SET FORTH IN DELL’S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT,
DELL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL DELL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF DELL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Dell makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifi cations and product descriptions at any time without notice. Dell does not make any commitment to update the information contained in this document.
About Dell
Dell Inc. (NASDAQ: DELL) listens to customers and delivers worldwide innovative technology, business solutions and services they trust and value. For more information, visit www.dell.com.
If you have any questions regarding your potential use of this material, contact:
Dell Software 5 Polaris Way Aliso Viejo, CA 92656 www.dell.com
Refer to our Web site for regional and international offi ce information.
