Oracle 12c ADG

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 © 2014, Oracle and/or its affiliates. All rights reserved. | 2

Oracle Active Data Guard
Best Practices and Deep Dive
CON7535
Larry M. Carpenter
Master Product Manager
High Availability Systems Group
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |

Program Agenda
Introduction
Data Guard Broker Enhancements
Configuring for Long Distance Zero Data Loss
DML on an Active Data Guard Standby
In Conclusion

Oracle Data Guard
Best Data Protection and Availability for Oracle Databases
Data Guard
All instances open read-write
SYNC / ASYNC
Primary Standby
Database Database
Data Guard Broker

Oracle Enterprise Manager
Oracle Data Guard 12c
Still the Best Data Protection and Availability for Oracle Databases
Data Guard
All instances open read-write
SYNC / ASYNC
Multitenant Multitenant
Primary Standby
Database Database
Data Guard Broker

Oracle Enterprise Manager
Oracle Data Guard and Multitenant
A Quick Note
• Redo generation is at the Container (CDB) level

– Not the Pluggable (PDB) level
• Hence Data Guard works at the CDB level also.

A Quick Note
• Redo generation is at the Container (CDB) level

– Not the Pluggable (PDB) level
• Hence Data Guard works at the CDB level also
• There are considerations when Cloning or
Plugging in PDBs at the Primary
– Depending on which one you are doing there will be
some things you might have to perform manually
at the Standby CDB to sort out the data files.

Cloning a PDB
• From the Seed PDB

– No problems. Redo Apply will automatically copy
the seed data files at the standby database
• From an Existing PDB at the Primary
– If the Standby is in Active Data Guard, no problems.
Redo Apply will automatically copy the PDB
data files at the standby database
– If the Standby is NOT in Active Data Guard then the
data files have to be manually copied at the standby
so the redo apply can find them.
• See MOS note on next slide.

Plugging in a PDB
• The PDB data files have to be present at the

Standby databases before you plug in the PDB
• However, like cloning with non-Active Data Guard
standby databases, care must be taken to ensure
that redo apply can find the files
• Full instructions and procedures can be found at:
– Step by Step Examples of Migrating non-CDBs and
PDBs Using ASM for File Storage (Doc ID 1576755.1)

Plugging in a PDB - 12.1.0.2
• New STANDBYS=NONE clause in 12.1.0.2

• Allows you to plug in a PDB at the primary
and defer the work at the standbys
– New PDB at standby is created with offline data files
– Redo apply keeps running, new PDB redo is ignored
– You sort out the data files at the standby
when ready to ENABLE RECOVERY
– Has no impact on Role Transitions
• Full instructions and procedures can be found at:
– Making Use of the STANDBYS=NONE Feature (Doc ID 1916648.1)
Data Guard
Capabilities Included with Oracle Database Enterprise Edition (EE)
Data Protection High Availability Performance and ROI

Zero or sub-second data loss Extreme throughput -
Automatic database failover
protection supports all workloads
Strong isolation using Dual-purpose standby for
Automatic client failover
continuous Oracle validation development and test
Lost-write detection Standby-first patch apply Data Guard Broker
Universal support – all data

Database rolling maintenance
types and applications
Comprehensive monitoring
Select platform migrations
with Enterprise Manager

Active Data Guard
Capabilities Included with the Active Data Guard Option
Data Protection High Availability Performance and ROI

Zero data loss at any distance Automatic block repair Offload read-only
Automated rolling database

Real-time cascade Offload incremental backups
maintenance
Transparent failover for in-
Offload read mostly
flight transactions1
Service management for Offload transport
replicated databases2 compression3
Intelligent load balancing for
replicated databases2
1 - Requires Application Continuity

2 - Requires Global Data Services
3 - Requires Advanced Compression

Program Agenda
Introduction
In Conclusion

New Data Guard Broker Features
• Improved Lag Monitoring and Warnings
• Validating Database Role Transition Readiness
• Switchover Enhancements
• Support for Far Sync and Cascading Redo destinations
• Configuration Analysis for Correctness
– Validating Future Database Topology
– Validating Far Sync Instance Configuration
• Fast Start Failover Enhancements

Our Starting Configuration
• Primary Database is Boston (BOS)
• Standby Database is San Francisco (SFO)
• Redo Transport is ASYNC

• Primary Database is BOS
• Standby Database is SFO
• Configuration Status is 

• Primary Database is BOS
• Standby Database is SFO
• Configuration Status
• Standby Status is 
– Also available are three
Lag Threshold Properties

