Session ID:

Prepared by:

Remember to complete your evaluation for this session within the app!

11045

Disaster Recovery: Defining Business Requirements and Strategic Solutions

April 9th, 2019

Michael Rulf CTO Syntax

Agenda

• Key Perceptions• Causes of Downtime• Key Considerations• DR Solutions

• Backups & Archive Log Mode• Oracle DataGuard• EMC RecoverPoint• Oracle Database Backup Logging Recovery

Appliance

Syntax at a Glance

A pioneer ERP hosting and Disaster recovery provider with best of breed Private and Public Cloud offerings on AWS, OCI and Azure.

Focus on building long-term relationships with over 250 hosted in the Syntax Enterprise Cloud.

Oracle expertise tailored to your needs and delivered via our Consulting Solutions.

Syntax Global Capabilities

Office and Data Center Locations

Account Management & Sales Support

H

Phoenix, AZEdison, NJ

Montreal, QC

Germany

China

NO

N O

RA

CL

E A

PP

LIC

AT

ION

S

• Remote Managed Services• JD Edwards: EnterpriseOne, World• EBS, PSFT, Hyperion, OBIEE• Other Oracle and 3rd-Party Apps

• Application Managed Services• Application Development & Extension

• SOA and Fusion Development• Business Intelligence

• MS SQL Server• Windows Servers• Solaris, Linux, Windows, AIX

• Integrations

• DBaaS• PaaS• DRaaS• BaaS• IaaS

• Implementations & Upgrades• Project Management• Functional Support

TraditionalCloud

Solutions

Application Managed Services

Oracle ERP Cloud

Solutions

Associated Technologies

Consulting Solutions

OR

AC

LE

AP

PL

ICA

TIO

NS

Key Perceptions about Disaster Recovery• Requires expensive, redundant systems• Under-utilized standby resources• Lack of ROI until a disaster occurs• Lack of confidence that it will work when needed

Causes of DowntimeUnplanned

• Site failure• Cluster-wide failure• Server failure• Storage failure• Data corruption• Human error• System hang/slowdown

Planned

• System/DB Changes• Data Changes• Application Changes

Downtime Statistics

Key ConsiderationsRecovery Time Objective (“RTO”)

DefinitionThe maximum acceptable time to bring a system or application back to operational state after a failure or disaster.

Key Facts about DR• “40% of companies that experience a major disaster risk their business if they

cannot access their data within 24 hours” – Gartner• “93% of companies that lost their data center for 10 days or more went

bankrupt within one year” – National Archives & Records Administration• “After a major disaster an average company will lose at least 25 percent of the

daily revenue in the first six days” - Le Secretariat, La Convention Européenne

Key ConsiderationsRecovery Point Objective (“RPO”)Definition: The maximum tolerable period in which data might be lost.

An RPO of 8 Hours could mean you’d send the following email:

Backup Media & Archive Log ModePros:• No stranded hardware• Low cost• Simple to administer & manage

Cons:• Long RTO dependent on backup media.• May need to run through multiple

backups if using an incremental model.• Increased RPO dependent on log

rotation rate.• Typically all local so logs may not

survive a site failure

Oracle Data Guard• Provides the management, monitoring and automation software to create and maintain

one or more standby databases to protect Oracle data from failures, disasters, human error & data corruption

• Consists of one production DB and one or more standby DBs (up to 30 in 11gR2) and may be geographically disperse

• Managing the primary and standby DBs can be done via SQL command line, Data Guard broker interface or a GUI such as Enterprise Manager

• Consistency maintained through redo data

Oracle Data GuardPhysical Standby

• Identical to primary at the block level

• Sync via Redo Apply• Can be open read-only for

real-time queries

Oracle Data GuardLogical Standby

• Same Logical data but physical organization & structure can be different• Synchronized via Redo Apply • Can be open read-only for reporting (11gR1)• Additional structures/schemas can be created to optimize the reporting

workload• Some restrictions on datatypes, types of tables, and types of DDL & DML

operations

Oracle Data GuardSnapshot Standby

• A Physical standby that is temporarily converted to an updatable standby and opened read/write

