HA, Scalability, DR & MAA in Oracle Database 21c - Overview

High Availability (HA), Scalability,
Disaster Recovery (DR) & MAA
In Oracle Database 21c – Overview
For the team: Markus Michalewicz
Senior Director of Product Management
Database HA, Scalability, DR, ZDM & MAA
January 20, 2021
@KnownAsMarkus
www.linkedin.com/in/markusmichalewicz
www.slideshare.net/MarkusMichalewicz

Announced on January 13, 2021
Oracle Database 21c
More innovations for developers & architects, analysts & data scientists, and DBAs
https://youtu.be/recR8UR13o8
2 Copyright © 2020, Oracle and/or its affiliates

Lead database software, infrastructure and cloud innovation
Objectives | Oracle Data Management
Database Cloud Services – Autonomous Database
• Automate everything – Free DBAs, developers, analysts to innovate
• Available everywhere – In public cloud or Cloud@Customer
Oracle Exadata
• Best for OLTP – Scale-out, fault-tolerant, persistent memory
• Best for Analytics – Smart storage, in-memory columnar
Oracle Database Software
• Fastest Innovation – Converged SQL database
• Safest - Most scalable, reliable and secure

For details see MOS Note 742060.1 – “Release Schedule of Current Database Releases”
Oracle Database 21c – Oracle’s First Innovation Release
Copyright © 2020, Oracle and/or its affiliates
• 2 years of Premier Support
• No Extended Support
• Great release to try new features
• Great release to develop apps
• 5 years of Premier Support
• 3 years of Extended Support
• Great release for production
Innovation Release Long Term Release

Projected Database Release and Support Timeline
• Innovation Release - 2 years of Premier Support, and no Extended Support
• Long Term Release - 5 years of Premier Support, and 3 years of Extended Support
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
18c Innovation
22c Innovation
21c Innovation
19c Long Term
23c Long Term
24c Innovation
Extended
Extended
(subject to change)
5

What’s New In Oracle Database High Availability 21c?
Integrated support for all focus areas
Application
Development
Database Cloud
(@Customer) Services
Zero Downtime
Migration
to Oracle Cloud
Converged Database
Maximum Availability Architecture (MAA)

Maximum Availability Architecture (MAA)
Reference
Architectures
Deployment Choices
HA Features,
Configurations &
Operational
Practices
Customer Insights &
Expert
Recommendations
Production Site Replicated Site
Platinum
Gold
Silver
Bronze
Replication
Data Protection
Flashback RMAN + ZDLRA
Continuous Availability
Application
Continuity
Global Data
Services
Generic
Systems
Engineered
Systems
DBCS
ExaCS/ExaCC
Autonomous DB
Active Replication
Active Data Guard GoldenGate
24
Scale Out
RAC Sharding
ASM

Exadata focus:
• Consolidation
• Platinum Tier MAA
with OGG & ADG
Multitenant integration:
• Simplified lifecycle
operations
• “Aurous” option
Oracle Cloud automation:
• Autonomous Data Guard
(AuDG)
• Active Data Guard for
ExaCC Gen 2
What’s New and Important for MAA with Oracle Database 21c?
8
Application Continuity (AC),
the “missing link”
• Critical component in all
Silver+ Ref. Architectures
• Part of Platinum tier
via ADG Standby

Oracle Cloud automation
Oracle Database 21c – Most Scalable & Reliable
9
Application Continuity (AC)
Multitenant integration
Exadata focus

10
Exadata focus

1. Oracle Multitenant Architecture is the standard going forward
• Oracle Database 19c is the last database version to support non-CDB architecture
2. Three Pluggable Databases can be used free-of-charge with Oracle Databases (EE / SE)
• https://docs.oracle.com/en/database/oracle/oracle-database/21/dblic/Licensing-Information.html#GUID-
0F9EB85D-4610-4EDF-89C2-4916A0E7AC87
• For all offerings, if you are not licensed for Oracle Multitenant,
then you may have up to 3 user-created PDBs in a given container database at any time.
3. Oracle Multitenant is a strong foundation for Consolidation and Optimized Lifecycle Management
Reminder: Three Facts About Oracle Multitenant
11

• Oracle Multitenant means self-contained,
Pluggable Databases (PDBs) providing
- Rapid deployment with Hot Clone
- Refresh / incremental refresh
- Relocation with no downtime
- PDB upgrades (using plug / unplug)
• PDBs enable transparent, simplified online
lifecycle operations for any application
• PDBs speed up database migration to
new container databases (in the cloud)
Oracle Multitenant
Architecture for database consolidation & optimized lifecycle operations
12
Pricing Retail
CRM