Validating your Configuration’s Readiness
• New VALIDATE command
– Primary Database
– Standby Database compared to the Primary
– Far Sync Instance Configuration
• Performs a Health Check

• Check your Primary 

• Check your Primary
• Check your Standby 

• Check your Primary
• Check your Standby
• Fix and Validate again

Validate Database
• Automatically performs numerous health checks, including:
– Validates each database’s current status
– Verifies there are no archive log gaps
– Performs a log switch on primary to verify the log is applied on all standbys
– Shows any databases or RAC instances that are not discovered
– Detects inconsistencies between database properties and values stored in database
– Insures online redo log files have been cleared in advance of role transition
– Checks for previously disabled redo threads
– Ensures primary and all standbys are on the same redo branch
• VALIDATE DATABASE VERBOSE <name>; = A lot of information!

Switchover Enhancements
• Switchover can still be impacted by problems that occur in between the
time status is validated and the switchover command is issued
• In earlier releases, a failed switchover usually required the Broker
configuration to be deleted and re-created
• Data Guard Broker Resumable Switchover allows you the option to:
– Resolve the problem and re-issue Broker switchover – it picks up where it let off
– Use Broker to switch back to the original primary while you resolve the problem
– Use Broker to switch to another standby database in a multi-standby configuration
• Resumable Switchover also available in SQL*Plus environments

• A new 12.1.0.2 Switchover Enhancement
– Switchover from SFO to BOS
• Yes, for those of you paying attention, I already did a switchover from SFO to BOS!
– See anything new?

• A new 12.1.0.2 Switchover Enhancement
– Switchover from SFO to BOS
• Yes, for those of you paying attention, I already did a switchover from SFO to BOS!
– No more “_DGMGRL” Static Entries with Oracle Restart, RAC One Node or RAC!

Fast Start Failover (FSFO) Enhancements
• New FSFO Properties 
– Reconnect will log off and
log in again to check Primary
response capability.
– Override will force a failover if
the Observer loses connection to
the Primary even if the Standby
can still communicate with the
Primary database.

Fast Start Failover (FSFO) Enhancements
• New FSFO Properties
– Reconnect will log off and
log in again to check Primary
response capability.
– Override will force a failover if
the Observer loses connection to
the Primary even if the Standby
can still communicate with the
Primary database.
• New FSFO view
– V$FS_OBSERVER_HISTOGRAM
Frequency statistics of successful pings between the observer and primary

Additional New Properties
• Configuration Level
• PrimaryLostWriteAction 

• PrimaryLostWriteAction 
– CONTINUE or SHUTDOWN if a Lost
write is discovered on the Primary
– Can also force automatic failover
if in a FSFO configuration using
FAILOVER or FORCEFAILOVER

• PrimaryLostWriteAction
– Continue or shutdown if a Lost
if in a FSFO configuration.
• ExternalDestination1 & 2 

• PrimaryLostWriteAction
– Continue or shutdown if a Lost
if in a FSFO configuration.
• ExternalDestination1 & 2 
– Configure up to two downstream
capture destinations for
Oracle GoldenGate or ZDLRA

Data Guard Broker
• In Summary
– The Data Guard Broker
• Is the recommended Command Line Management Interface to Oracle Data Guard
• Is the underlying communication interface for Oracle Enterprise Manager Cloud Control
• Provides access to functionality that is not available at the SQL*Plus level
• Automates Database Services and Client Failover at Role Transition
• More Data Guard Broker Enhancements are discussed in the next section.

Program Agenda
Introduction
In Conclusion

Inter/Intra Continent Zero Data Loss Data Guard
• Everyone wants Zero Data Loss
• Everyone also wants geographic separation
• The problem is the two don’t mix very well
• Because Zero Data Loss requires Synchronous Transport Services
SYNC?
Boston San Francisco

Inter/Intra Continent Zero Data Loss Data Guard
• Everyone wants Zero Data Loss
• Everyone also wants geographic separation
• The problem is the two don’t mix very well
• Because Zero Data Loss requires Synchronous Transport Services
– The greater the distance, the larger the performance impact
Commit Ack Network Ack
Commit Network Send
Boston San Francisco

Enter Active Data Guard Far Sync
Zero-Data-loss protection at any distance
• Placed where Synchronous redo transport viable

– With acceptable production performance impact
• Lightweight
– No Data Files
– No Database
– No EE License
• Transparent
– Works like any other Data Guard redo destination

