Oracle RAC - Roadmap for New Features

Oracle Real Application Clusters
(RAC) – Roadmap for New Features
Markus Michalewicz, Senior Director of Product Management
Dave Hickson, Database Architect, BT
Tak Wang, Vice President, Oracle RAC Development

October 22, 2018
Confidential – Oracle Internal/Restricted/Highly Restricted

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, timing, and pricing of any
features or functionality described for Oracle’s products may change and remains at the
sole discretion of Oracle Corporation.
3

Program Agenda
Overview
Better Management
Better Availability
Better Scalability & Performance
The Road Ahead
1
2
3
4
5
4

Program Agenda
Overview
Better Management
Better Availability
The Road Ahead
1
2
3
4
5
5


Scalable Sequences
Continuous Application Availability
Oracle RAC Sharding
Cluster Domains
Cluster Health Advisor (CHA)
RAC Reader Nodes
Application Continuity (AC)
Oracle Flex ASM & Flex Clusters
Rapid Home Provisioning (RHP)
Cluster Health Monitor (CHM)
Oracle Quality of Service Management (QoS)
Policy-Based Cluster Management
Oracle RAC One Node & RACcheck
Oracle ASM Cluster File System (ACFS)
Oracle Grid Infrastructure (GI)
UCP and OCI Load Balancing Support for RAC
Cluster Verification Utility (CVU)
Cluster-Managed Services
Oracle Clusterware
Oracle Automatic Storage Management (ASM)
Oracle Real Application Clusters (RAC)

Oracle 9i
Oracle RAC’s Journey into the Autonomous Database
20-years of continuous innovation*
Oracle 18c
* Documented features list is selective; 20 years include development time
6

Oracle RAC Innovation Spin-Off 1
Oracle Autonomous Health and the Autonomous Health Framework (AHF)
7
http://oracle.com/goto/ahf

