Achieving Oracle Database Scalability using SharePlex

Transcription

1 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 Oracle 7, and then morphed OPS into Real Application Cluster (RAC) in Oracle 9i. Oracle RAC enables IT organizations to scale horizontally using cheaper hardware, making it a costeffective alternative to expensive single monolithic super 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 organizations can overcome RAC s limitations and achieve six nines of availability for their databases with no platform, geographic, network or performance limitations.

2 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 reinvigorated 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 affordable 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. Benefits 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 different 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 Notification (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 different 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 Infiniband 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 different type of workload, such as online transaction processing (OLTP), data mining or reporting. 2

3 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-effective alternative: SharePlex SharePlex from Dell Software is an affordable 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 affordable, easy-to-use logical data replication solution for Oracle databases. It provides a realtime 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 files using a proprietary capture mechanism. Applications are able to access multiple copies of the database seamlessly an analogue to receiving s in desktop Microsoft Outlook client and mobile devices simultaneously. SharePlex can replicate the database in its entirety or can be limited to specific schemas, tables, columns or rows within tables. It also has the ability to modify or transform replicated data on the fly prior to posting it to the target database. SharePlex from Dell Software is an affordable logical replication solution that can either complement Oracle RAC or completely replace it. Export queue Export Import Post queue SQL Read Redo/archive logs Post Post Source Capture Capture queue Cloud target Target Figure 1. SharePlex captures changes to the source database and keeps the replica in sync in real time. 3

4 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 flip the users or the application to a copy of the database with no downtime. 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 diskbased queue files. Benefits of SharePlex SharePlex offers some of the same benefits 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 flip the users or the application to a copy of the database with no downtime. Optimization for different 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 different nodes. SharePlex maintains multiple copies of the same database in real time, so each replica database can be customized for different 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 different set of indices that will run reports and queries more efficiently. Geographic flexibility 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 different storage mount points. This eliminates 4

5 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 affordable 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 effectively. 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 configuration, 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 modification 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 configured 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. 5

6 10g, 4-node RAC, RedHat Linux 4, Siebel application 11g, 5-node RAC, RedHat Linux 5, Siebel application Figure 2. SharePlex migration with reverse replication for failback, if required One team was able to reclaim 1.2TB of storage space in an 11g environment by performing the archive/ purge during the migration. 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 configured as a failback option, in case it would be required. The Dell DBA team summarized the benefits 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. Figure 3. Using SharePlex active-active replication across multiple data centers 6

7 RAC 1: Airline reservations RAC 2: Hotel reservations Figure 4. SharePlex peer-to-peer replication using a RAC configuration 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 configured in HA/DR mode. Using SharePlex in active/active replication configuration 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 configuration 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 different 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 first product offering. 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 offering. Using SharePlex in active/active replication configuration 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. Data center 1 Data center 2 Target 1: Billing (internal users) Target 2: Reporting (external users) Figure 5. RAC replicating to reporting single instance 7

8 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. Using SharePlex peer-to-peer replication, the customer has been able to offload 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 configuration. 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 configuration 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. 8

9 For More Information 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 identified 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 specifications 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 If you have any questions regarding your potential use of this material, contact: Dell Software 5 Polaris Way Aliso Viejo, CA Refer to our Web site for regional and international office information. 9 TechBrief-SharePlex-OracleDB-US-KS-24265