Oracle RAC - Designing Applications for Scalability Presented by: Christo Kutrovsky.

Oracle RAC - Designing Applications for Scalability Presented by: Christo Kutrovsky

© 2013 Pythian - Presentation for Oracle OpenWorld Who Am I 2 Oracle ACE 12 years in Oracle field Joined Pythian 2003 Part of Pythian Consulting Group Special projects Performance tuning Critical services Presenter at: IOUG, RMOUG, UKOUG, OpenWorld “oracle pinup”

© 2013 Pythian - Presentation for Oracle OpenWorld 3 © 2011 Pythian - Confidential Why Companies Trust Pythian Recognized Leader: Global industry-leader in remote database administration services and consulting for Oracle, Oracle Applications, MySQL and SQL Server Work with over 150 multinational companies such as Forbes.com, Fox Sports, Nordion and Western Union to help manage their complex IT deployments Expertise: One of the world’s largest concentrations of dedicated, full-time DBA expertise. Employ 7 Oracle ACEs/ACE Directors. Hold 7 Specializations under Oracle Platinum Partner program, including Oracle Exadata, Oracle GoldenGate & Oracle RAC. Global Reach & Scalability: 24/7/365 global remote support for DBA and consulting, systems administration, special projects or emergency response

© 2013 Pythian - Presentation for Oracle OpenWorld Questions for Audience 4 How many have RAC today? How many have RAC for HA? How many have RAC for scalability? How many plan to move to RAC? How many develop on RAC?

5 Scale UP vs Scale OUT

© 2013 Pythian - Presentation for Oracle OpenWorld Database Performance 7 Has 2 primary components CPU – compute capacity IO – data transfer capacity Disk Network Cache (RAM) Implementation specifics Database scalability – latches, mutexes, threading etc.

© 2013 Pythian - Presentation for Oracle OpenWorld Scale UP - challenges 11 Scale UP Limited “max size” Appears unified, but is not, NUMA Slower CPUs 12.8-GB/sec per QPI Up to 88 Gb/sec of network (NEM) 8 PCIe slots Sources: http://www.oracle.com/technetwork/articles/systems-hardware-architecture/sun-server-x2-8-architecture-1689083.pdfhttp://www.oracle.com/technetwork/articles/systems-hardware-architecture/sun-server-x2-8-architecture-1689083.pdf

© 2013 Pythian - Presentation for Oracle OpenWorld CPU Comparisson 12 X3-2 8 cores per chip 2 chips max Server with 16 cores: 702 (SPECint®_rate2006) 43.8 per core 1.8 x faster X3-8 10 cores per chip 8 chips max server with 80 cores: 1990 (SPECint®_rate2006) 24.8 per core 56% of x3-2 Sources: http://www.spec.org/cpu2006/results/res2012q4/cpu2006-20121104-24909.html http://www.spec.org/cpu2006/results/res2012q3/cpu2006-20120710-23574.html

© 2013 Pythian - Presentation for Oracle OpenWorld Scale OUT 13 Requires Synchronisation Software – Oracle RAC Requires “interconnect” network Low latency critical Requires additional CPU resources for cross- node synchronisation Some operations (ex. locking) significantly increased latency (network vs. memory)

© 2013 Pythian - Presentation for Oracle OpenWorld Adding CPU hardware 14 Both Scale UP and Scale OUT increase total CPU capacity and IO network bandwidth Does not improve IO latency Does not improve IO requests capacity Does not improve application response time Does not make your batch job run faster

17 Oracle RDBMS Scale OUT with RAC

© 2013 Pythian - Presentation for Oracle OpenWorld Why Scale OUT Oracle 18 Access to fastest CPUs Reduced query response time by 1.8x Less CPU licenses (although RAC costs) Control (m anual) over data localisation Natural HA Infinite scalability – realistically

© 2013 Pythian - Presentation for Oracle OpenWorld Challenges with Oracle RAC 19 Concurrent modifications latency increased drastically Requires block transfer (CPU + network) Requires partial disk flush (CPU + latency) Concurrent reads do not share RAM cache Each node has local copy Oracle RAC Cache Fusion Reads slow timings similar to SSD read speeds – 10,000x slower than memory reads

20 Practical Issues Concurrent inserts