A Typical Database Lifecycle – Managed Online with Oracle Multitenant
Creation /
New
Version
Clone for
Testing
Clone for
Integration
Production
• Rapid deployment with Hot Clone
• Refresh / incremental refresh
• Relocation with no downtime
• PDB upgrades (using plug / unplug)

Multitenant Architecture-based Disaster Recovery
Flexible PDB Placement using Refreshable PDB Switchover
• Great HA and PDB flexibility. Good data protection & DR.
• Aurous Option is between silver and gold
• CDBs can host any PDB with varying SLAs
• For non-Critical, Business Critical and Mission Critical PDBs in the same CDB
• Business critical PDBs can fail over to another RAC instance
• Mission critical PDBs can fail over to remote PDB in another CDB
• Some advanced features not available such as
• read-only standby, automatic DR failover
and fast reinstate after role transition
Capability is very innovating but relatively new
• RTO=secs for HA and RTO < 30 mins for DR
• RPO for DR < 15 mins
“Aurous” MAA Option
14
Platinum
Gold
Aurous
Silver
Bronze

Multitenant Data Guard
Disaster Protection at the Pluggable Database (PDB) Level
• Protection on PDB or CDB level using real-time Apply
• No need to fail over a full Container Database!
• Switchover and failover capabilities with the broker on a single PDB
HR
Standby
HR
SALES
Standby
SALES
Container Database in Boston Container Database in New York
Data Guard Redo Transport and Apply
15

Better resource utilization across the cluster in an Administrator-managed environment
PDB placement choice FILL
• “Fill” attempts “fill up” nodes
PDB placement choice SPREAD
• “Spread” attempts to “spread the load”
Oracle RAC: Automatic PDB Resource Placement
16
0%
25%
75%
50%
100%
CPU
Utilization
0%
25%
75%
50%
100%
CPU
Utilization
X
+ Ranked Startup Order
+ Ordered failure handling

Dominant Approach for Scaling Internet Applications
Database Sharding
• Horizontal partitioning of data across
independent databases (shards)
– Each shard holds a subset of the data
– Can be single-node or RAC or PDB
– Replicated for high availability
• Shared-nothing architecture
– Shards don’t share any hardware (CPU,
memory, disk), or software (clusterware)
A single logical DB sharded
into N physical Databases
Server1
Database
Table1
Shard1
Server2
Table1
Shard2
Server3
Table1
Shard3
17

Oracle Sharding 21c Enhancements
Sharding Advisor Tool
• Assists in the process of migrating a non-sharded schema to a sharded one
• Analyzes non-sharded database schema and query workload
• Produces a ranked list of possible sharded database designs
optimized for query performance, scalability, availability, and storage
Create a Sharded Database from Multiple Existing Databases
• Simplifies migration of multiple databases based on the same application schema to a sharded architecture
• Creates a federated database capable of running cross-shard queries
18

Exadata focus
19

Application Continuity – Use Cases
Planned Maintenance
Uses response time,
throughput & capacity
Sessions rebalanced
RLB since 10.2
ALB in 19c (RAC only)
Unplanned Outages
Inflight work is drained
Schedule anytime
No more outages
For RAC, ADG & OGG
Since Oracle v10.2
Inflight work is replayed
Automatic
Correctness guaranteed
For RAC & ADG
Since Oracle v12.1
Load Balancing
Database Services and Fast Application Notification (FAN) are KEY!

Application Continuity
Choose the right flavor for your application
21
Transparent Application
Continuity
works with & without Oracle pools,
some decisions are made for you
Application Continuity
uses Oracle pools, customizable

ACchk
Reports the Protection Provided by Application Continuity
Disable Reason
ORA-41429: side effect detected

Reset Session State Between Requests with Oracle Database 21c
23
Applications use state in requests:
Temporary tables
PL/SQL globals
Cursors in fetch ….
New:
• Database resets state at end of request
• Next request starts with clean state
• Service attribute (RESET_STATE)

24
Exadata focus

Best Mixed Workload Performance, No Bottlenecks, Performance Isolation, Availability
Exadata for Consolidation and Database as a Service
25
• Smart storage offloads database servers
– Smart scan, columnar features, storage
indexes decrease the server and network load
– Improves consolidation density!
• Built-in consolidation support
– Network prioritization for OLTP
– Resource management of PMEM and flash
cache space, flash I/Os, disk I/Os
– Enables consolidation of mixed workloads
– Enables consolidation of production and
dev/test databases
– Not available from any other storage vendor!
Manufacturing
Marketing
Human
Resources
Engineering
Sales
Service
IT/Operations
Finance and
Accounting

Persistent
Memory In
Exadata X8M
Continuing Tradition of
State-of-the-Art Hardware

