Oracle RAC 19c - the Basis for the Autonomous Database

1
Real Application Clusters (RAC) 19c
for the Autonomous Database
MarkusMichalewicz,
SeniorDirectorDatabaseHighAvailability
andScalabilityProductManagement
July2,2019

Safe Harbor Statement
The preceding 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, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
Copyright © 2019, Oracle and/or its affiliates. All rights reserved. | 2

3
The first fully Autonomous Database in the industry
Self-Driving
Automates all database and
infrastructure management,
monitoring, tuning
Self-Securing
Protects from both
external attacks and
malicious internal users
Self-Repairing
Protects from all
downtime including
planned maintenance
Copyright © 2019, Oracle and/or its affiliates. All rights reserved. |

4Copyright © 2019, Oracle and/or its affiliates. All rights reserved. |
Oracle Driving Database Innovations & Leadership
Continued focus on automation; not maintenance
• Automatic Query Rewrite
• Automatic Undo Management
• Autonomous Health Framework
• Automatic Diagnostic Framework
• Automatic Refresh of Clones
• Automatic SQL Tuning
• Automatic Workload Capture / Replay
• Automatic SQL Plan Management
• Automatic Capture of SQL Monitor
• Automatic Data Optimization
• Automatic Memory Management
• Automatic Segment Space Mgmt
• Automatic Statistics Gathering
• Automatic Storage Management
• Automatic Workload Repository
• Automatic Diagnostic Monitor
• Automatic Columnar Flash
• Automatic IM population
• Automatic Application Continuity
9i 10g
11g
12c
18c
• Automatic Indexes, Partitions
• Automatic Materialized views
19c

5
Automating and Optimizing Database Infrastructure
• Smart Scan
• Infiniband Scale-Out
• Database Aware Flash Cache
• Storage Indexes
• Hybrid Columnar Data
• IO Priorities
• Data Mining Offload
• Offload Decryption
• Direct-to-wire Protocol
• JSON and XML offload
• Instant failure detection
• Network Resource Mgmt
• Prioritized File Recovery
• In-Memory Columnar in Flash
• Smart Fusion Block Transfer
• Exadata Cloud Service
2008
2018Engineered Systems provide a
differentiated platform to build upon

Autonomous Completes the Journey
Full automation of database lifecycle enabled with machine learning
Autonomous
Database
Automated
Data Center Operations
Complete
Infrastructure
Automation
Complete
Database
Automation
Oracle Cloud

Autonomous Database Means Oracle RAC on Exadata
Autonomous
Database
Automated
Data Center Operations
Oracle Cloud

One Autonomous Database - Optimized by Workload
ORACLE
AUTONOMOUS
DATABASE
• Transactions, Reporting, IoT
• App Dev, Machine Learning
Autonomous
Transaction Processing
• Data Warehouse, Data Mart
• Data Lake, Machine Learning
Autonomous Data
Warehouse

Dedicated
Exadata Cloud Infrastructure
Serverless
Exadata Cloud Infrastructure
One Autonomous Database – Two Deployment Options
ORACLE
AUTONOMOUS
DATABASE

ORACLE
AUTONOMOUS
DATABASE
Why Oracle RAC?

Oracle RAC is Designed for ATP-D
Better availability
11
Efficient management
for
large scale deployments
Better scalability
& performance

12
A Look Under the Hood
Key Capabilities of Self-driving, Self-Securing, Self-Repairing facilitating Oracle RAC
Self
Rapid Provisioning
Self Scaling
Automatic Tuning
Automatic Indexing
Self
Self Patching
Encryption by Default
Separation of Duties
Auditing
Self
Self Healing Hardware
Self Healing
Software
Maximum Availability
Architecture
Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

ORACLE
AUTONOMOUS
DATABASE
How does it work?

14
Self
Rapid Provisioning
Self Scaling
Automatic Tuning
Automatic Indexing
Self
Self Patching
Auditing
Self
Self Healing
Software
Architecture

Self-Driving | Rapid Provisioning
Database creation is quick and easy - answer 6 simple question:
1. DB region
2. DB type - ATP or ADW
3. DB name
4. DB CPU count - really performance
5. DB storage size limit
6. Admin Password
• Exadata Cloud Infrastructure instantly provisioned with Oracle RAC Database
– Easy migration as it’s the same database as you have on-premises today
• Performance resources allocated proportionally to number of CPUs chosen

