1 / 58

Thomas Baus Senior Sales Consultant Oracle/SAP Global Technology Center

Thomas Baus Senior Sales Consultant Oracle/SAP Global Technology Center Mail: thomas.baus @oracle.com Phone: +49 6227 8398-13 4. Oracle9i RAC for SAP Customers. Agenda. Driving Forces Oracle9i RAC Architecture Oracle9i RAC Scalability Oracle9i RAC High Availability

lbeeson
Download Presentation

Thomas Baus Senior Sales Consultant Oracle/SAP Global Technology Center

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Thomas BausSenior Sales Consultant Oracle/SAP Global Technology Center Mail: thomas.baus@oracle.com Phone: +49 6227 8398-134

  2. Oracle9i RACfor SAP Customers

  3. Agenda • Driving Forces • Oracle9i RAC Architecture • Oracle9i RAC Scalability • Oracle9i RAC High Availability • Oracle9i RAC and SAP’s MCOD • Oracle9i RAC & Low Cost Technologies • Oracle9i RAC Release Strategy

  4. Driving Forces

  5. Driving Forces • Increased competition • Customers do not tolerate downtime • Management needs real-time information • System evolution • Growing amount of data • Changing workloads • Increasing complexity of IT landscapes • Increasing interaction between different systems

  6. Driving Forces • Economic slowdown • Decreasing earnings • Need to improve margins • Less money available for investments

  7. The Problem IncreasedCompetition EconomicSlowdown SystemEvolution More IT investments Less IT investments

  8. The Solution • Get most out of existing resources • Opimize resource usage • Implement high availability solutions • Minimize administration costs • Protect existing, minimize new investments • Look for modularity and scalability of system components • Look for low cost technologies • Simplify IT landscape (“consolidation”)

  9. The Solution • For several years, consolidation was the only strategy to reduce costs. • Modularity, scalability and low cost technologies require distribution. • This means, that we need a new concept of systems design: Consolidated and integrated systems should be distributed to cheap and standardized components.

  10. Oracle9i RACArchitecture

  11. Standard Oracle Architecture Database Instance

  12. Shared Nothing Architecture DatabaseInstance 1 Table A DatabaseInstance 2 Table B DatabaseInstance 3 Table C

  13. Table A Table C Table B Shared Disk Architecture DatabaseInstance 1 DatabaseInstance 2 DatabaseInstance 3

  14. Table A Table C Table B RAC Architecure DatabaseInstance 1 DatabaseInstance 2 High Speed Interconnect Mirrored DiskSubsystem DatabaseInstance 3 CacheFusion

  15. Oracle9i RACScalability

  16. RAC Scalability • In the past, clustered databases (OPS)scaled well for specific types of applications: • Data Warehouse • Parallel-enabled OLTP • RAC with Cache Fusion delivers transparent scalability to all types of applications(including SAP applications)

  17. RAC Scalability and SAP • In the past, the only way to scale the database server was to replace a small system by a larger system (“scale up”) • Oracle9i RAC provides an other option:add more small systems (“scale out”) • Benefits: • Protection of existing investments • Less new investments

  18. mySAP.com Scalability Presentation Application Database

  19. mySAP.com Scalability Presentation Application Database

  20. mySAP.com Scalability Presentation Application Database

  21. mySAP.com/RAC Scalability Presentation Application Database

  22. mySAP.com/RAC Scalability Presentation Application Database

  23. mySAP.com/RAC Scalability Presentation Application Database

  24. Parallel SD Benchmark • Oracle9i RAC running on HP (Compaq) Tru64 • 3-tier system • Finished: December 2001 • Certified: June 2002(2002029, 2002030, 2002031) • Goal: Prove scalability with max. CPU utilization

  25. Parallel SD Benchmark Scalability: 1.8 Scalability: 1.8

  26. Oracle9i RACHigh Availability

  27. Parallel Workload Study • Oracle9i RAC running on Windows 2000 • 2-tier systems • Finished April 2002 • Not intended for certification • Goal: Prove scalability under conditions as close as possible to real world environments(CPU util. between 33% and 70%)

  28. 100 SAP SD Users+ Oracle Instance 1 100 SAP SD Users+ Oracle Instance 2 100 SAP SD Users+ Oracle Instance 3 100 SAP SD Users+ Oracle Instance 4 RAC Scalability

  29. RAC Scalability + High Availability 133 SAP SD Users+ Oracle Instance 1 133 SAP SD Users+ Oracle Instance 2 134 SAP SD Users+ Oracle Instance 3 100 SAP SD Users+ Oracle Instance 4

  30. Parallel Workload Study Configuration Users Throughput(Dsteps/Hour) Scaling Phase 1: Scalability 1 node 100 SD 35,364 2 nodes 200 SD 70,320 1.99 3 nodes 300 SD 103,482 2.93 4 nodes 400 SD 133,840 3.78 Phase 2: High Availability 3 nodes 400 SD 124,812

  31. Parallel Workload Study

  32. Oracle9i RAC& SAP’s MCOD

  33. MCOD • SAP requires more and more databases for their different modules. • The SAP modules in a mySAP.com landscape are not independent, e.g. SAP SD, SAP CRM and BW interact and share data. • To guarantee the required consistency within all these databases, SAP has developed MCOD (“Multiple Components in One Database”)

  34. Typical mySAP.com Landscape SAP R/3Instance 1 OracleInstance 1 SAP R/3Instance 2 OracleInstance 2 SAP CRMInstance 1 OracleInstance 3 SAP BWInstance 1 OracleInstance 4

  35. SAP R/3Instance 1 SAP R/3Instance 2 OracleInstance 1 SAP CRMInstance 3 SAP BWInstance 4 OracleInstance 2 mySAP.com and MCOD

  36. mySAP.com, MCOD & RAC SAP R/3Instance 1 OracleInstance 1 SAP R/3Instance 2 OracleInstance 2 SAP CRMInstance 1 OracleInstance 3 SAP BWInstance 1 OracleInstance 4

  37. mySAP.com, MCOD & RAC • With Oracle 9i RAC, nodes can be optimally customized for dedicated workloads(e.g. CRM, HR, SD, Retail, etc.). • With Oracle 9i RAC, OLTP, BW andbatch-centric modules can be fine tuned without affecting each other. • Only running all related SAP modules inone database guarantees the consistency, especially for backups.

  38. Oracle9i RAC& Low-CostTechnologies

  39. Blades • Up to 600 CPUsper 19“ rack • Decreased spacerequirements: up to 7 times lessspace compared to classic servers • Decreased power requirements:up to 5 times less power consumption • Decreased cooling requirements: up to 5 times less cooling • Decreased price per CPU: up to 20 times less $/CPU compared to a classic 32-way server

  40. Blades: Expected Savings Company 1 $500,000 to $1,000,000 per rack Company 2 60% per server,90% of data center space (15m2 vs. 156m2) Company 3 60% of data center space (19,000m2 vs. 48,000m2)= € 7,000,000 Company 4 reduction from $54 to $31 per user

  41. Blades & Oracle9i RAC • Blades have a high potential to cut cost • Oracle runs on blades • 800 SD users with Oracle on a 2-way,Intel PIII, 800MHz, blade • With Oracle9i Real Application Clusters (RAC), blades can be clustered as instances of one database because of Oracle‘s shared disk architecture • Only Oracle 9i RAC can run on more than one blade with SAP

  42. Grid Computing • Without Grid, systems have dedicated tasks. • Each system has to be sized for worst case peak load of his task. • Under normal conditions, systems run over hours with low load. • Potential CPU power is wasted, because unused.

  43. idle Retail idle Retail Grid Computing Example 1: Retail • Within the normal business hours the system is under low load. • After business hours POS upload starts, new batch calculation starts, data collection and transfer to the BW systems starts. The system is now, but only a view hours, under the load it had to been sized for. ~ 50% idle

  44. idle CRM idle CRM Grid Computing Example 2: CRM • Within the normal businesshours, the system is under load it was sized for. • After business hours it runs with low load till the next business day. ~ 50% idle

  45. Grid Computing Grid to minimize unused resources. • Because different systems have different resources requirements at different points in time, free resources can be shared. • With Oracle Real Application Clusters (RAC),additional database nodes can be added up on demand.Example: Remove a database node from the CRM system and assign it to the Retail system for POS uploads.

  46. idle idle Retail idle CRM CRM Retail idle idle idle CRM Retail Retail CRM Grid Computing ~ 50% idle ~ 25% idle

  47. Centralized Storage • Storage Area Network (SAN) or Network-attached Storage (NAS) • Separates storage from the traditional server and puts it on special appliances • Provides a common storage pool that is highly scalable and flexible

  48. Centralized Storage • Centralized storage matches the capabilities offered by blades and RAC: • Small computing units without local disk • Shared disk storage (RAC) • No Oracle Cluster File System required, if NAS is used

  49. Linux • What is it? • Open-source operating system. • Supported by many hardware vendors. • Supported by many software vendors. • Increasing market share as serveroperating system.

More Related