© 2013 Pythian - Presentation for Oracle OpenWorld Data Block 21 Oracle stores data in blocks, in rows Each segment (table) has independent blocks* Lowest granularity in RAC data exchange is block* Modifying any data requires the block to be ‘acquired’ in local SGA (cache) Oracle Table Block 8 KiB (8192) Oracle Table Block 8 KiB (8192) 1, Christo Kutrovsky, Canada, 99$ 2, Alex Gorbachev, Canada, 98$ 3, Marc Fielding, Canada, 101$

© 2013 Pythian - Presentation for Oracle OpenWorld Inserting Data 22 Inserting a row is modifying the block Oracle Table Block 8 KiB (8192) Oracle Table Block 8 KiB (8192) 1, Christo Kutrovsky, Canada, 99$ 2, Alex Gorbachev, Canada, 98$ 3, Marc Fielding, Canada, 101$ 4, Vanessa Simons, Canada, 199$

© 2013 Pythian - Presentation for Oracle OpenWorld Block needs to move 23 Block will bounce from node to node depending on where the insert runs Server CPU RAM Server CPU RAM Server CPU RAM APP 4, Vanessa Simons, Canada, 199$ 5, John Smith, Canada, 777$ 6, Scott Tiger, Canada, 333$

© 2013 Pythian - Presentation for Oracle OpenWorld Inserting Data 25 Yes we can! But… ASSM Instances can “own” L1 space metadata, which maps to N blocks Larger segments To have multiple L1 space metadata, larger segments are required

© 2013 Pythian - Presentation for Oracle OpenWorld ASSM – bitmapped space mgmt 26 ASSM L3 L2 L1 1 L1 1 L1 2 L1 2 L1 3 L1 3 L1 4 L1 4 L1 5 L1 5 L1 6 L1 6 L1 7 L1 7 L1 8 L1 8 BLOCKS 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 11 12 13 14 15 16

© 2013 Pythian - Presentation for Oracle OpenWorld ASSM 27 Server CPU RAM Server CPU RAM Server CPU RAM APP 4, Vanessa Simons, Canada, 199$ 5, John Smith, Canada, 777$ 6, Scott Tiger, Canada, 333$ L1 1 L1 1 BLOCKS L1 2 L1 2 BLOCKS L1 3 L1 3 BLOCKS

© 2013 Pythian - Presentation for Oracle OpenWorld Primary Key 28 Primary Key – an index Each row has a very specific place Must insert into last block, always Sequentially generated … or is it? Oracle Table Block 8 KiB (8192) Oracle Table Block 8 KiB (8192) 1, Christo Kutrovsky, Canada, 99$ 2, Alex Gorbachev, Canada, 98$ 3, Marc Fielding, Canada, 101$ 4, Vanessa Simons, Canada, 199$ 5, John Smith, Canada, 777$ 6, Scott Tiger, Canada, 333$ 7, ……………………..

© 2013 Pythian - Presentation for Oracle OpenWorld Sequences 29 Sequences can be Cached or NOcached Ordered or NOordered Cached NOordered with large cache are your best friend A sequence’s cache “sticks” with a RAC node cache 10,000 – 10,000 sequential values assigned to node 1

© 2013 Pythian - Presentation for Oracle OpenWorld NO ORDER 30 Server CPU RAM Server CPU RAM Server CPU RAM APP ?, Vanessa Simons, Canada, 199$ ?, John Smith, Canada, 777$ ?, Scott Tiger, Canada, 333$ 10,001 10,002 10,001 10,002 20,001 20,002 20,001 20,002 30,001 30,002 30,001 30,002

© 2013 Pythian - Presentation for Oracle OpenWorld Sequences 31 Cached noordered 10,000 cache – almost perfect Oracle numbers “compress” zeroes 10,000 and 20,000 are next to each other Sequence dictionary updates moves blocks Order not maintained But what if it’s required? Is it required? When do you consider the row “inserted”? What if delayed due to lock/concurrency?

© 2013 Pythian - Presentation for Oracle OpenWorld Index on date inserted 32 Concurrently inserted records have same date or very close Specific ordering in blocks No flexibility on values Same for index on Country or any other “same value” column Oracle Table Block 8 KiB (8192) Oracle Table Block 8 KiB (8192) 1, Christo Kutrovsky, Canada, 99$ 2, Alex Gorbachev, Canada, 98$ 3, Marc Fielding, Canada, 101$ 4, Vanessa Simons, Canada, 199$ 5, John Smith, Canada, 777$ 6, Scott Tiger, Canada, 333$ 7, ……………………..