Self-Driving | Elastic Scaling
1 2 3 4 5
• Instant scaling online for highest
performance and lowest cost
• Scale compute or storage completely
independent of one another
• All scaling operation occur online – while
the application continuous to run
• Scaling actions are exposed through Cloud
UI and REST APIs

17
RAC Scales 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

Oracle RAC Performance Features
Over two decades of innovation
• 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
• 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
19c
• Dynamic Resource Allocation
features (for ATP-D)

• With Oracle Database SGA Runtime Management, the SGA can grow during runtime.
• Starting with Oracle Database 19.3, Oracle RAC Resource Runtime Management allows
for automatic and at-runtime adjustment of resources that otherwise used to be
allocated at instance startup time. This enables more efficient resource allocation.
• Memory allocations have traditionally been made based on CPU_COUNT, but were
fixed at instance startup. A post-start CPU change will now trigger re-adjustment.
Oracle RAC – Enhanced for ATP-D
RAC Resource Runtime Management

• In Autonomous Transaction Processing – Dedicated
– Allocations of <= 16 CPU are meant to be handled in one instance only
Cross-Instance scaling depends on CPU_COUNT

Innovation Under the Hood
MultipleprojectsandfeaturescontributetoBetterScalability&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)

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
write
write
write
write

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

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

Self-Driving | Automatic Indexing
• An expert system that implements
indexes based on what a skilled
performance engineer would do
• Reinforcement Learning allows it to learn
from it’s own actions as all candidate
indexes are validated before being
implementing
• The entire process is fully automatic
• Transparency is equally important as
sophisticated automation
• All tuning activities are auditable

Self-Driving | Cloning
Clone DB for
Development or test
Production DB
Cloning creates a point-in-time copy of an ADB
for testing, development, analytics, etc.
Two types of clone can be created:
• A full database clone
• A metadata clone (Schema but no data)
Easy and fast as user only has to decide:
1. Compartment for the clone
2. Name of the clone
3. CPU and storage
4. New ADMIN password
ML Worksheets and AWR data don’t get cloned

Automatic Indexing Easy cloning for testing Common right growing indexes
and index contention tackled.
Additional Causes for Contention Considered and Tackled
✓

• For workload of > 16 CPU the COLOCATION_TAG can be used to co-locate workload.
• The COLOCATION_TAG parameter is an alphanumeric string
– used with the CONNECT_DATA parameter of the TNS connect string.
(DESCRIPTION=(CONNECT_TIMEOUT=120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(AD
DRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=somehost-scan.exadatasubnet.ocivcn.oraclevcn.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=ATPDB1_tp.atp.oraclecloud.com)
(COLOCATION_TAG=interactive)))
• When set, it attempts to route clients with the same COLOCATION_TAG to the same database instance.
• Colocation of sessions on the same instance can help decrease inter-instance communication and
thereby increase performance for workload that benefits from being executed in the same instance.
Colocation of workload

29
Self
Rapid Provisioning
Self Scaling
Automatic Tuning
Automatic Indexing
Self
Self Patching
Auditing
Self
Self Healing
Software
Architecture

Self-Securing | Self Patching
Automatic Patching of all components (on-demand for critical security issue)
– Firmware, OS, Hypervisor, Clusterware, Database
Patches applied in a rolling fashion across RAC nodes and Exadata storage servers
– Database is continuously available to application
– Applications using Application Continuity best practices, run without interruption
Patching is automatically scheduled
– Customer can adjust patching window within a time range on Dedicated deployments
Oracle Cloud patches thousands of systems in a day
– Scale of patching has driven huge improvements in automation and reliability

Oracle RAC–based 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

32
But Remember, In the Cloud… Security Is a Shared Responsibility
Security Managed
by Oracle
• Network security and monitoring
• OS and platform security
• Database patches and upgrades
• Administrative separation of duties
• Data encryption by default
Security Managed by
the Customer
• Ongoing security assessments
• Users & Privileges
• Sensitive data discovery
• Data protection
• Activity auditing
Self-Securing | Separation of Duties

DBMS_SERVICE Placement Policy Support to avoid SRVCTL

34
Self
Rapid Provisioning
Self Scaling
Automatic Tuning
Automatic Indexing
Self
Self Patching
Auditing
Self
Self Healing
Software
Architecture