Speed of Persistent Memory For I/O-Bound Workloads
• Native Persistent Memory Store keeps database data
and redo in local Persistent Memory (PMEM)
• SQL runs directly on data stored in mapped
Persistent Memory file system
• Eliminates IO code path, no need for large buffer cache
• New database algorithms prevent partial or inconsistent
stores to Persistent Memory
• Scale-out using Native Database Sharding
• Protect Shards using Data Guard
Persistent Memory Store
DATA GUARD
27

Platinum Reference Architecture with Oracle OGG & ADG
28
Primary Region – West US
Secondary Region – East US
ProdA
ProdB
STBYA
STBYB
AD1 AD2
AD1 AD2
Read
Application Tier
Read/Write
Oracle GoldenGate (OGG) Replication
Active Data Guard (ADG) Fast-Start Failover
Sync Transport with Zero Data Loss
Read
Application Tier
Read/Write

Disaster Scenario: Loss of Entire Data Center
29
ProdA
ProdB
STBYA
STBYB
AD1 AD2
AD1 AD2
Read/Write
Application Tier
Read/Write
Read
Application Tier
Read/Write
Optional Client failover to ProdB
Automatic Data Guard Failover
Achieve eventual Zero Data Loss
by synchronizing replicas
Zero App and DB Downtime
with ProdB Replica

ProdA returns to Primary and STBYA+ to Standby
30
ProdA
ProdB
STBYA
STBYB
AD1 AD2
AD1 AD2
Read
Application Tier
Read/Write
Read
Application Tier
Read/Write
1. Reinstate failed system
2. Data Guard Switchover
to return to original state

31
Exadata focus

ExaCC Gen 2 Control Plane Support for Data Guard Disaster Recovery
32
Cloud Control
Plane
Primary
ExaC@C
Standby
ExaC@C
Data Guard
Redo Transport
• Real-time, database-optimized Disaster Recovery
• Ultra-low RTO, Zero RPO
• Cloud automation for “Create / Delete / Switchover / Failover / Reinstate”
• CLI-support to configure additional Data Guard attributes

Available today!
Maintains a real-time remote copy of a production database
• Protects from physical disasters, network outages
• Automatically switches from primary to remote copy
Maintains copy by applying physical changes
• Protects against database corruptions
• Validates data consistency as changes are applied
Fully Autonomous – Automates Everything
• Creation, operation, patching, backup, recovery
Provides replication but not active standby
• Cannot open stand-by to read operations at this time
• Currently restricted to availability domain (AD) failover
Oracle Autonomous Data Guard for Autonomous Database – Shared
33

Enablement
Autonomous Data Guard – Demo
34
Enabling Autonomous Data Guard

Available today!
• Oracle RAC Database, redundant network and storage, Active Data Guard standby
• Protection from hardware failures, crashes, corruptions, patches, upgrades, disasters
• Uptime Service Level Objective per Month: 99.995NRX% (NRX = No Ridiculous Exclusions)
• Move to an SLA with more integration features coming in future
• 99.995% Uptime = at most 2m 12s of downtime per month, commonly zero downtime
• Goal is for application impact to be well under 30 seconds from any given availability event
• Suitable for Business and Mission Critical production databases
Oracle Autonomous Data Guard for Autonomous Database – Dedicated
35
Primary Database
Region #1, AD #1 Region #2, AD #2
Backup
Service
Standby Database
Active
Data
Guard

Supported
Target
Cloud Services
Supported
Source
Platforms
Source
Databases
Inflight
Upgrade
Migration
Type
Migration
Methodologies
Non-CDB
to
CDB
Physical
Logical
RMAN
Data Guard
Data Pump
GoldenGate
11g, 12c, 18c, 19c
SE / EE DBCS BM / VM
ExaCS / ExaCC
ATP / ADW
Your complete solution for Database Migrations to Oracle Cloud
MAA-Compliant Zero Downtime Migration 21c
36

37
What if things go wrong?
Enhancements in Diagnostics

1. The root user can grant permission for specific users to be able to run checks as root
2. Once permission has been granted, when that user chooses to run as root the ORAchk
database checks are executed by the TFA daemon, which itself runs as root
3. Allowing any non-root user to run database checks, which would normally require root
access
Run all ORAchk database checks without root password
38

Run all database server checks without root password
39
tfactl access promote -user user_name -runasroot
As root user grant
permission to run root
privileged checks, for
non-root users:
tfactl access lsusers
Verify that the non-root
user has been
promoted by using:
Non-root user can run
root privileged checks
using the option:
1 2 3