© 2013 Pythian - Presentation for Oracle OpenWorld Dates 33 Server CPU RAM Server CPU RAM Server CPU RAM APP ?, Vanessa Simons, Canada, 199$ ?, John Smith, Canada, 777$ ?, Scott Tiger, Canada, 333$ 11:09:01

© 2013 Pythian - Presentation for Oracle OpenWorld Same Value Index 34 Requires Partitioning Changes everything Partition key selection is non-trivial Local Indexes Lots of combinations Primary key local or global Depends on partition key and type Lots of considerations Data locality

© 2013 Pythian - Presentation for Oracle OpenWorld Partition 4 BLOCKS 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 IDX Date IDX Date IDX PK IDX PK Partitioning 35 Partition 1 BLOCKS 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 IDX Date IDX Date IDX PK IDX PK Partition 2 BLOCKS 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 IDX Date IDX Date IDX PK IDX PK Partition 3 BLOCKS 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 IDX Date IDX Date IDX PK IDX PK

© 2013 Pythian - Presentation for Oracle OpenWorld Same Value Index 36 Multiple partitions Create multiple blocks that have the “current” date “current” block will still move around the cluster, but decreases changes of “collisions” Still far from ideal

© 2013 Pythian - Presentation for Oracle OpenWorld Same Value Index - Other 37 Alternative solutions Prefix same value index with customer ID Prefix same value index with INSTANCE_ID “fake” local index Relies on skip scan

38 Application Partitioning

© 2013 Pythian - Presentation for Oracle OpenWorld Application partitioning 42 By Functionality Not all functions of the application require concurrent modifications Isolating by functionality is the easiest and fastest way to ‘fix’ RAC unfriendly activities Such functionality has inherently bad scalability properties, as number of cores increase, this will become bigger problem Cache fusion will mirror concurrently read data Multiple nodes do not ‘add’ to caching benefits

© 2013 Pythian - Presentation for Oracle OpenWorld Apps 43 Server CPU RAM Server CPU RAM Server CPU RAM Server APP Server APP Server APP Module(s) With Concurrent Modifications Module(s) With Concurrent Modifications

© 2013 Pythian - Presentation for Oracle OpenWorld More Performance 45 Tune it What are you doing? Can you not do it? Can you do it more efficiently? Are you using the latest hardware? Should probably start with this Still need more?

© 2013 Pythian - Presentation for Oracle OpenWorld Data Partitioning 50 Partition the Database to match Consider growth – have significantly more buckets than servers Local indexes everywhere Partition key and Primary Key generation can be challenging If partitioned by primary key, key generation from one node, must not send data to multiple partitions Secondary unique indexes still challenging

© 2013 Pythian - Presentation for Oracle OpenWorld Data Partitioning – Primary Keys 51 Unique Keys Primary Keys usually part of partition key Two level partitioning (range for historical, hash for concurrency) – global partitioned indexes

© 2013 Pythian - Presentation for Oracle OpenWorld Sharded Data – why use RAC? 52 Most apps will “just work” Few components require extra attention Not all data is sharded Reference / Lookup Data is shared Low concurrency data does not need to be sharded Redundancy – can ‘fail back’ to any node Caching (performance) implications

© 2013 Pythian - Presentation for Oracle OpenWorld Sharded Data – why use RAC? 53 Some data cannot be sharded one way Many to Many Buyer/Seller with portals for both customers and stores Manual sharding mistakes – loose data Non shardable queries? Code manually? Sharded queries and sorting Schema Changes/Indexing

© 2013 Pythian - Presentation for Oracle OpenWorld Reports Across all Data 55 No replication Cross shard consistency – even after data restore No data movement Reuse cache from each node Parallel queries can leverage all nodes MPP on OLTP data

56 Final Thoughts

Oracle RAC - Designing Applications for Scalability Presented by: Christo Kutrovsky.

Similar presentations

Presentation on theme: "Oracle RAC - Designing Applications for Scalability Presented by: Christo Kutrovsky."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Oracle RAC - Designing Applications for Scalability Presented by: Christo Kutrovsky.

Similar presentations

Presentation on theme: "Oracle RAC - Designing Applications for Scalability Presented by: Christo Kutrovsky."— Presentation transcript:

Similar presentations

About project

Feedback