Sizing the Far Sync Server
• Disk required for Far Sync instance is negligible.
– Requires disk space for the Standby Redo Log files
– Space for archive log files sufficient to handle the largest gap you expect to happen.
• Memory parameters controlled per init file
• I/O speed of the SRL disks at the Far Sync is most important
– They need to be fast if the Primary generates a lot of redo per second.
• Redo to Terminal Standby can be compressed
– Will require more CPU and the Adv. Compression Option

Creating a Far Sync Instance
• Create a Far Sync control file from the primary
– ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS ‘<filename>’:
• Copy the parameter file used by the primary database
– Several parameters must be modified for the Far Sync Instance
• Create various directories at the Far Sync system
• Copy the control file, init file and password file to the Far Sync system
• Start the Far Sync Instance
– Create an SPFILE and restart to use the Broker
• Set up TNSNAMES and Redo Transport

• We have
ASYNC
BOS SFO
• We want BOSFS1
BOS SFO
BOSFS1

Adding a Far Sync Instance
• Our Configuration 

• Our Configuration
• Add the Far Sync

• Updated Configuration 
– Still disabled so no redo

• Updated Configuration
– Still disabled so no redo
– By default if it is enabled it will
automatically begin to receive
redo from the Primary but not
send it anywhere.
– So it needs to be properly configured
before enabling as a best practice

• Updated Configuration
– Still disabled so no redo Enter
– By default if it is enabled it will
automatically begin to receive RedoRoutes
redo from the Primary but not
send it anywhere.
– So it needs to be properly configured
before enabling as a best practice

A Powerful New Broker Property - “RedoRoutes”
• LogXPTMode said “How the Primary should ship redo to me”
– Still the default in a Broker configuration
• RedoRoutes says “When, Where and How ‘I’ should ship redo”
– Ship when I am the Primary - Normal redo transport
– Ship when I am a Standby - Far Sync and Cascading redo transport
• When someone else is the Primary
• Comprised of multiple sets of Redo Source, Redo Destination, Mode
– (When : Where How, Where How, Where How)
• When - Defaults to ‘Me’ or ‘LOCAL’ (i.e. I am the primary)
• Where - Defaults to all (ALL) standby destinations
• How - Defaults to LogXPTMode

Our Interim Configuration
• We are now here
ASYNC
BOS SFO
BOSFS1
(idle)
• Default RedoRoutes is blank 

Set up the Initial RedoRoutes
• The configuration is using the defaults

• The configuration is using the defaults
• Change BOS and SFO to use RedoRoutes

• Now we’re using RedoRoutes 

• Now we’re using RedoRoutes
• Setup our Far Sync to also use RedoRoutes

• Now we’re using RedoRoutes
• Setup our Far Sync to also use RedoRoutes
• Finally enable the Far Sync 

Begin Using the Far Sync
• Go from  ASYNC
BOS SFO
BOSFS1
(idle)

• Go from  ASYNC
BOS SFO
BOSFS1

• Go from ASYNC
BOS SFO
BOSFS1
• To 
BOS SFO
BOSFS1
(active)
Our New Configuration
• Boston sends redo to
the Boston Far Sync
who forwards the redo
to San Francisco 

Increase the Protection Mode
• Now that we have a SYNC
destination we can operate in
Zero Data Loss (ZDL) mode
and do ZDL failovers from
BOS to SFO

Zero Data Loss mode
BOS to SFO

Zero Data Loss mode
BOS to SFO

Finish the Picture
• We need a Far Sync in San Francisco so we stay at Maximum Availability
after a role change.

Finish the Picture
– Create the SFO Far Sync as before and add it in, as before

Finish the Picture
– Create the SFO Far Sync as before and add it in, as before
• Got that?

Ready For Anything
• Everything is now up and running

Our New Configuration
• One Far Sync is always idle
BOS SFO
BOSFS1 SFOFS1
(active) (idle)

Switchover with Confidence
• No matter where the Primary is…

• No matter where the Primary is, you will always be in Maximum Availability



Our Switched Over Configuration
• One Far Sync is always idle
BOS SFO
BOSFS1 SFOFS1
(idle) (active)

Check Your Topology
• A new 12.1.0.2 SHOW CONFIGURATION Enhancement
• More on this later in the talk

What Happens if my Far Sync Fails?
• One failure and we’re toast?
BOS SFO
BOSFS1 SFOFS1
(idle) (active)

BOS SFO
BOSFS1 SFOFS1
(idle) (down)

BOS SFO
BOSFS1 SFOFS1
(idle) (down)

BOS SFO
BOSFS1 SFOFS1
(idle) (down)

