Oracle Maximum Availability Best Practices Oracle Database 18

Oracle Maximum Availability Best Practices: Oracle Database 18 c Best Practices and Techniques Michael Smith Consulting Member of Technical Staff Oracle Database MAA October 25, 2018 Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 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, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 2

Agenda • MAA validated reference architectures and blueprints • MAA best practices and tips – Active Data Guard – Application Continuity – Multitenant – Golden. Gate – Sharding – Oracle Cloud Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 3

Oracle Maximum Availability Architecture (MAA) High Availability, Disaster Recovery and Data Protection • Applying 25+ years of lessons learned in solving toughest HA problems around the world Production • Solutions to reduce downtime for planned & unplanned outages for Enterprise customers with most demanding workloads and requirements Copy Database Replication • Service level oriented architectures • Books, white papers, blueprints • MAA integrated Engineered Systems • Continuous feedback into products R https: //oracle. com/goto/maa Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 4

MAA Reference Architectures Meet Downtime (RTO) and Data Loss (RPO) SLAs MAA Reference Architectures Topology BRONZE Single Instance + Backup Dev, Test, Prod SILVER HA Clustering + Backup Prod/Departmental GOLD HA Clustering + Disaster Recovery + Backup Mission Critical PLATINUM Zero Data Loss & Zero Downtime Extreme Critical Downtime & Data Loss Suitable Databases Addresses SLAs for Data Loss and Downtime during Planned & Unplanned Outages Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 5

Oracle MAA Designed to Address the Complete Range of Business Requirements Oracle Database On Premises On Cloud Common Platform – On Premises, Cloud, and Hybrid Cloud Big Differentiator Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 6

MAA Best Practices Active Data Guard Copyright © 2018, Oracle and/or its affiliates. All

Active Data Guard Best Disaster Protection, Real-time Failover, High ROI Primary Database Open Read-Write Primary Oracle Instance Active Standby Database Open Read-Only Oracle-aware Replication Continuous Oracle Data Validation Database Files Standby Oracle Instance Database Files Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 8

Data Guard Creation Best Practices • Fastest and easiest Data Guard deployment for your environment • New master MOS note that directs you to the best way to deploy a Data Guard standby • My Oracle Support Note 2275154. 1 – If you are 11. 2 use the standard RMAN DUPLICATE method – If you are 12. 1. 0. 2 or higher then use RMAN restore from service method – If you 12. 2. 0. 1 or higher and single instance use DBCA method (RAC in 18 c) Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 9

Data Guard Transport Best Practices • Learn to push ASYNC performance to provide near zero data loss • How to accurately determine transport lag • Diagnosing and tuning ASYNC transport – Network performance – Identify bottlenecks • Diagnosing reasons for ASYNC transport lag – Using AWR to assess peak redo rate can be misleading due to averages bring down the rate over longer period of time – Examine the time spent in each log to determine the peak redo rate on a finer level Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 10

Data Guard Transport Best Practices • Achieve zero data loss with minimal performance impact • Deep dive on SYNC performance tuning – Test results that illustrate performance gains when using best practices – For example, proper online log file sizes with a large banking customer improved performance by 30% – Frequent log switches force a checkpoint on the standby which results in increased I/O thereby affecting performance – Single member standby redo log placed on fast storage Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 11

Data Guard Transport Best Practices TIP • Benefit: Achieve zero data loss with minimal performance impact • The vast majority of Data Guard • Deep dive on SYNC performance tuning Transport performance issues can be – Test results that illustrate performance gains when using best practices attributed to frequent log switches – For example, proper online log file sizes with a large banking customer improved performance by 30% • Log switches should occur – Frequent log switches force a checkpoint on the standby which results in increased approximately every 15 minutes I/O thereby affecting performance – Single member standby redo log placed on fast storage Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 12

Data Guard Redo Apply Best Practices • Updated MAA Whitepaper • How to tune with examples for various scenarios – Tuning using top five wait events – Test results that illustrate performance gains when using best practices • New installation and usage instructions for using AWR with standby • New update that includes multi instance redo apply Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 13

Multi-Instance Redo Apply Performance • Scale redo apply and keep RTO low • Parallel, multi-instance recovery : standby will keep up – Standby recovery - utilizes CPU and IO across all nodes of RAC standby – OLTP workload tests on Exadata show great scalability 1400 Standby 1200 Apply 1000 Rate 800 MB/sec 600 400 200 0 OLTP Workload 1 Instance 2 Instances 4 Instances 8 Instances Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 14