• Receives and archives redo data but does not apply while open for read/write• Typically diverges from primary over time• Good for development & testing purposes• Snapshot Standby added in 11gR1

Oracle Data Guard

IF: THEN:

• Very high primary DB throughput

• Simplicity of a physical replica

• Maximum protection from physical corruption

• Read-only access to offload workload

Physical Standby

• Simpler, one-way logical replication

• Standby requires local tables, additional schemas, indexes & materialized views

• Offload apps that need read-write access but does not modify primary data

Logical Standby

Physical vs Logical Comparison

Oracle Data GuardSummary

Pros:• Short RTO, can be real-time w/ synchronous option• Replication features part of standard DB license• Read-only access to DB w/ additional license• Simple to administer & manage

Cons:• Can not login to Apps in read-only mode• Additional solution required for Apps components• Stranded/underutilized target assets

Replication Outside Primary I/O Path EMC RecoverPoint• Provides synchronous replication

and continuous asynchronous bi-directional replication at the block level for both DB & Application tiers

• Continuous replication w/ optimization & compression to a maximum of 4 targets per source without incurring I/O load on the production volumes

• Preserves time-specific and application-specific bookmarks, enabling immediate recovery to any point in time without data loss.

EMC RecoverPointSummary

PROS:• Replicate using EMC RecoverPoint SAN Tap Technology locally & to different FEMA zones• No read/write penalty on prod LUNs to accomplish replication• Prod NEVER placed in hot backup mode to complete backups• Remote mirror written to tape; NO read / write penalty on prod LUNs during backup• Does not require Oracle Standby or Oracle Data Guard licenses• RPO / RTO = 0 Hours / 2 Hours• Supports both Fibre channel and IP-based storage platforms including 3rd-party storage solutions• No stranded or underutilized assets at target site• Provides a simplified clone process in addition to DR functionality

CONS:• Requires purchase of 2 devices for multisite replication, included on EMC arrays for local replication

Oracle Database Backup Logging Recovery ApplianceIncremental-forever and re-do log

• Uses incremental-forever in RMAN to do a “delta push”• Uses re-do log similar to Data Guard technology.• Enterprise Manager (Fusion Middleware) provides views of storage,

performance, consumption of incoming throughputs, histories of backups, copies done, and replications done. Template-driven policy application lets users easily click 100 databases and add them to one policy.

• Engineered Software – DBRLA Database is a “database of databases”, specialized engineered software. Not meant to be changed by clients. Built on Linux, it has algorithms for query and compression embedded.

Oracle Database Backup Logging Recovery Appliance

B

SummaryOracle Database Backup

Logging Recovery ApplianceProtected Databases

X X X

Database Delta PushIncremental ForeverRemove Backup Windows

Real-time Redo (like Data Guard)Minimize Data Loss

All Backup Processing OffloadedBoost Production Performance

Unified EM consoleEnable End to End Data

Protection Visibility

B

Replicate to Remote Appliance

Archive to tape

tape

Enterprise Manager (EM)

Cloned environment(s)

Database Delta StoreValidated & Compressed Backups

Scale Easily for Rapid Data Growth

SummaryOracle Database Backup Logging Recovery AppliancePROS:• RPO / RTO = 0 Hours / dependent on DB size• Offloads backup load to appliance thus reducing load on PROD volumes• Provides a simplified clone process in addition to DR functionality• Allows point-in-time recovery of data• No specified limit of source databases

CONS:• Requires purchase of an expensive EXA-like device• Database only solution, additional solution required for Apps components• Must restore back to an instance• RTO is the restore time based on on instance size to do RMAN restore• Announced but not yet released

Planning Considerations• What is the required business hours for your system?

– Drives RPO/RTO definition• Do you require multi-site replication?

– FEMA zones– Power grid

• Have you created a staffing plan?– Ongoing monitoring & management– Roles & responsibilities in a DR scenario

• Have you documented your policies & procedures– Backup Policy & Procedure– Recovery Policy & Procedure– Replication Policy & Procedure– Disaster Recovery Failover Policy & Procedure– Testing Plan– Business Continuity Plan

Session ID:

Remember to complete your evaluation for this session within the app!

11045

mrulf@syntax.com