BOS SFO
BOSFS1 SFOFS1
(idle) (down)
• Nope!
• With 12.1.0.2 and support for ALTERNATE destinations you’re safe!

Configure Far Sync Redirect
• You can automatically redirect redo directly to the Terminal Standby
ASYNC
BOS SFO
SFOFS1
(down)
• But this implicitly reduces you to Maximum Performance

– No longer possible to perform a Zero Data Loss failover to BOS
– Far Sync High Availability is the way to go!

Configure Far Sync for High Availability
• Create and add 2 more Far Sync Instances to your configuration
BOSFS2 SFOFS2
(idle) (idle)
BOS SFO
BOSFS1 SFOFS1
(idle) (active)
• One each in Boston and San Francisco

– BOSFS2 and SFOFS2 will become the alternates

• Requires MaxFailure be set on our current Far Sync Instances

• Requires MaxFailure be set on our current Far Sync Instances
• Causes the Alternate to be invoked at the first failure of the active Far Sync
• As before, Add in the two new Far Sync Instances



• Our Configuration Now.

• Enable the new ones

• Reconfigure RedoRoutes
of both Databases to
identify the Alternate



• We are ready for that failure!

• We are ready for that failure!

Disaster (small ‘d’) Strikes!
• Our active SFOFS1 Far Sync Instance Fails!
BOSFS2 SFOFS2
(idle) (idle)
BOS SFO
BOSFS1 SFOFS1
(idle) (down)

Disaster (small ‘d’) Averted!
• Our idle SFOFS2 Far Sync Instance kicks in!
BOSFS2 SFOFS2
(idle) (active)
BOS SFO
BOSFS1 SFOFS1
(idle) (down)

• All is well with our configuration

• All is well with our configuration

• The ORA-16764 Error?
• It’s correct, SFOFS1 is unreachable.



How Do We Get True High Availability?
• What happens if the SFOFS2 Far Sync Instance goes down now?
BOSFS2 SFOFS2
(idle) (down)
BOS SFO
BOSFS1 SFOFS1
(idle) (idle)

• By default it will not go back and we will be unprotected!
BOSFS2 SFOFS2
(idle) (down)
BOS SFO
BOSFS1 SFOFS1
(idle) (idle)

• You want it to go back to using SFOFS1 when restarted!
BOSFS2 SFOFS2
(idle) (down)
BOS SFO
BOSFS1 SFOFS1
(idle) (active)

Finalizing True High Availability
• Add the FALLBACK qualifier to RedoRoutes
– To the Primary SFO
Finalizing True High Availability
• Add the FALLBACK qualifier to RedoRoutes
– To the Primary SFO
– And the Standby BOS
Achieving True High Availability!
• With FALLBACK we just keep on shipping that redo!
BOSFS2 SFOFS2
(idle) (down)
BOS SFO
BOSFS1 SFOFS1
(idle) (active)
Validating your Far Sync Instances
• VALIDATE can also validate your Far Sync Instance Setup
• Validate one Boston Far Sync
• Validate one San Francisco Far Sync
• VALIDATE can also validate future Far Sync Instance Setup
• Validate a Boston Far Sync when San Francisco will be the Primary
• Validate a San Francisco Far Sync when Boston will be the Primary
Endless Data Protection and Distribution Possibilities
• Dual Site Symmetrical Setup (Triple ZDL Failover possibilities)
BOSFS2 SFOFS2
(idle) (idle)
BOS SFO
ASYNC
BOSFS1 SFOFS1
(active) (active)
BOSADG SFOADG
• Of course all the standbys above can be Active Data Guard enabled
Endless Data Protection and Distribution Possibilities
• Multiple Remote Reader Farms
FS4 FS2
(idle) (idle)
ASYNC
FS3 FS1
(active) (active)
A Final Note on RedoRoutes
• Remember a Local SYNC standby with a Remote ASYNC Standby?
ASYNC
SYNC
BOS SFO
SFOADG
• A Switchover between SFO and SFOADG, everything worked fine.
SYNC
BOS SFO
SFOADG
• But a move to the Remote ASYNC standby BOS wreaked havoc!
SYNC!
BOS SFO
SFOADG
• SYNC + WAN is not good for performance, you had to reset LogXptMode.
• With RedoRoutes it’s all Automatic now!
ASYNC
BOS SFO
SFOADG
• No more reconfiguration required!

Program Agenda
Introduction
In Conclusion
Writing to Global Temporary Tables (GTT)
Active Data Guard DML
• DML on global temporary tables now supported on Active Data Guard

