Webinář, 22.9.2016 Prezentoval Patrik Plachý, Oracle

1. Copyright © 2015 Oracle and/or its affiliates. All rights reserved.
Oracle Database Disaster Recovery to Cloud
Patrik Plachy
Senior Consultatnt, CoreTech Competency Center
September 2016

2. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Why You Need Disaster Recovery Plan ?
• Avoid Single Point of Failure
• Prevent Data Loss
• Reduce Downtime Cost & Revenue
Impact for Planned & Unplanned
Outages
• Disaster and Data Protection for
Compliance & Regulatory Purposes
Business Continuity

3. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Typical Challenges with Disaster Recovery Deployment
• Complexity in deployment and management
• It takes time for planning & deployment of DR
• Cost associated with CAPEX / OPEX for
maintaining another data center and standby
• Keeping up DR site’s resources with production
• On-demand elasticity after failover / switchover
• Return on investment challenges
• Lack of data protection when deploying storage
replications based DR
3

4. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Challenges Addressed: Oracle Database DR to Cloud
• Technologies Used
– Oracle Database Enterprise Edition
– Data Guard (or) Active Data Guard features for
replicating changes and for data protection
– Oracle Public Cloud – Database Cloud Services /
Exadata Cloud Services used for cloud-based standby
database
• Engineering Validation
– Maximum Availability Architecture engineering team
4

5. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Active Data Guard
– Data Protection, DR
– Query Offload
GoldenGate
– Active-active replication
– Heterogeneous
Active Replica
Oracle Database Backup Service
– Backup to cloud
Enterprise Manager Cloud Control
– Site Guard, Coordinated Site Failover
Application Continuity
– Application HA
Global Data Services
– Service Failover / Load Balancing
RAC
– Scalability
– Server HA
ASM
– Local storage protection
Production Site
Flashback
– Human error correction
Oracle Maximum Availability Architecture (MAA)
5
On-Prem, Public Cloud, Hybrid Cloud
RMAN, Oracle Secure Backup,
Zero Data Loss Recovery Appliance
– Backup to disk, tape, or to cloud

6. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Note: A single DR copy may be multi-
purposed for different combinations of
the use cases described
SYNC
or
ASYNC
Data Guard &
Active Data Guard
Use Cases: Data Guard and Active Data Guard
Real-Time Data Protection and Availability for Oracle Database
New DB
Version
Standby First Patching,
Database Rolling Maintenance
Exact copy
of primary
Query & Report Offload
Open Read-Only
Snapshot
Standby
Convert to Test Database
(open read-write)
Single Command Refresh
Exact copy
of primary
Offload RMAN Backups
Exact copy
of primary
Disaster Recovery
Manual or Automatic Failover
Redo Far Sync,
GoldenGate Downstream
Exact copy
of primary
Source for thin snaps/clones
Exact copy
of primary
Extract offload, source for
GoldenGate ALO mode

7. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Data Guard and Active Data Guard Feature Sets
Data Guard (included with EE)
Data Protection with HA
• Zero or near-zero data loss protection
• Transparent – all datatypes, workloads
• Continuous data validation
• Detect silent corruption
• Automatic database failover
• Dual-purpose DR as test system
• Simple migrations and upgrades
• Oracle Enterprise Manager integration
Active Data Guard (Option)
Advanced Protection with High ROI
• Zero data loss at any distance
• Automatic corruption repair
• Auto-replay of inflight transactions
• Offload transport compression*
• Offload read-only workload
• Offload read-mostly workload
• Offload fast incremental backups
• Automation for rolling upgrades
* Also requires Advanced Compression Option

8. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Data Guard Protection Modes
Mode Risk of data loss Transport If no acknowledgement from standby:
Maximum
Protection
Zero Data Loss
Double Failure
Protection
SYNC
Stall primary until acknowledgement is
received from replica
Maximum
Availability
Zero Data Loss
Single Failure
Protection
SYNC
FASTSYNC
Far Sync
Stall primary until acknowledgement is
received or timeout threshold period expires –
then resume processing
Maximum
Performance
Potential for
Minimal Data Loss
ASYNC
Primary never waits for standby
acknowledgement
(Suitable for Cloud DR)
Balance Data Protection with Performance and Availability

9. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Virtual Image
VM + DB + Disk Image
• Similar to Azure image or AMI
• Full distribution extracted on disk
• Same as on premise hosts
• Customer manages their database
Database Cloud Service
VM + DB + Full Provisioning
• Backup/recovery automation
• Patching and upgrade automation
• Data Guard setup
• Monitoring & management portals
• Local management console
Oracle Database Cloud Services - Offerings
• Oracle Linux 6.4
• On-demand storage & compute
• Choice of editions SE1, EE and Database 12c 12.1.0.2, and 11g 11.2.0.4
• Bundles: EE High Performance (most options), EE Extreme Perf (all options)
• Full network, VM and OS isolation, Full SQL*Net access
• Self-managed with SSH access into VM with root privilege
Database as a Service
Full Database Instance Service

10. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Hybrid Cloud: DR to Cloud
• DR to Cloud for Databases
– On-premise Primary  OPC Standby (PaaS)
– Using Data Guard or Active Data Guard
– Manual do-it-yourself model (Customer
Managed)
• Validation Process
– MAA with OPC team validated end-to-end
deployment procedure
• Delivered
– MAA Technical Paper published*
– Scripts & some level of automation provided
10
(Active) Data Guard
On-Premises
Primary Database
Oracle Cloud
Standby Database
Sandbox Test/Dev in
the cloud
Reporting
* http://www.oracle.com/technetwork/database/availability/dr-to-oracle-cloud-2615770.pdf

11. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Customer Benefits: Cloud-based Disaster Recovery Site
• Huge CAPEX & OPEX savings
– No need to maintain DR infrastructure
• Instantaneous availability of DR site
– No need to wait for months
• DR for compliance & regulatory purposes
– Physically remote location with data protection
• Use standby in the cloud for DR and also
reporting and testing
– Multiple use cases with DR site
• Short and long time DR site
– Commission or de-commission on-demand
11

12. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
General Hybrid DR Considerations
• Service Level Agreements
– RTO and RPO
– Latency between on-premises and Oracle
Public Cloud
• Network Security
– End-to-end data encryption
– Key management
• Standby encryption at rest
• Management of Standby database using
cloud portal
• Database & Application layer failovers
12

13. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• Database Versions
– Oracle Database EE 11.2.0.4 or above
– Oracle Database EE 12.1.0.2 or above
• Platform (64-bit)
– Generic Platform:Linux, Windows, Solaris-X86
– Exadata: Linux
• If using Active Data Guard based DR
– On-premises to be licensed for Active Data
Guard
• Database Versions
– Oracle Database 11.2.0.4 – Enterprise Edition
– Oracle Database 12.1.0.2 – Enterprise Edition
• Platform (64-bit)
– Generic : Linux
– Exadata: Linux
• Minimum DBCS Subscription
– Data Guard: Enterprise Edition
– Active Data Guard: Extreme Performance
Edition (DBaaS or Exadata Cloud Service)
• Automated (Production) / Virtual Image
(Evaluation)
13
DR to Cloud: Supported Environment
Standby Site in the CloudPrimary Site On-Premises

14. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• Using Data Guard
– Instantaneous remote DR Site in the
cloud
– Use cloud-based Standby for
temporarily testing the data by
converting to read/write
– Offload regular backups from standby
– Use cloud-based Standby for standby-
first patching, rolling upgrades
• Using Active Data Guard
(in addition to Data Guard use cases)
– Use cloud-based Standby for read-only
workloads
– Repair on-premises primary corrupted
blocks automatically from standby
– Offload fast backups from standby
– Create many standby databases with
real-time cascading (12c)
– Application continuity (12c)
– Advanced database rolling upgrade
features (12c)
14
DR to Cloud: Use Cases

15. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
DR to Cloud: Lifecycle
Subscription
& Licensing
Pre-paid DBCS
Subscription
On-premises Active
Data Guard licensing
Cloud Service
Creation
Instance creation
Automated or
Virtual Image
Extreme
Performance
Network
Configuration
Cloud-side SSH
Restrict IP address
access
Create listener port
On-premises
network security
Enabling
Security
On-Premises
SQL*Net
TDE encryption
(optional)
Instantiate
Standby
From on-premises
Using RMAN
DUPLICATE
Using Oracle
Database Backup
Service
Runtime
Management
Health Check /
Monitor Lags
Validate DR setup
Failover/Switchover
to Cloud
Use Standby for
reporting, testing
15

16. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• Database Cloud Service
– Up to 5TB usable capacity without
backups
– Up to 2.3TB usable capacity with
option to backup local in the cloud or
to Database Backup Service
• Exadata Service
– Larger databases
– Best Performance
– Option to backup to Database Backup
Service
16
1. Oracle Public Cloud: DBaaS

17. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
2. Service (Instance) Creation
• Choose Database Cloud Service
(Automated) for production
• Virtual Image can be chosen for
evaluation
• Provide the service / SID name
that you want for the standby
database
• Backup settings are optional
17

18. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
3. Cloud VM Instance Details
• Once the default instance is created,
IP address is assigned
• Default port 1521 is configured
– Has secured SSH access
– But access open to all IP addresses
• Database is created with instance up
& running
– This instance is not needed and to be
deleted
– This restriction will be removed once we
have automation
18

19. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
4. Cloud-side Network Settings
Procedure to create new listener
port
1. Create Security IP list
– Restrict access only to the on-premises
primary database’s IP address
2. Create a new Security
Application
– Define a new port #
3. Create a Security Rule
– For the standby database instance and
security IP list
19

20. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
5. On-Premises Network Settings
• Every customer site has different network security
requirements
• Network Administrator has to make sure
– Name resolution & Firewall Access Control List to the cloud IP (On-
Premises  Cloud)
– Ports are open ONLY to the cloud-side IP address (Cloud  On-
Premises)
– Prompt-less SSH between On-Premises DB server and Cloud VM
• Oracle environment settings
– Database must be running in ARCHIVELOG mode
– Standby Redo Logs (SRL) must be configured before Standby
instantiation in the cloud
– Recommended to use Data Guard Broker for easier deployment and
management
20

21. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
2. From the cloud backup1. From On-Premises production database
using RMAN ACTIVE DUPLICATE
21
Standby Database Instantiation in the Cloud
Oracle
Cloud
Standby
Database
On-
Premises
Primary
Database
On-Premises
Primary Database
RMAN
DUPLICATE
Oracle Cloud
Standby
Database

22. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• On-Premises Primary
1. Configure promptless SSH
2. Database must be in ARCHIVELOG
3. Size Online Redo Logs
4. Create Standby Redo Logs (SRL)
5. Set TCP socket size
6. Configure Oracle Net encryption
configuration
7. Configure tnsnames.ora, listener.ora
8. Perform Cloud Standby tasks
9. Run RMAN DUPLICATE command
10. Configure Data Guard Broker
• Cloud Standby
1. Delete the default database created
during instance creation*
2. Configure tnsnames.ora, listener.ora
3. Create Auxiliary Database init.ora and
password files
4. Start the instance in NOMOUNT
22
Standby Instantiation Directly From Production
* This step won’t be required for Virtual Image

23. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Instantiation from Production
Standby Database(s) on Oracle Public Cloud
DatabasesApplicationsClients
On-Premises (Production)
Firewall
Exadata
Cloud
Service
Dedicated
Compute
General
Purpose
DBCS
RMAN DUPLICATE
(Encrypted)
RMAN DUPLICATE
(Encrypted)
Oracle Public Cloud

24. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Instantiation from Database Cloud Backup
• Pre-requisite
– Backup from the on-premises database already exist in Oracle Cloud
• In the cloud VM
– Perform RMAN Oracle Cloud Module installation using same credential
– Set DBID (same as primary), decryption key
– Restore SPFILE
– Edit SPFILE and fix destination path, location, DB_UNIQUE_NAME,
db_file_name_convert, log_file_name_convert
– Restore standby control file
– Restore Database
– Configure Data Guard Broker
24

25. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Instantiation from Database Backup Cloud Service
Standby Database(s) on Oracle Public Cloud
DatabasesApplicationsClients
On-Premises (Production)
Database
Backup
Service
Firewall
Exadata
Cloud
Service
Dedicated
Compute
General
Purpose
DBCS
Oracle Public Cloud
RESTORE
RESTORE
RESTORE

26. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
• Primary Site (On-premises)
– Databases can be on physical systems
or virtual
– Database optionally encrypted
– Network ports open and configured
– Applications are available only on-
premises
– Secured log shipping
• Standby Site (Oracle Public Cloud)
– Standby database created on Database
Cloud Service – Automated / Virtual
Image
– Data Guard
• Enterprise Edition or above
• Used for testing
– Active Data Guard
• Extreme Performance
• Used for real-time reporting, testing
26
On-Premises  Cloud: Steady State Operation

27. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Database(s) on Oracle Public Cloud
DatabasesApplicationsClients
On-Premises (Production)
Database
Backup
ServiceFirewall
Database
Cloud
Service
Active Data Guard
(Encrypted)
Active Data Guard
(Encrypted)
Oracle Public Cloud
Reporting
Sandbox Test/Dev in
the cloud
DR to Cloud – Steady State

28. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Switchover / Failover to Cloud based Standby
• Standby in the cloud is activated for DR by either
– manually using documented procedure (or)
– automatically using Data Guard broker
• Applications from on-premises then access the standby in the cloud
• If failed over for DR, then the standby DB is used as production DB
• If using standby for standby patch-first, or rolling upgrades
– User follows the fully documented procedure
• If Active Data Guard is used, then the standby is opened read-only
– Reporting, backups and other read-only operations
28

29. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Standby Database(s) on Oracle Public Cloud
ApplicationsClients
On-Premises (Production)
Database
Backup
ServiceFirewall
Database
Cloud
Service
Oracle Public Cloud
Application Access – After Switchover

30. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Today: Self Service (DIY)
1. Disaster Recovery for
Databases
2. Standby-first Patching
(Switchover)
3. Rolling Upgrades
(Switchover)
4. Reporting
5. Testing
Future: Semi-Automated
1. Automating scripts
for certain complex
operations
2. Sandbox creation
(Cloning from
Standby for test/dev)
30
Future: Fully Automated
DRaaS
• Push button services
– Automate the whole
provisioning and
configuration process
– Sandbox creation
• Enable multiple DRaaS
use cases
• Full stack failover
(including Applications)
• Application Testing
Staged Roll-out of DR to Cloud

31. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Today: Self Service DIY
– Mostly customer driven,
hence no DR specific SLA
guarantees
– Cloud Database SLAs still
applicable
– Alert generation for
Transport lag, RPO exposure
– Estimate time required to
activate standby
Future: Hybrid DRaaS
– Automated process with
limited SLAs
– Cloud Database SLAs still
applicable
– Alert generation for
Transport lag, RPO exposure
– SLA for activating standby
31
Future: DRaaS in the Cloud
– Services offered by Oracle
– SLAs for RTO / RPO with
levels of service
• Gold, Silver, Bronze
– Fully automated with push-
button services
Service Level Agreements: Now & Future

32. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Considerations
• Application layer DR to cloud
– Application layers in OPC: JCS, BICS, Dedicated Compute (Future)
– Non JCS/BICS customers must connect their applications from on-premises
– Mitigation: DR for full-stack support planned
• Manual procedure of DR deployment
– Mitigation: Automation Planned
• Non availability of VPN
– Mitigation: VPN support planned for OPC
• Encryption
– Primary site has to be encrypted to support encrypted standby in the cloud
• High network bandwidth and low latency option with partners
32

33. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
DR to Cloud: Summary
33
Oracle Public Cloud for seamless DR deployment
Avoid single point of failure using DR
Cloud-based DR addresses compliance and
regulatory requirements
No separate DR site maintenance by customer
Cloud-based instance used for DR, testing &
reporting
On-demand resource elasticity in the cloud
No CAPEX
Instantaneous DR site

34. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Reference
• Maximum Availability Architecture
– http://oracle.com/goto/maa
• Data Guard / Active Data Guard
– http://oracle.com/goto/dataguard
• Oracle Public Cloud
– https://cloud.oracle.com/database
– https://cloud.oracle.com/database_backup
34

35. Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Q & A