PROS
• Stores Autonomous Health metrics for real-
time and post-mortem analysis
• Cluster Health Monitor (CHM)
• Cluster Health Advisor (CHA)
• DB QoS Management (QoSM)
• Default 72 hours of storage
• Minimized resource footprint
• Built-in Automatic Lifecycle management
• Automatic HA failover support
• No DBA management required
CONS
• Requires minimum 30GB of shared disk
• GI Patching and Upgrade integration requires
significantly longer maintenance window
• Only remote centralized solution required
new Member Cluster greenfield installation
The GIMR – Your Oracle Cluster Diagnostics Repository
40
12.1 12.2+ 18.1+ 19.1+ 19.5+ 21.1
Optional Mandatory Optional (New) ???

New 21c GI Management Repository (GIMR) Deployment Options
New Local Separate Home Default Option
• Dedicated DB Home installation – No user DBs
• Patched/Upgraded Separately after GI
• Separate GIMR Home directory owned by oinstall user
• Single RAC-enabled instance with HA failover
New Remote Centralized GIMR Service Option
• Centralized infrastructure cluster for GIMR Service
• Separate PDB-per-cluster architecture
• 1st Class GI Installation option
• Removes Local GIMR resource footprint
• 2-version backward and forward compatibility
Gridbase
GI Home
GIMR
DB Home
Local GI Deployment
Oracle Domain
Service Cluster
19c
Database
Cluster
21c
Database
Cluster
GIMR Service

1. Install the Oracle 21c Grid Infrastructure with Default GIMR Option.
• If using ASM, create a disk group for the GIMR (ex: MGMT)
2. Install an Oracle 21c Database Home in a separate directory as the GI User.
• Install on all nodes as you would an Oracle RAC database.
3. Create the GIMR Database
• OH/bin/mgmtca createGIMRContainer [-storageDiskLocation disk_location]
How To Install a Local 21c GIMR in 3 Steps
42

• PRO
• Destination for Important DB Events
• Single file to monitor by DBAs
• Many tools available to parse
• Supported by TFA for generating alarms
Oracle Database Alert Log – Enough?
43
• CONS
• Includes both critical and non-critical
events
• Incudes messages not intended for DBAs
• Inconsistently reports severity level
• Can report unintuitive cause and action
• New undocumented messages in every
release

1. Contains only important events requiring customer attention
2. Includes documented set of messages and attributes
3. All Messages include these attributes:
• Type
• Urgency
• Scope
• Target User
• Cause and Action
• Additional debug information
The Curated Solution – New 21c Attention Log
44

45
SCOPE
1. Session
2. Process
3. PDB-Instance
4. CDB-Instance
5. CDB-Cluster
6. PDB-Persistent
7. CDB-Persistent
TYPE
1. Error
2. Warning
3. Notification
Attention Log Curation - Message Attributes
URGENCY
1. Immediate
2. Soon
3. Deferable
4. Info
TARGET USER
1. App-Dev
2. Sec-Admin
3. Net-Admin
4. Cluster-Admin
5. PDB-Admin
6. CDB-Admin
7. Server-Admin
8. Storage-Admin
9. DataOps-Admin

Example Attention Message Definition – CDB Warning
46
// TYPE - 1 error, 2 warning, 3 notification
// URGENCY - 1 immediate, 2 soon, 3 deferable, 4 info
// SCOPE - 1 session, 2 process, 3 pdb-instance, 4 cdb-instance, 5 cdb-cluster, 6 pdb-
persistent, 7 cdb-persistent
// TARGETUSER - 1 app-dev, 2 sec-admin, 3 net-admin, 4 cluster-admin, 5 pdb-admin, 6 cdb-
admin, 7 server-admin, 8 storage-admin, 9 dataops-admin
ID::2000
TYPE::2
URGENCY::1
SCOPE::4
TARGETUSER::6
TEXT::Parameter %s specified is high
CAUSE::Memory parameter specified for this instance is high
ACTION::Check alert log or trace file for more information relating to instance configuration,
reconfigure the parameter and restart the instance
STARTVERSION::21.1

Thank you
Markus Michalewicz (Markus.Michalewicz@oracle.com)
Senior Director of Product Management
@KnownAsMarkus
www.linkedin.com/in/markusmichalewicz
www.slideshare.net/MarkusMichalewicz

Our mission is to help people see
data in new ways, discover insights,
unlock endless possibilities.

HA, Scalability, DR & MAA in Oracle Database 21c - Overview

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à HA, Scalability, DR & MAA in Oracle Database 21c - Overview

Similaire à HA, Scalability, DR & MAA in Oracle Database 21c - Overview (20)

Plus de Markus Michalewicz

Plus de Markus Michalewicz (18)

Dernier

Dernier (20)

HA, Scalability, DR & MAA in Oracle Database 21c - Overview