– DDL to create temporary tables must be issued on the primary database
– Applications that are read-only but that require DML to global temp tables can be
offloaded to an Active Data Guard standby database
• Enabled by a new initialization parameter in Oracle Database 12c
TEMP_UNDO_ENABLED
– Separates undo for temporary tables from undo for persistent tables
• Hence any temporary undo is not logged in redo logs
– Set by default on an Active Data Guard standby database
Sequences
Extending GTT Usefulness
• Sequences now supported on Active Data Guard

– Applications have access to sets of unique identifiers
– Both Global and Session (new) sequences available
• Global - sequence is unique across all databases in the configuration
• Session - sequence is unique to a session
• DDL to create the sequence must be issued on the primary database
Global Sequences
Active Data Guard
• Sequences created using the default CACHE and NOORDER options can be
accessed from an Active Data Guard standby database
• When first accessed by the standby, the primary allocates a unique range of
sequence numbers
• When all sequences within a range have been used, the standby requests
another range of numbers
• Each range assigned to a standby is unique – thus there is a unique stream
of identifiers across the entire Data Guard configuration
Session Sequences
Active Data Guard
• A sequence specifically designed for use with global temporary tables that
have session visibility
– A unique range of sequence numbers only within a session
– Session sequences are not persistent - the state of the session sequences accessed
during a session is lost when the session terminates
• To create a session sequence:
SQL> CREATE SEQUENCE … SESSION;
Benefits: Temporary Undo and Sequences
Increase Return on Investment in Standby Databases
• Reporting and other applications that are generally read-only but require
non-persistent write access to the database can be run on an Active Data
Guard standby using global temporary tables
• Reduces redo volume if also enabled on the primary database
– Temporary undo is not logged in redo
– Improves primary database performance
– Reduce network bandwidth consumption - less redo for Data Guard to ship
– Less standby I/O
• Applications that are read-only and require generation of unique
sequences can be offloaded to Active Data Guard standby
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Program Agenda
Introduction
In Conclusion
Data Guard 12c New Features Summary
• Data Guard • Active Data Guard
– SYSDG Role for Data Guard specific operations – Real Time Cascading Redo destinations
– Multitenent Database Standbys – Wan Distance Zero Data Loss with Far Sync
– Default Real Time Apply – Global Temporary Table DML on a standby
– Transparent Online Data file movement – Sequences (global and session) on a standby
– Single SQL*Plus Switchover command – DBMS_ROLLING automated rolling upgrades
– No Primary instance shutdown for switchover – Support for Oracle Application Continuity
– FastSync (SYNC NOAFFIRM) – Support for Oracle Global Data Services
– Enhanced Extended Datatype Support for upgrades
– Logical Standby support for additional data types
– DBMS_SCHEDULER support for Rolling Upgrades
– Broker VALIDATE DATABASE capability
– Enhanced Broker configuring with RedoRoutes
– Broker Resumable switchover
– New Broker Observer properties and capabilities
– Broker support of Cascading Redo destinations
Resources
• Oracle Data Guard
– http://www.oracle.com/goto/dataguard
• Maximum Availability Architecture (MAA)
– http://www.oracle.com/goto/maa
• MAA Blogs
– http://blogs.oracle.com/maa
• Oracle Active Data Guard Far Sync - Zero Data Loss at Any Distance
– http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf
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.

Oracle 12c ADG

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle 12c ADG

Uploaded by

Copyright:

Available Formats

Safe Harbor Statement

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 2

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 4

All instances open read-write

Data Guard Broker

All instances open read-write

Data Guard Broker

• Redo generation is at the Container (CDB) level

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 7

• Redo generation is at the Container (CDB) level

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 8

• From the Seed PDB

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 9

• The PDB data files have to be present at the

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 10

• New STANDBYS=NONE clause in 12.1.0.2

Data Protection High Availability Performance and ROI

Lost-write detection Standby-first patch apply Data Guard Broker

Universal support – all data

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 12

Data Protection High Availability Performance and ROI

Automated rolling database

1 - Requires Application Continuity

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 13

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 14

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 15

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 16

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 17

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 18

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 19

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 20

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 21

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 22

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 23

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 24

– See anything new?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 25

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 26

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 27

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 28

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 29

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 30

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 31

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 32

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 33

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 34

Boston San Francisco

Commit Network Send

Boston San Francisco

• Placed where Synchronous redo transport viable

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 37

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 38

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 39

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 40

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 41

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 42

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 43

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 44

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 45

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 46

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 47

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | 48

• Change BOS and SFO to use RedoRoutes