Self-Repairing | Self-Healing Hardware
• Database Infrastructure for
Autonomous is provided by Exadata
• Exadata provides advanced predictive
failure detection capabilities
– Proactively detect hardware failure
– Migrate customer off failing H/W
• Unique detection of server failures without
a long timeout avoids system hangs
• Unique sub-second redirection of IOs
around sick devices avoid database hangs
Example: Continuously monitors for sick devices
35
Failing disk is automatically
taken offline and database
activities directed to mirror
DevOps notified and fail drive
is replaced
Automatically detects
change in disk latency
ASM automatically rebalances
data off of failing disk to create
additional mirror
ASM automatically detects new
disk and rebalances data to
create additional mirror

• A proactive and automatic monitoring and correction framework
– Some functionality first introduced in Oracle RAC 12c
– Framework first used in Oracle RAC 18c with further enhancements in 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
Innovation on the Way to the Autonomous Database
Introducing Database Reliability Framework (DRF)

37
Automatically detect problems/issues:
1. Collect diagnostics info to establish
an anomaly timeline or signature
2. Use Pattern Recognition to determine
if it’s a known problems
3. If known problem
a. Explain what will be done to fix
b. Save environment checkpoint
c. Apply Fix and do root cause analysis
d. Roll back fix if required
4. If a new problem
a. Package up all diagnostic information
b. Hand off to DevOps
Collect Scrubbed
Logs, Traces
Problem
Repository
Determine if it’s a known
Problems using pattern
recognition
Save environment
check point
Apply FixRoll back if
necessary
Package
for
DevOps
Done!
Unknown
Known
ResolvedUnresolved
Problem Occurs
Self-Repairing | Self-Healing Software

Self-Repairing | Maximum Availability Architecture
• High Availability - Protection from
hardware failures, software crashes, patches, updates
• Uses RAC Database, redundant compute, networking,
triple mirrored storage, and daily backup
• Disaster Recovery* –
Adds protection from site outages and data corruptions
• Uses Active Data Guard Standby*
• Service Uptime SLA per Month: 99.995 NRX% *
(NRX = No Ridiculous Exclusions)
• 99.995% Uptime = at most 2m 12s of downtime per month
• Goal is for application impact to be
well under 30 seconds from any given availability event
Primary Database
Region #1, AD #1
Region #1, AD #2
Standby Database
Active
Data Guard
Backup
Service
* Coming soon in ATP-Dedicated

Application Continuity – Standard for ATP-D
Pre-configured Services offered by the Oracle Autonomous Database

Application Continuity – Standard for ATP-D
https://www.oracle.com/technetwork/database/options/clustering/applicationcontinuity/continuous-service-for-apps-on-atpd-5486113.pdf

• Session parameters, module name, and module action can be set through the CONNECT_DATA in an
Oracle connect string. For example, connecting as
(DESCRIPTION=(CONNECT_TIMEOUT=120)(RETRY_COUNT=20)(RETRY_DELAY=3)
(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=somehost)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=ATPDB1_tp.atp.oraclecloud.com))
(SESSION_SETTINGS=(param=val))
(MODULE_NAME=mname)(MODULE_ACTION=maction))
• will result in a session with module name set to mname, module action set to maction, and the
parameter named "param" set to val.
• The value of SESSION_SETTINGS should be a single level list; I.E. only (name=value) pairs with no nested
lists (SESSION_SETTINGS=(param1=val1)(param2=val2)...). The parameters are set via "alter session set
setting=value", run as the logging in user, so are constrained by all the restrictions that implies.
– Logon triggers are executed after setting the parameters and hence can override the values set.
Connect_Data SESSION_SETTINGS

Summary | Autonomous Database + Oracle RAC = Great Team
Spend Less
• Eliminate tedious, expensive, and unsafe manual database management
Innovate more
• Develop new applications faster with instant database provisioning and self-tuning
Ensure data availability
• Continuous online updates and availability
• Fault-tolerant solution – including maintenance

Oracle RAC 19c - the Basis for the Autonomous Database

Oracle RAC 19c - the Basis for the Autonomous Database

Recommended

More Related Content

What's hot (20)

Similar to Oracle RAC 19c - the Basis for the Autonomous Database (20)

More from Markus Michalewicz (20)

Recently uploaded (20)

Oracle RAC 19c - the Basis for the Autonomous Database