Multi-Instance Redo Apply Performance • Benefit: Scale redo apply and keep RTO low TIP • Parallel, multi-instance recovery : standby will keep up • The vast majority of Data Guard Redo – Standby recovery - utilizes CPU and IO across all nodes of RAC standby Apply performance issues can be – Some of our OLTP workload tests on Exadata show great scalability attributed to frequent log switches 1400 Standby 1200 • Apply 1000 Rate 800 MB/sec 600 400 200 0 Increasing the number of OLTP Workload db_writer_processes can reduce high checkpoint wait events 1 Instance 2 Instances 4 Instances 8 Instances Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 15

Multi-Instance Redo Apply Enhancements • Multi-Instance Redo Apply allows all standby nodes to participate in recovery • In-memory DB (IMC) on Active Data Guard allows: * – Creation of IMC tables and columns for analytics on Active Data Guard – Population with different data than production database Month In-Memory – Offloading even more to your standby! Year In-Memory • Multi-Instance Redo apply also works with BCT * Available only on Exadata and Oracle Cloud Offerings Primary Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Standby 16

Data Guard Role Transition Best Practices • Updated MAA Whitepaper • Benefit: Reduced downtime for both unplanned and planned • Expected performance and tuning advice • How to assess your role transition timings and where the time is being spent Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 17

Preserve Buffer Cache During Role Change Read/Write Primary Read Active Data Guard Standby Read/Write Failed Primary • The database buffer cache state will be maintained on an ADG standby during a role change • Automatic, nothing to set up. – Except for init parameter on the standby – STANDBY_DB_PRESERVE_STATES Primary Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 18

Data Guard and No Force Logging* *Available on Engineered Systems and Oracle Cloud only • Extended to provide better support in an Active Data Guard environment without significantly increasing the amount of redo generated. • Two new modes are added as alternatives to the existing nologging mode – Standby Nologging for Load Performance • Ensures that standbys will receive the nonlogged data changes with the minimum impact to the speed of loading at the primary – The standby can transiently have nonlogged blocks. These nonlogged blocks will be automatically resolved by managed standby recovery. – Standby Nologging for Data availability • Ensures all standbys have the data when the primary load commits but at the cost of throttling the speed of loading data at the primary – The standbys will never have any nonlogged blocks. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 19

MAA Best Practices Application Continuity Copyright © 2018, Oracle and/or its affiliates. All rights

Applications see no errors during outages Standardize on Transparent Application Continuity Hides errors, timeouts, and maintenance Request No application knowledge or changes to use Rebuilds session state & in-flight transactions Errors/Timeouts hidden Adapts as applications change: protected for the future TAC Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 21

TAC Explained Normal Operation • Client marks requests: explicit and discovered. • Server tracks session state, decides which calls to replay, disables side effects. • Directed, client holds original calls, their inputs, and validation data. Failover Phase 1: Reconnect • Checks replay is enabled Failover Phase 2: Replay • Restores and verifies the session state • Creates a new connection • Replays held calls, restores mutables automatically • Checks target database is legal for replay • Ensures results, states, messages match original. • Uses Transaction Guard to guarantee commit outcome • On success, returns control to the application • Verifies timeliness New with TAC Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 22

Configuration at Database Service Attributes • FAILOVER_TYPE = AUTO • FAILOVER_RESTORE = AUTO • COMMIT_OUTCOME = TRUE • AQ_HA_NOTIFICATIONS=True for FAN OCI • REPLAY_INITIATION_TIMEOUT = 300 - seconds before replay is canceled Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 23

Connections Appear Continuous Standard for All Drivers from 12. 2 Configure in One Place Single description Automatic Retries alias =(DESCRIPTION = (CONNECT_TIMEOUT=90) (RETRY_COUNT=20)(RETRY_DELAY=3) (TRANSPORT_CONNECT_TIMEOUT=3) (ADDRESS_LIST = (LOAD_BALANCE=on) ( ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521))) (ADDRESS_LIST = No reliance on DNS (LOAD_BALANCE=on) ( ADDRESS = (PROTOCOL = TCP)(HOST=secondary-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME = gold-cloud))) ALWAYS use a SERVICE that is NOT DB/PDB name Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 25