Oracle Fleet Patching & Provisioning (FPP) and Gold Image Management
formerly Oracle Rapid Home Provisioning (RHP)
8
http://oracle.com/goto/fpp
(http://oracle.com/goto/rhp)

Application Continuity & Continuous Application Availability – the new MAA* standard
* MAA = Maximum Availability Architecture
9
http://oracle.com/goto/ac

Oracle Autonomous Database Highlights
Self-Driving
Automates database and
infrastructure management,
monitoring, tuning
Self-Scaling
Scales online for
highest performance
and lowest cost
Self-Repairing
Protects from all
downtime including
planned maintenance
Enabled by Applied Machine Learning
10
1 2 3 4 5

Oracle RAC Development Focus Areas
Better scalability
& performance
Efficient management
for
large scale deployments
Better availability
11

Program Agenda
Overview
Better Management
Better Availability
The Road Ahead
1
2
3
4
5
12

What If…You have Hundreds of Environments
And what if…
– Software Installation
– Storage configuration
– Diagnostics setup

… would have to be performed only once
and can then be re-used multiple times?

… allowing you to save many hours
performing these tiring tasks?
13

Cluster
Domain
Cluster Domain-Based Management
Facilitating …
– Fleet Patching & Provisioning (FPP) /
formerly Rapid Home Provisioning (RHP)
– Autonomous Health Framework (AHF)
– Automatic Storage Management (ASM)

and hosted on a dedicated cluster
– the Domain Services Cluster (DSC) –

all three management tasks can be
centralized and diagnostics can be optimized

for Member Clusters in a Cluster Domain.
14
Domain Services Cluster
FPP AHF
Simplification and efficiency through centralization

Cluster Domains @BT
David Hickson – Database Architect
BT
October 22, 2018

© British Telecommunications plc
About BT
•  The UK’s largest broadband provider
•  The UK’s largest last-mile network provider
•  The UK’s largest wide area network provider
•  In EE, the UK’s best largest and best mobile network provider
•  A global footprint operating in 180 countries
•  BT Sport delivering Premiership and UEFA football
•  All underpinned by Technology Department

Context – Existing RAC and Database Services in BT
•  Large scale, on-premises Enterprise Cloud
•  Oracle Database and RAC estate continuing to grow
•  Oracle RAC databases mostly on 12.1 or 12.2
•  12.2 clusters only since April 2018
•  Lots of automation already but …
•  We need smarter ways to
–  Deliver RAC clusters more quickly
–  Administrate more efficiently
•  Goal: Reduce overheads of many RAC clusters

Cluster Domains – Why is this architecture attractive to us?
•  I/O Server
–  Replace hundreds of independent pools of storage with centralised pools
–  Increase storage on member clusters without infrastructure changes
•  Rapid Home Provisioning
–  Centralised management of Oracle software for installation, patching, upgrading
•  Autonomous Health Framework
–  Replace many independent management repositories with one

Cluster Domains – Future Plans
•  What we’ve done
–  Testing of Cluster Domains and Member Clusters using 12.2.0.1
–  On virtualised infrastructure
•  What we plan to do
–  Cluster Domains are a significant architectural shift
–  Proceed with Oracle Database 19c (AKA 12.2 Terminal Release)
–  I/O server, Rapid Home Provisioning and Autonomous Health Framework

What’s Next for Cluster Domains?
1.  Transitions (*18c+)
2.  Domain Services
Cluster Availability
3.  and Performance
Planned Transitions
20

gridSetup and zip-based install
for Oracle Grid Infrastructure
NEW: RPM-based installs for the
Oracle Database and Oracle Client
ASM Management for
NFS-based Clusterware files
for easier management and
thereby better availability.
Separate Diskgroup for Grid
Infrastructure Management
Repository (GIMR)
allows for more flexibility during
Grid Infrastructure Installation

Better Management Thanks to Your Feedback
$ORACLE_HOME/gridSetup.sh
Configure ASM on NFS
21

Adapting to Your Feedback
•  Desupport of Direct File System Placement for Oracle Clusterware Files
– Introduced with Oracle Clusterware 12c Rel. 2 (12.2.0.1)
– Effective with Oracle Clusterware 18c
– Desupport revoked effective with Oracle Clusterware 19c
•  Oracle Grid Infrastructure Management Repository (GIMR)
– Around since Oracle Grid Infrastructure 11g Release 2
– Automatic Installation of the GIMR introduced with Grid Infrastructure 12.1.0.2
– Separate diskgroup installation introduced with Grid Infrastructure 12c Release 2
– Automatic install revised for Oracle Grid Infrastructure 19c
•  Plans foresee a GIMR installation outside of the Oracle Grid Infrastructure home for Standard Clusters
•  Centralized GIMR hosting on a Domain Services Cluster (for Member Clusters) remains unchanged
22

Flex Cluster Massive Parallel Query Oracle RAC Oracle RAC Reader Nodes
Oracle Flex Cluster – A Brief Review
23

Flex Cluster
Leaf nodes deprecated
Massive Parallel Query Oracle RAC
deprecated
Oracle RAC Reader Nodes
to be implemented on Hub nodes
Flex Cluster – Changes Down the Road
24

Deprecation = Room to Focus on Innovation
•  Oracle Flex Cluster
–  Introduced with Oracle Clusterware 12c Release 1 (12.1.0.1)
•  Target use case: Management of applications and database in the same cluster
•  Databases are meant to be hosted on HUB nodes, applications on Leaf nodes
–  Oracle Clusterware 12c Release 2 enabled two more uses cases:
1.  Massive Parallel Query Oracle Real Application Clusters (Oracle RAC)
2.  Oracle RAC Reader Nodes
–  Effective with Oracle Clusterware 18c
•  Leaf nodes as part of the Flex Cluster architecture have been deprecated
•  The “Massive Parallel Query Oracle RAC” use case has been deprecated
•  The “Oracle RAC Reader Nodes” use case remains and will be supported on HUB nodes instead
–  HA capabilities provided by Leaf nodes will be made available on Hub nodes as applicable
•  The desupport of Leaf nodes and their respective uses cases is currently planned for Oracle Clusterware 19c
25

Program Agenda
Overview
Better Management
Better Availability
The Road Ahead
1
2
3
4
5
26

Application Continuity
& Continuous Application
Availability
Zero Brownout
Reconfiguration
Zero Downtime
Maintenance
Three Availability Focus Areas
27

Innovation Under the Hood
Multiple projects and features contribute to Zero Brownout Reconfiguration
Maximum Availability Architecture
4x
faster
1.5x
faster
•  Oracle RAC reconfiguration times reduced by
–  4x between Oracle RAC 11.2.0.4 and 12 Rel. 2
–  1.5x between Oracle RAC 12c Rel. 2 & 18c
–  for a total of 6x improvements
between Oracle RAC 11.2.0.4 and 18c

•  Selection of contributing features:
–  Remastering Slaves (*12.1)
–  Support for 100 LMS’s (*12.2)
–  More Dynamic Remastering
28

Contributing Features
•  Remastering Slaves (1 slave per LMS)
–  Starting with Oracle RAC 12.1, the LMS offloads heavy remastering work to the slave
–  This improves LMS’s responsiveness for Cache Fusion requests during remastering

•  Support for 100 LMS’s – change in default value
–  Oracle RAC 12.2 supports up to 100 LMS’s (names: LMS0-LM99) as opposed to 35
–  On larger systems (lots of CPU, large SGA), more LMS’s will start by default
–  More LMS’s means better reconfiguration time without any impact during runtime

•  More Dynamic Remastering (DRM)
–  Starting with Oracle RAC 19c, DRM is planned to more adaptively consider the overall system state
29

Innovation on the Way to the Autonomous Database
•  A proactive and automatic monitoring and correction framework
–  Some functionality first introduced in Oracle RAC 12c
–  Current framework used in Oracle RAC 18c; further enhancements planned for Oracle Database 19c

–  Monitors various (currently ~50) metrics across different layers continuously
•  Shares and considers information globally, but acts locally
–  Detects problems before any disruption of service occurs
•  v$ tables provide logs showing current system status and history of issues detected
–  Identifies root cause accurately, based on current system situation
•  Uses a combination of metrics to predict potential issues and identifies root cause(s)
–  Resolves problems with minimum disruption, ideally before it happens
•  Takes preventative action based on identified root cause
–  Serializes actions across the cluster to minimize resolution impact
•  Corrective actions are performed on per resource basis
Introducing Database Reliability Framework (DRF) (Working Name)
30

Patching Improvements
•  OJVM is Oracle RAC rolling patch enabled with Oracle RAC 18c (18.4)
– Non-Java services are available at all times
– Java services are available all the time, except for a ~10 seconds brownout
•  No errors are reported during the brownout
•  Zero-Downtime Oracle Grid Infrastructure Patching (*18.3)
– Patch Oracle Grid Infrastructure without interrupting database operations
– Patches are applied out-of-place and in a rolling fashion with one node being patched
at a time while the database instance(s) on that node remain up and running
– Supported for Oracle RAC and RAC One Node clusters with two or more nodes
31

Program Agenda
Overview
Better Management
Better Availability
The Road Ahead
1
2
3
4
5
32

Innovation Under the Hood
Multiple projects and features contribute to Better Scalability & Performance
5x
faster
•  Oracle RAC performance has improved up to
–  5x between Oracle RAC 11.2.0.4 and 18.1
especially for high contention workloads
•  Selection of contributing features:
–  Leaf Block Split Optimizations (*12.2)
–  Scalable Sequences (*18c)
•  Exadata-based optimizations:
–  Undo RDMA-Read (*18c)
–  “Smart Fusion Block Transfer” (*12.2)
–  ExaFusion Direct-to-Wire OLTP Protocol (*12.2)
33

Oracle RAC Performance Features
• Automatic Undo Management
• Cache Fusion
• Oracle Real Application Clusters
• Session Affinity
• PDB & Services Isolation
• Service-Oriented Buffer Cache
• Leaf Block Split Optimizations
• Self Tuning LMS
• Multithreaded Cache Fusion
• ExaFusion Direct-to-Wire Protocol
• Smart Fusion Block Transfer
• Universal Connection Pool (UCP) Support for Oracle RAC
• Support for Distributed Transactions (XA) in Oracle RAC
• Parallel Execution Optimizations for Oracle RAC
• Affinity Locking and Read-Mostly Objects
• Reader Bypass
• Flash Cache
• Connection Load Balancing
• Load Balancing Advisory
• Cluster Managed Services
• Automatic Storage Management
9i 10g
11g
12c
18c
• Scalable Sequences
• Undo RDMA-Read
• Commit Cache
• Database Reliability Framework
Over two decades of innovation

Contention can occur in any multi-
user system (even in SI databases)
Scaling out, contention can occur
between instances
(not only within an instance).
From a contention perspective,
the number of nodes is irrelevant.
Contention – The Basics
https://www.slideshare.net/MarkusMichalewicz/oracle-rac-internals-the-cache-fusion-edition
write
write
write
write
Note: for scalability, only write/write contention needs to be considered.
write
write
write
write
35

Frequent transactional changes to
the same data blocks may result in
“write hot spots”
Pending redo must be written to
log before the block can be
transferred
Contention can affect related data as
much as it can affect the user data.
Right growing indexes and
index contention are common.
In 99% of OLTP performance issues,
write hot spots occur on indexes.
Contention – Considerations
https://www.slideshare.net/MarkusMichalewicz/oracle-rac-internals-the-cache-fusion-edition
Sequence
REDO
36

ExaFusion
Direct-to-Wire OLTP Protocol
allows the database to directly
call into the InfiniBand HW.
Smart Fusion Block Transfer
Improves Cache Fusion latency by
allowing LMS to serve dirty blocks
as soon as a REDO flush is initiated
3x faster Right-Growing Index
performance due to
Leaf Block Split Optimizations,
Scalable Sequences,
Commit Cache
Contention – The Solutions
37

Undo RDMA-Read & Commit Cache
•  Undo RDMA-Read (*18c)
–  In some workloads, more than half of the remote
reads are for Undo Blocks to satisfy read consistency
–  Undo Block RDMA-read uses RDMA to directly and
rapidly access UNDO blocks in remote instances
•  Avoids having to activate a remote LMS to perform the operation
•  Commit Cache (*18c)
–  The Commit Cache maintains an in-memory, simple
hash table of recent transactions on each instance
–  Remote LMS directly reads the commit cache and
sends back commit times for requested transactions
•  Replaces having to send entire 8K transaction table block
•  Customer test results:
–  Up to 57% of the cache-fusion block traffic was eliminated
–  cluster wait time down by 22%; DB CPU time down by 7%
UNDO UNDO
RDMA RDMA
Inst
1
Inst
3
Inst
2
38

Scaling the World’s Most Complex Enterprise Workloads
•  Due to its market leading Cache Fusion algorithm, Oracle RAC scales

1.  any feature – e.g. Pluggable Databases, Oracle In-Memory and Oracle Data Guard

2.  most enterprise applications – e.g. Ebusiness Suite, SAP, Oracle Hospitality

3.  nearly all custom applications as used by many of Oracle’s 15000 RAC customers

•  Without the need for significant application changes
•  Especially on Oracle Exadata Database Machines
•  Designed to support Oracle Autonomous Database Cloud

39

Why Oracle Sharding?
•  Some applications hugely benefit from “data dependent routing”
–  Data dependent routing means that users are routed to where the data resides
–  Routing can be performed within an Oracle RAC database or across independent databases
–  Oracle Sharding is Oracle’s fully integrated data dependent routing solution

•  Oracle RAC Sharding
–  Affinitizes table partitions to instances
•  for better cache utilization and reduced block pings between instances
–  Takes advantage of direct routing API of Sharding:
•  Requests that a specify sharding key are routed to the instance that logically holds the corresponding partition
•  Requests that do not provide a partition key will be routed based on the default load balancing policy
–  Adding a sharding key improves OLTP performance requires no changes to the database schema
•  alter system enable affinity <TableName>;
40

Another Innovation for Oracle RAC
Oracle RAC Sharding
41
http://oracle.com/goto/sharding

Program Agenda
Overview
Better Management
Better Availability
The Road Ahead
1
2
3
4
5
42

The Road Ahead Leads into the Autonomous Database Cloud
•  Future scalability & performance improvements
– Tailor to scaling well within Exadata dimensions (“scale linear across 64 nodes, not 200”)
– Are designed to meet ADB performance requirements and will grow as ADB enhances
– Will leverage RDMA technology for server-less communication
– Plan to use RoCE as the next-generation network for the cloud
•  Details in MOS note “Oracle RAC Interconnect Protocols – Support and Roadmap (ID 2434852.1)”
– Will substitute storage access with network-based access to data on remote nodes
– Are likely to utilize NVM for storage on independent servers (eliminate shared disk)
•  Future availability improvements
– Will focus on reducing re-configuration times (brownouts) further to come closer to “zero”
– Will provide even more ways to perform maintenance & admin tasks with no downtime
43

Oracle RAC - Roadmap for New Features

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Oracle RAC - Roadmap for New Features

Ähnlich wie Oracle RAC - Roadmap for New Features (20)

Mehr von Markus Michalewicz

Mehr von Markus Michalewicz (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Oracle RAC - Roadmap for New Features