FAN for INSTANT Interrupt The dead thing cannot tell you it is dead Auto-Configured in 12 c All Oracle uses FAN JDBC Universal Connection Pool OCI/OCCI driver ODP. NET Unmanaged Provider (OCI) ODP. NET Managed Provider (C#) DESCRIPTION = (CONNECT_TIMEOUT=90) (RETRY_COUNT=20)(RETRY_DELAY=3) (TRANSPORT_CONNECT_TIMEOUT=3) (ADDRESS_LIST = ONS Node Set 1 (LOAD_BALANCE=on) ( ADDRESS = (PROTOCOL = TCP) (HOST=primary-scan) (PORT=1521))) OCI Session Pool Web. Logic Active Grid. Link Tuxedo JDBC Thin Driver (new 12. 2) CMAN and Listeners (ADDRESS_LIST = ONS Node Set 2 (LOAD_BALANCE=on) ( ADDRESS = (PROTOCOL = TCP) (HOST=secondscan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=gold))) Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 26

Draining and Failover Locally – Switchover between sites Production Site RAC – Online Rolling Maintenance – Scalability – Server HA RAC One – Online Rolling Maintenance – Server HA Fast Application Notification – Notify draining, failover, load balancing TIP Transparent Application Continuity – Application HA Global Data Services – Cross Site Placement • Use AWR statistics to determine your level of protection • Drain Use Exa. Chk/Ora. Chk to view Drain within RAC unprotected calls Switchover ADG or GG Active Data Guard – Scheduled switchover – Data Protection, DR – Query Offload Data Guard – Scheduled switchover – Data Protection, DR Golden. Gate – Scheduled switchover – Active-active replication – Heterogeneous Sharding – Massive OLTP – Scheduled switchover – Active-active replication – Heterogeneous Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 27

Always Know Your Protection Level • AWR, system, session, service stats – Requests completed per second – User calls in request – Protected user calls Statistic Total per Second per Trans ---------------- --------- ------ cumulative requests 177, 406 49. 2 5. 0 cumulative user calls in request 493, 329 136. 8 13. 8 cumulative user calls protected 493, 329 136. 8 13. 8 Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 28

Detailed Protection Report when needed Copyright © 2018, Oracle and/or its affiliates. All rights

MAA Best Practices Multitenant Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

Oracle Multitenant Architecture for consolidating databases and simplifying operations AP GL OE Self-contained PDB for each application • • Portability (via pluggability) Rapid provisioning (via clones) Applications run unchanged PDB upgrades via plug/unplug PDBs Common operations performed at CDB level Root Shared memory and background processes • More applications per server CDB • Manage many as one (upgrade, backups, HA) • Granular control when appropriate • Simple DR MAA and Multitenant • Solutions for planned / unplanned outages Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 31

PDB Relocate • Provides the ability to move a PDB from one CDB to another with minimal downtime • Relocate is done in 2 phases • Phase 1: Copy datafiles from source to destination - No application downtime • Phase 2: Apply any redo that has occurred at source since phase 1 completion, quiesce the PDBs (downtime), open the new PDB • Downtime is a function of redo generated at source CDB - must be shipped & applied Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 32

PDB Relocate • With AVAILABILITY MAX clause allows deferral of changing connect strings • Apps connect via previous connect string to "tombstone" PDB left in previous CDB • Listener connection forwarding redirects connection to new location • When connect strings have been changed, drop the tombstone Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 33

PDB Relocate • With AVAILABILITY MAX clause allows deferral of changing TIP connect strings • Monitor MOS note 2049127. 1 for • Apps connect via previous connect string to "tombstone" PDB left in previous CDB improvements to PDB relocate which will reduces downtime • Listener connection forwarding redirects connection to new location • Remove source PDB to avoid extra • When connect strings have been changed, drop the network hop tombstone Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 34

Multitenant and Data Guard Enhancements • When performing a remote clone on a primary database the standby automates copying of the datafiles for the new PDB • On the standby CDB set the STANDBY_PDB_SOURCE_FILE_DBLINK initialization parameter. • This parameter specifies the name of the database link used in CREATE PLUGGABLE DATABASE. . . FROM dblink. • The standby CDB attempts to copy the data files from the source PDB referenced in the database link Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 35

MAA Best Practices Golden. Gate Copyright © 2018, Oracle and/or its affiliates. All rights

Oracle Golden. Gate Flexible Logical Replication LAN / WAN / Internet Over TCP/IP Source & Target Oracle & Non-Oracle Database(s) Bi-directional Target & Source Oracle & Non-Oracle Database(s) • Zero-downtime maintenance and migrations • Active-Active high availability • Heterogeneous replication, data distribution and integration Note: MAA for Golden. Gate Microservices Architecture is currently WIP Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 37

Micro. Services Architecture GGSCI Source Database Manager Admin Server Metrics Server Pumps Distribution Service Extract HTTPS RESTFul Service Interfaces GGSCI Metrics Server Collectors Receiver Service Trail Files Source Service Manager Admin Server Target Database Trail Files Service Manager Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Target Replicat

Microservices Architecture: Benefits • Cloud-ready Administration – Industry-standard communications protocol: HTTPS (Hypertext Transport Protocol Secure) – HTTPS: widely supported and permitted by firewalls – Industry-standard JSON (Java. Script Object Notation) wire-level data representation • Ease of maintenance – Can remotely issue commands to OGG; no need to logon to host servers – Role based authentication – Easier patching across multiple deployments and better security model – Multi-threaded version of Pump and Collector replacing multiple processes Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 39

Oracle Golden. Gate with RAC MAA Best Practices • Golden. Gate Microservices Architecture Configuration • Oracle Grid Infrastructure Bundled Agent (XAG) • DBFS or ACFS for shared Golden. Gate files (trails & checkpoint files) • Application VIP for target Golden. Gate environments • Updated MAA white paper • https: //www. oracle. com/technetwork/database/features/availability/maagg-microservices-on-rac-5073545. pdf Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 40

Oracle Golden. Gate MAA Performance Best Practices • Configure database STREAMS_POOL_SIZE – (# of integrated GG processes * 1 GB) + 25% head room • Use the automatic heartbeat table to monitor end-to-end latency • For integrated Extract/Replicat install and run Streams Performance Advisor (SPADV) – Shows process percentage split between idle, busy and waiting (flow control) • Use Golden. Gate Integrated Extract and Replicat Performance Diagnostic Collector (MOS note 2262988. 1) – Gathers required data for diagnosing performance issues by a single script. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 41

Oracle Golden. Gate MAA Performance Best Practices TIP • Configure database STREAMS_POOL_SIZE • Make sure you benchmark GG – (# of integrated GG processes * 1 GB) + 25% head room performance before going live with • Use the automatic heartbeat table to monitor end-to-end latency REAL data volumes and workload type • For integrated Extract/Replicat install and run Streams Performance Advisor (SPADV) • When implementing GG in an HA – Shows process percentage split between idle, busy and waiting (flow control) configuration, dedicate time to test • Use Golden. Gate Integrated Extract and Replicat Performance ALL failure scenarios Diagnostic Collector (MOS note 2262988. 1) – Gathers required data for diagnosing performance issues by a single script. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 42

MAA Best Practices Sharding Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

Oracle Database Sharding – Benefits Linear Scalability … Add shards online to scale transactions and concurrent users. Online rebalance. Fault Tolerant Geographic Distribution … No shared hardware or software to isolate faults. Shards may run different Oracle releases. User defined data placement for performance, availability, DR or to meet regulatory requirements. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 44

Deployment of a System-Managed SDB with Data Guard Shard Director shdir 1, 2 Region Availabilty_Domain 1 Shardgroup shgrp 1 Shard Catalog shardcat Primaries Clients Region Availability_Domain 2 Connection Pools … HA Standbys Connection Pools … Shard Director shdir 3, 4 Shard Catalog Shardgroup shgrp 2 shardcat_stdby Data Guard Fast-Start Failover Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 45

Oracle Sharding – MAA Outage Testing • Outage of Shard Catalog has no effect on application performance • Shard Keys are cached within the shard directors • MAA Best Practice is to protect catalog with Data Guard Maximum Availability Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 46

Oracle Sharding – MAA Outage Testing • Outage of shard directors does not affect a running connection pool • Connection pool caches range of shard keys / shards • MAA best practice to have 3 shard directors per region Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 47

Oracle Sharding – MAA Outage Testing Failover Performance • Failover of an individual shard does not affect application performance for remaining shards 4500 4000 3000 2500 Read/Write 2000 Read Only 1500 • Fast failover for both read / write and read only connections • Generic MAA best practices apply for sharded environments 1000 500 0 18: 12: 52 18: 12: 54 18: 12: 56 18: 12: 58 18: 13: 00 18: 13: 02 18: 13: 04 18: 13: 06 18: 13: 08 18: 13: 10 18: 13: 12 18: 13: 14 18: 13: 16 18: 13: 18 18: 13: 20 18: 13: 22 18: 13: 24 18: 13: 26 18: 13: 28 18: 13: 30 18: 13: 32 18: 13: 34 18: 13: 36 18: 13: 38 18: 13: 40 18: 13: 42 18: 13: 44 18: 13: 46 18: 13: 48 18: 13: 50 18: 13: 52 18: 13: 54 Transactions Per Second 3500 Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 48

Oracle Sharding – MAA Outage Testing Failover Performance 4500 4000 3000 2500 2000 • Fast failover for both read / write protected against data loss using DG and read only connections with SYNC transport (Max Availability) Read/Write Read Only 1500 • Generic MAA best practices apply for sharded environments 1000 500 0 18: 12: 52 18: 12: 54 18: 12: 56 18: 12: 58 18: 13: 00 18: 13: 02 18: 13: 04 18: 13: 06 18: 13: 08 18: 13: 10 18: 13: 12 18: 13: 14 18: 13: 16 18: 13: 18 18: 13: 20 18: 13: 22 18: 13: 24 18: 13: 26 18: 13: 28 18: 13: 30 18: 13: 32 18: 13: 34 18: 13: 36 18: 13: 38 18: 13: 40 18: 13: 42 18: 13: 44 18: 13: 46 18: 13: 48 18: 13: 50 18: 13: 52 18: 13: 54 Transactions Per Second 3500 • Failover of an individual shard does not affect application TIP performance for remaining shards • Shard catalog database must be Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 49

User-defined Sharding Explicit mapping of data to shards for better control, compliance & performance • Partition data across shards by RANGE or LIST – Ranges or lists of sharding key values are assigned to shards by the user Sharded Database User-defined shards on hybrid cloud • User-controlled data distribution provides: + Regulatory compliance • Data remains in country of origin + Hybrid cloud and cloud bursting • Some shards on premises; other shards in the cloud + Control of data availability for planned maintenance + Ability to customize hardware resources and HA configuration for subsets of data + More efficient range queries - User needs to maintain balanced data distribution Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 50

PDB Sharding Multitenant Support • In 12 c, a shard must be a non-CDB • In 18 c, a shard can also be a PDB – Only a single PDB-shard per CDB – CDB can contain other non-shard PDBs. – Support for multiple PDB-shards within a CDB is planned for future release • PDB sharding provides all manageability benefits of Multitenant … – database consolidation, manage many as one, database upgrades, relocation, etc. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 51

RAC Sharding High performance for shard-aware RAC applications • Affinitizes table partitions to RAC instances – Affinity gives better cache utilization and reduced block pings across instances Instance 2 Instance 1 P 2 Instance 3 P 3 • Takes advantage of data-dependent routing for sharding – Requests that specify sharding key are routed to the instance that logically holds the corresponding partition – Requests that don’t specify sharding key still work transparently • Gives RAC the performance and scalability of a Sharded Database with minimal application changes – Just add sharding key to the most performance critical operations; no changes to the database schema – alter system enable affinity <Table. Name>; RAC Database Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 52

MAA Best Practices Oracle Cloud Copyright © 2018, Oracle and/or its affiliates. All rights

MAA Evolution from On-Premises to Autonomous Customer Oracle • • • Infrastructure Management Architecture Configuration, Tuning Database Management Lifecycle Operations Application Performance Infrastructure Management Architecture Database Management Configuration, Tuning Lifecycle operations Application Performance • • • Architecture Database Management (Tooling) Configuration, Tuning Lifecycle Operations (Tooling) Application Performance On-Premises • • Blueprints Feedback to products & features Blueprints Exadata is the best integrated MAA DB platform • • Oracle owns and manages the best integrated MAA DB platform Cloud automation for provisioning and life cycle operations Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Choosing the SLA policy Application performance Autonomous Database Exadata Cloud On-Premises Exadata • • Oracle owns and manages Infrastructure Policy driven deployments MAA Integrated cloud Fully automated Self. Driving, Self-Securing, Self-Repairing Database 54

MAA Automation in the Cloud Database Deployment Made Easy Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Region #1 Primary Region #2 AD #1 Standby GOLD (DR) RAC Primary AD #2 DB Backup Service SILVER (HA) Single Instance SILVER (HA) BRONZE • MAA made easy • Simple UI / CLI / REST interfaces • Databases are provisioned with optimal parameter configurations Standby 55

Zero Data Loss with Minimal Performance Impact Exa. CS Primary / Standby in different regions SYNC Performance Impact 2500 1500 async fastsync FAST SYNC Redo Rate (MB/sec) 14. 93 14. 48 14. 39 Block Changes/sec (KB/sec) 96. 92 94. 3 93. 86 Txn Rate 2082 2025 2018 % Difference from ASYNC N/A 97% sync 1000 500 0 1 12 23 34 45 56 67 78 89 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298 Transactions Per Second 2000 ASYNC Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 56

Database Failover with Minimal Downtime Exa. CS Primary / Standby in different regions Failover Performance • Swingbench OLTP application performing mixture of inserts, updates, and deletes 4500 4000 2000 1500 1000 • Application redo rate of 15 MB/sec Database Failover - 8 Seconds 2500 FSFO Threshold - 6 Seconds 3000 Read/Write Read Only 500 0 18: 12: 52 18: 12: 54 18: 12: 56 18: 12: 58 18: 13: 00 18: 13: 02 18: 13: 04 18: 13: 06 18: 13: 08 18: 13: 10 18: 13: 12 18: 13: 14 18: 13: 16 18: 13: 18 18: 13: 20 18: 13: 22 18: 13: 24 18: 13: 26 18: 13: 28 18: 13: 30 18: 13: 32 18: 13: 34 18: 13: 36 18: 13: 38 18: 13: 40 18: 13: 42 18: 13: 44 18: 13: 46 18: 13: 48 18: 13: 50 18: 13: 52 18: 13: 54 Transactions Per Second 3500 • Fast Start failover in Maximum Availability mode, FSFO threshold configured for 6 seconds • Database failover time of 8 seconds Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 57

Database Failover • All Practices of Silver Plus TIP • Decision: • Setup Data Guard Fast-start Failover – Data Guard FSFO across ADs versus Data Guard FSFO across Regions (Site Failover) across ADs when you require existing Application Tiers to failover • Key Customer Actions transparently – Follow Application Checklist for Continuous Service for Data Guard Fast-Start Failover – Data Guard Fast-Start setup and tuning failover times is manual (refer to updated • Note: DNS + Complete Site Failover is Oracle Cloud MAA paper) required when failing over to a – Database Rolling Upgrade with Data Guard is also manual. Refer to generic MAA doc different region • Operational Practices – Test complete application + Data Guard role transitions Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 58

Planned Maintenance with Minimal Downtime Exa. CS Primary / Standby in different regions Switchover Performance • Swingbench OLTP application performing mixture of inserts, updates, and deletes 4500 4000 3000 2500 Read Write 2000 Read Only 1500 1000 500 0 18: 45: 52 18: 45: 54 18: 45: 56 18: 45: 58 18: 46: 00 18: 46: 02 18: 46: 04 18: 46: 06 18: 46: 08 18: 46: 10 18: 46: 12 18: 46: 14 18: 46: 16 18: 46: 18 18: 46: 20 18: 46: 22 18: 46: 24 18: 46: 26 18: 46: 28 18: 46: 30 18: 46: 32 18: 46: 34 18: 46: 36 18: 46: 38 18: 46: 40 18: 46: 42 18: 46: 44 18: 46: 48 18: 46: 50 18: 46: 52 Transactions Per Second 3500 • Application redo rate of 15 MB/sec • Application outage of 12 seconds during the switchover process • Total switchover time of approximately 40 seconds Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 59

MAA Evolution from On-Premises to Autonomous Customer Oracle • • • Infrastructure Management Architecture Configuration, Tuning Database Management Lifecycle Operations Application Performance Infrastructure Management Architecture Database Management Configuration, Tuning Lifecycle operations Application Performance • • • Architecture Database Management (Tooling) Configuration, Tuning Lifecycle Operations (Tooling) Application Performance On-Premises • • Blueprints Feedback to products & features Blueprints Exadata is the best integrated MAA DB platform • • Oracle owns and manages the best integrated MAA DB platform Cloud automation for provisioning and life cycle operations Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Choosing the SLA policy Application performance Autonomous Database Exadata Cloud On-Premises Exadata • • Oracle owns and manages Infrastructure Policy driven deployments MAA Integrated cloud Fully automated Self. Driving, Self-Securing, Self-Repairing Database 60