NL 2014 4 Award Article PDF

SWISS ORACLE USER GROUP
www.soug.ch
Ne ws le t ter 4/2014
Oktober 2014
Data Guard in Oracle 12c

Adaptive Bitmap Pruning
Oracle RAC 12c
Oracle Net Encryption
TIPS&TECHNIQUES
17
Ludovico Caldara, Trivadis AG
Oracle 12C Data Guard:

Far sync, real-time cascade standby
and other goodies
Abstract
The new release of Oracle Database has come
with many new exciting enhancements for the High
Availability.
This whitepaper introduces some new Data Guard
features. Among various enhancements, special
attention will be given to the new Far Sync Instance
and the Real-Time Cascade Standby.
Target Audience
Real-time cascade standby

In some situations, customers may want to have cascading standby configurations, where the primary database
sends its redo stream to a first-level standby database (also
named cascading standby), and from this database forward
the redo stream to one or multiple second-level destinations
(also named cascaded standbys). This kind of configuration
can be handful, for example, to offload the primary database
when multiple standby databases are needed.
Previous releases of Oracle Data Guard had, however,
different limitations that were preventing customers from
implementing efficiently this kind of configuration:
This whitepaper is targeted at database administrators and architects who are familiar with Oracle
Data Guard concepts and want to know more about
the new 12c features.
Executive Summary
After reading this whitepaper, you should be
able to:
s2EVIEWTHEPRINCIPAL$ATA'UARDFEATURES
introduced with the release 12c
s$ISCOVERNEWREPLICATIONTOPOLOGIESAND
possibilities with Data Guard
s,ISTTHENEW$'FEATURESTHATREQUIRESPECIAL
Oracle Dataguard 11gR2 limitations
licensing

The Data Guard Broker wasnt able to manage cascaded

standbys.
The manual configuration of the redo destinations was
hard to implement, and manual interventions on the
initialization parameters were required to handle role
changes correctly.
ARCH transport was the only redo transport available
between the cascading and the cascaded databases:
the cascading database had to fill up the standby redo
logs before the archiver process could send the archive
stream, so the cascaded standby was always at least
one sequence behind the primary database.
SOUG Newsletter 4/2014
18
TIPS&TECHNIQUES
The new Oracle Data Guard 12c overcomes these limitations.
ROLE
ATTRIBUTE
RESULT
PRIMARY
SYNC
Old 11gR2 behavior
ASYNC
Old 11gR2 behavior
<none>
Same behavior as ASYNC
STANDBY
ASYNC
<none>
Use LGWR:
Real-Time Cascade ENABLED
USE ARCH:
Real-Time Cascade DISABLED
12c LOG_ARCHIVE_DEST_n attributes

Oracle Data Guard 12c overcomes these limitations
As an example, keep the following two configurations on
the same cascading, standby database:
The Data Guard Broker is now able to manage cascaded
and cascading standbys. You can now implement cascade
scenarios that span more than three levels (actually, Ive tested it with a four-level cascade).
Moreover, cascading standbys can now send the redo
stream immediately, as soon as it is received from the primary database. Its up to the LGWR process of the cascading
standby to forward the redo stream to the cascaded
standby(s), at the same time it also writes the standby redo
logs as it used to do.
This ability of forwarding the redo stream immediately to
the second-level destinations is called Real-time cascade
and its a new feature of the Active Data Guard Option. This
means that if the real-time cascade feature is used, all the
servers involved in the Data Guard configuration need to be
licensed with the ADG option.
The real-time cascade allows having the cascaded standby always up to date with the primary database, so the customers can now use a cascading standby to offload the primary database without increasing the gap between the
primary database and the destination databases.
Whether the real-time cascade feature is used or not, actually depends on the attributes in the parameter LOG_ARCHIVE_DEST_n of the cascading standby that control how
the redo stream is forwarded to the cascaded database. Beginning with Oracle 12c, the attributes LGWR and ARCH of
the LOG_ARCHIVE_DEST_n parameters are deprecated.
The only valid values are SYNC, ASYNC or none of them.
In particular, for a cascading standby (thus, for a DB in Standby Role), the only valid attribute for the transport is ASYNC,
meaning that synchronous transport from a standby database to another is not possible. If ASYNC is specified then
real-time cascade is used, if no transport attribute is specified, real-time cascade is disabled and the redo stream from
the cascading to the cascaded database is transported using
the archived logs.
1.log_archive_dest_2 = service="REP", optional reopen=300 net_timeout=30,

valid_for=(standby_logfile,all_roles)
2.log_archive_dest_2 = service="REP", ASYNC NOAFFIRM optional reopen=300
net_timeout=30, valid_for=(standby_logfile,all_roles)
In the first example, ASYNC is not specified; therefore the

real-time cascade is not enabled. In the second example
however, ASYNC is specified and the real-time cascade
feature is used.
Dealing with multiple databases may lead to having different configurations of LOG_ARCHIVE_DEST_n for the same
database. In the following example, we can see how the DR
database needs to change his archive destination depending
on which the primary database is, either PROD or REP.
In order to manage different role transition scenarios and

have the proper redo log routing between the different databases, Oracle has introduced the new Data Guard Broker
property RedoRoutes.
This new property specifies, for each database in the
configuration, where the redo stream must be redirected depending on which the primary database is.
The format of a redo route is the following:
(<primary database> : <destination> [<transport mode>]
[, <destination> [<transport mode>] [, ]] )
Where <transport mode> can be SYNC, ASYNC, FASTSYNC or none of them.
TIPS&TECHNIQUES
19
Example of a cascade standby

scenario
As for the parameter LOG_ARCHIVE_DEST_n, a standby

database can have only ASYNC transport mode in the property RedoRoutes, and depending whether its specified or
not, the real-time cascade feature is respectively enabled or
disabled. So take care: if you dont have a valid ADG license,
you should not specify ASYNC in either RedoRoutes or
LOG_ARCHIVE_DEST_n when configuring a cascading
standby!
One database can have multiple routes to support different scenarios. Take the following image as an example:
Start by implement traditional two-ways Data Guard architecture (details are missing as it is expected that you are
already comfortable with DG):
1. Put the primary database (PROD in this example) in
archivelog mode
2. Configure force logging to have more flexibility in case of
failover
3. Add a few standby redo log files
4. Prepare the TNS configuration, the static listener entry
db_unique_name_dgmgrl.db_domain and the password
file as usual, on all the involved nodes
5. Prepare a minimal pfile on the cascading site and start
the instance in nomount (lets call the instance DR).
6. Duplicate PROD database for standby to the DR
database
7. Create the configuration with dgmgrl:
dgmgrl> create configuration DGPROD as
PRIMARY DATABASE IS 'PROD' connect identifier is 'PROD';
8. Add the standby database to the configuration

dgmgrl> add database 'DR' as connect identifier is 'DR';
9. Enable the configuration

dgmgrl> enable configuration;
10. Verify that everything is working as expected

(e.g. try a switchover)
New RedoRoutes parameter
dgmgrl> show configuration;

dgmgrl> enable configuration;
Configuration dgprod
10.
Verify that
everything
is working as expected (e.g. try a
Protection
Mode:
MaxPerformance
Databases:
switchover)
You should infer that:

PROD database sends its redo stream to the DR
database when PROD is the primary (LOCAL is an
alternative label to specify the current database). In all
other situations it doesnt forward the redo stream.

REP database sends its redo stream to the DR database
when REP is the primary. In all other situations it doesnt
forward the redo stream.

DR database forwards the redo stream to the REP
database when PROD is the primary or to PROD when
REP is the primary, but when DR itself is the primary, it
sends the redo stream directly to both the REP and
PROD databases.
Also, the transport mode is explicitly set to ASYNC when
in standby role; therefore the configuration requires the
ADG option.
PROD - Primary database

DR - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
Once the 2-node Dataguard is configured, repeat the

steps 5, 6 and 8 to have another standby copy ready for inclusion, then:
1. Add the third database to the configuration:
dgmgrl> add database 'REP' as connect identifier is 'REP';
Database "REP" added
20
TIPS&TECHNIQUES
2. Verify that the REP database is added but disabled

DGMGRL> show configuration;
Protection Mode: MaxPerformance
Databases:
DR
- Physical standby database
REP - Physical standby database (disabled)
SUCCESS
3. Configure all the RedoRoutes properties to handle all the

possible role transitions, without enabling the real-time
cascade feature:
DGMGRL> edit database 'REP' set property 'redoroutes'='(REP : DR)';
Property "redoroutes" updated
DGMGRL> edit database 'DR' set property 'redoroutes'='(PROD : REP)(REP
: PROD)(LOCAL : REP , PROD)';
DGMGRL> edit database 'PROD' set property 'redoroutes'='(PROD : DR)';
4. Enable the REP database:

DGMGRL> enable database 'REP';
Enabled.
5. Verify the new output of the show configuration

command:
6.
Change the configuration to use the real-time cascade and verify that the label also changes:
DGMGRL> edit database 'DR' set property 'redoroutes'='(PROD : REP
ASYNC)(REP : PROD ASYNC)(LOCAL : REP , PROD)';
DGMGRL> show configuration
Databases:
REP - Physical standby database (receiving current redo)
SUCCESS
7. Switchover to the REP database and verify the new show

configuration output:

Databases:
REP - Physical standby database (receiving archived redo)
SUCCESS
Notice that PROD is the primary database, DR is the firstlevel cascading standby and REP is the second-level cascaded standby. You can infer this by observing the indentation that increases progressively with the level of the cascade.
DGMGRL> switchover to 'REP';

Performing switchover NOW, please wait...
New primary database "REP" is opening...
Operation requires startup of instance "DR" on database "DR"
Starting instance "DR"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "REP"
Databases:
REP - Primary database
PROD - Physical standby database (receiving current redo)
Also notice that the configuration is not using the realtime cascade feature because of the label receiving archived
redo.
SUCCESS
DGMGRL>
Notice that the REP is now the primary and the redo route
is reverted comparing to the original situation.
You may also want to check that the LOG_ARCHIVE_
DEST2 of the DR database has been changed automatically
by the Data Guard Broker (not shown here).
TIPS&TECHNIQUES
8. Switchover to the DR database and verify the new show
configuration output:
DGMGRL > switchover to 'DR';
New primary database "DR" is opening...
Operation requires startup of instance "PROD" on database "PROD"
Starting instance "PROD"...
Database mounted.
Switchover succeeded, new primary is "DR"
21
Far sync instance

When a standby database is deployed, is crucial to
choose if the protection level should guarantee the availability of every transaction on the standby site (for critical data)
and penalize the performance, or if its better to guarantee
the performance and take the risk of losing some transactions.
If the distance between the two locations is too high, the
latencies increase and the availability is always sacrificed in
order to have acceptable performance.
Databases:
DR - Primary database
REP - Physical standby database
PROD - Physical standby database
SUCCESS
Notice that now the DR database is the new primary and

that it sends the redo stream directly to both REP and PROD,
thus having temporarily a non-cascade situation. If you check
the LOG_ARCHIVE_DEST_n parameters on the DR database, you will also notice that the additional third destination
has been added automatically by the Data Guard Broker.
A N Z E I G E
gloBle
Services
Individuelle Softwarelsungen
Business Intelligence
Application Engineering
Seit 13 Jahren lokal, in Ihrer
weltweiten Nhe.
The local
player for
global
solutions
info@irix.ch www.irix.ch
Dornacherstrasse 192 CH 4053 Basel
T 061 367 93 33
To have protection and performance, with releases up to

11g, Oracle customers had to configure two standby databases for different purposes: one to achieve synchronous
commit on a short-distance standby to prevent transaction
loss, and one to have an asynchronous replication to a
disaster recovery site. This solution however was requiring an additional database with additional costs for license and storage.
Oracle Data Guard 12c solves this problem by introducing a new type of instance, named FAR_SYNC.
FAR_SYNC is an instance that takes part to a cascade

standby configuration as we have seen in the real-time
cascade section, but it has some special characteristics:

I t uses a special control file that is created from the
primary database using the command:
ALTER DATABASE CREATE FAR SYNC INSTANCE
CONTROLFILE AS ;

I t doesnt have data files, so the storage requirements are far lower than a standard cascading
database

I t doesnt apply the redo stream, rather it just writes
it to the standby redo logs and forwards the stream
to the cascaded standby

I t cant be opened or converted to a primary
database: it is not a database!
You can use a FAR_SYNC instance local to the primary database to send the redo stream synchronously,
and forward the redo stream asynchronously to a farther
22
TIPS&TECHNIQUES
destination.
The FAR_SYNC instance is configured through the Data
Guard Broker by using a new syntax:

ADD FAR_SYNC

ENABLE FAR_SYNC

EDIT FAR_SYNC

SHOW FAR_SYNC

Example of far sync toppology

As an example, lets start with the topology we ended up in
the previous implementation of cascade standby scenario
(three instances PROD, DR and REP). We want to achieve a
topology like this one:
The FAR_SYNC instance still has the standby redo log

files and its archiver process still creates archived redo logs.
In order to let the far sync instance send the redo stream in
real-time to the cascaded standby, you must clear the standby redo logs as you would with a traditional database.
To setup the FAR_SYNC instances:

1. Prepare the instance the exact way you would with a
traditional standby database (including static service
registration with the listener, password file, parameter
file).
2. Create the FAR_SYNC controlfile by issuing the following
command on the PROD database:
Each candidate primary database should send its redo
stream synchronously to a local FAR_SYNC instance in order
to reduce the latencies; therefore its better to plan one FAR_
SYNC instance for each location.
With this kind of configuration, the RedoRoutes property
is crucial, so it is highly recommended to use the Data Guard
Broker with every Oracle Data Guard 12c deployment.
Please note that Far Sync is a new feature of the Active
Data Guard Option, so you need to buy Active Data Guard
licenses if you use FAR_SYNC instances in your topology.
On the other hand, if you run your FAR_SYNC instances on
dedicated servers (other than the ones you use for the databases) you dont have to pay additional licenses for these
nodes (nor Enterprise Edition, nor Active Data Guard), provided that the servers that run the traditional databases are
licensed correctly.
The FAR_SYNC instances are great to allow a better
handling of a mix of synchronous replication and geographic
topologies, but are handful also, for example:

to offload the primary when the redo stream needs to be
sent to multiple standby databases

to compress the redo stream without impacting on the
primary database node (remind that redo compression
requires Advanced Compression Option license).
SYS@PROD > ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/
tmp/control_PROD_fs.ctl';
Database altered.
3. Copy the controlfile just created on the nodes where the

FAR_SYNC instances reside
4. Mount the FAR_SYNC instances like normal database
instances (startup mount)
a. Youll notice that the role of the instances is FAR
SYNC, whereas the controlfile type is BACKUP:
SQL> select controlfile_type, database_role from v$database;
CONTROL DATABASE_ROLE
------- ---------------BACKUP FAR SYNC
Also notice that FAR_SYNC instances cannot be opened because theyre not databases:
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-16476: far sync instance does not allow Open operation
5. As the last step, verify and clear all the standby log files
to allow the real-time cascade between the FAR_SYNC
instances and the destination databases.
SQL> alter database clear logfile group 4, group5, group6;
Database altered.
SQL>
Repeat the steps 1 to 4 for all the FAR_SYNC instances

you want to configure.
TIPS&TECHNIQUES
23
Once the instances are ready, its time to modify the Data
Guard configuration:
1. Add the FAR_SYNC instances:
DGMGRL> ADD FAR_SYNC 'PRODFS' AS CONNECT IDENTIFIER IS 'PRODFS';
far sync instance "PRODFS" added
DGMGRL> ADD FAR_SYNC 'DRFS' AS CONNECT IDENTIFIER IS 'DRFS';
far sync instance "DRFS" added
2. Verify that the instances have been added:

Databases:
PRODFS - Far Sync (disabled)
DRFS - Far Sync (disabled)
SUCCESS
3. Change the RedoRoutes to reflect the desired topology

and enable the new FAR_SYNC instances:
DGMGRL> edit database 'PROD' set property 'redoroutes'='(PROD : PRODFS
SYNC)';
DGMGRL> edit far_sync 'PRODFS' set property 'redoroutes'='(PROD : DR
ASYNC)';
DGMGRL> edit database 'DR' set property 'redoroutes'='(PROD : REP
ASYNC)(REP : DRFS ASYNC)(LOCAL : REP ASYNC, DRFS SYNC)';
DGMGRL> edit database 'REP' set property 'redoroutes'='(REP : DR
SYNC)';
DGMGRL> edit far_sync 'DRFS' set property 'redoroutes'='(DR : PROD
ASYNC)(REP : PROD ASYNC)';
DGMGRL> enable far_sync 'PRODFS';
Enabled.
DGMGRL> enable far_sync 'DRFS';
Enabled
5. Switchover to DR and verify that DRFS is used to

forward the redo stream from DR to PROD.
DGMGRL> switchover to 'DR';
Operation requires a connection to instance "DR" on database "DR"
Connecting to instance "DR"...
Connected as SYSDBA.
New primary database "DR" is opening...
Operation requires startup of instance "PROD" on database "PROD"
Starting instance "PROD"...
Database mounted.
Switchover succeeded, new primary is "DR"
Protection Mode: MaxAvailability
Databases:
DR - Primary database
REP - Physical standby database
DRFS - Far Sync
PRODFS - Far Sync (inactive)
SUCCES
6. Then switchover to REP and verify again:

DGMGRL> switchover to 'REP';
Operation requires a connection to instance "REP" on database "REP"
Connecting to instance "REP"...
Connected as SYSDBA.
New primary database "REP" is opening...
Operation requires startup of instance "DR" on database "DR"
Starting instance "DR"...
Database mounted.
Switchover succeeded, new primary is "REP"
4. Verify the new configuration and notice that PRODFS is

now used to forward the redo stream from PROD to DR.
Databases:
PRODFS - Far Sync
DRFS - Far Sync (inactive)
SUCCESS
Protection Mode: MaxAvailability

Databases:
REP - Primary database
DRFS - Far Sync (receiving current redo)
PRODFS - Far Sync (inactive)
SUCCESS
You can check the alignment of the databases by querying the v$managed_standby view just like previous releases,
FAR_SYNC instances are no exception, but dont expect to
find the MRP process because redo applying is not possible.
24
TIPS&TECHNIQUES
Other goodies
(remarkable enhancements)
Fastsync redo transport mode
With releases up to 11gR2, the only two available values for
the LogXptMode property of the Datag Guard Broker were:
SYNC (correspondent to SYNC AFFIRM options in the

LOG_ARCHIVE_DEST_n definition)
and ASYNC (correspondent to ASYNC NOAFFIRM

options)
There was still the possibility to specify by hand the couple
SYNC NOAFFIRM to say that:
the network transport should have been synchronous

(SYNC)
there was no need to wait for the standby log to be

written before the commit was returned to the users
(NOAFFIRM)
However this configuration had to be done by altering
manually the LOG_ARCHIVE_DEST_n parameter and it
wasnt supported by the Data Guard Broker.
Now, with Data Guard 12c, the LogXptMode property
supports a third value: FASTSYNC that automatically uses
the SYNC NOAFFIRM couple.
LogXptMode
Transport
Acknowledge
SYNC
SYNC
AFFIRM
ASYNC
ASYNC
NOAFFIRM
FASTSYNC
SYNC
NOAFFIRM
This means that, while the transport over the network is

done synchronously, the disk write on the remote standby log
files is not. Therefore, the Primary will wait some milliseconds
less before returning the commit to the application.
Temporary undo for GTTS
Several reporting applications make use of Global Temporary Tables to work on the data. Since GTTs generate undo
and redo, and the undo tablespace needs to be written, the
need for GTTs has been a big show stopper for the adoption
of Active Data Guard for reporting purposes.
The new parameter TEMP_UNDO_ENABLED enables the
use of the temporary tablespace for the undo generated by
temporary objects, such as GTTs. Redo is not generated at
all. On standby databases opened read-only, this feature is
enabled by default and thus it allows using GTTs seamlessly
in Active Data Guard configurations.
Sequence support
With Oracle Data Guard 12c, you can use global sequences on the standby, provided that the sequences are created
on the primary with the clauses CACHE and NOORDER.
When the standby database needs new sequences, it gets
them from the primary that allocates a range of usable sequences and sends it back to the standby database which
also caches them locally.
If you plan to use sequences massively on the standby,
specify a greater value for the CACHE parameter so that it will
require less requests to the primary, thus less network
roundtrips. The use of sequences doesnt work with cascaded standbys.
Switchover Validation
You may have tried a switchover in previous releases that
has ended up with a failure and an erroneous status of one or
both databases. The new broker command VALIDATE DATABASE allows to test the readiness of the standby database to
transition to the primary role instead of actually trying the
switchover.
DGMGRL> VALIDATE DATABASE 'DR';
Database Role: Physical standby database
Primary Database: South_Sales
Ready for Switchover:
Ready for Failover:
Yes
Yes (Primary Running)
Flashback Database Status:

PROD: On
DR: Off
...
While the VALIDATE DATABASE does a check on the status, the gap and the redo logs, actually it doesnt check the
effectiveness of the Oracle Net configuration and the equivalence of the password files, so you still have to check those
manually. Sadly, as of now they are the most common causes
of switchover failures.
SQL Apply and rolling upgrade

The new SQL Apply used by logical standbys has many
new enhancements, including support for Oracle Text, Multimedia and Spatial. Moreover, also deduplicated securefiles
works, expanding the scenarios where you can use rolling
upgrades for your database. The new DBMS_ROLLING
package simplifies the steps needed for a rolling upgrade, by
reducing the whole procedure to a bunch of steps:

DBMS_ROLLING.INIT_PLAN (future_primary => DR);

DBMS_ROLLING.BUILD_PLAN;

DBMS_ROLLING.START_PLAN;

<mount DR with new binaries and upgrade it>

DBMS_ROLLING.SWITCHOVER

<restart PROD with new binaries>

DBMS_ROLLING.FINISH_PLAN
Moreover, the Broker configuration is retained through the
whole upgrade.
Unfortunately, also the use of the DBMS_ROLLING package requires the purchase of the Active Data Guard Option.
LAG monitoring
Up to release 11g, the Data Guard Broker wasnt able to
monitor the real lag between two or more databases. It was
possible to have the command show configuration reporting
SUCCESS even with hours or days of apply lag. The new 12c
broker has two new parameters: ApplyLagThreshold and
TransportLagThreshold that report a warning in case the
transport or apply lag raises above the specified threshold
(which is expressed in seconds).
This feature increases the capabilities of monitoring, without the need of recurring to custom scripts.
TIPS&TECHNIQUES
25
Other minor enhancements

that are worth to mention

Faster transitions between roles allow quicker switchovers and failovers.

A switchover made in a RAC environment keeps all the
instances up, no more need to stop all the instances
except one (especially useful on RAC with many nodes!).

Resumable switchover makes possible to retry a
switchover even if a previous execution has failed.

The new security role separation comes with a new
SYSDG administrative privilege that follows the principle
of the least privileges. When connected as SYSDG,
youre allowed to do only few actions necessary to
manage the Data Guard.
Behavior in multitenant environments

When Oracle Data Guard 12c is deployed in Multitenant
environments (pluggable databases), theres one single redo
stream for the whole CDB: all the pluggable databases are
aligned and switched over at the same time, at the same consistency point. Even if the standby is logical, the SQL apply is
unique for the whole CDB.
From one side this is a nice feature, because a single configuration allows protecting many databases at once; on the
other side theres less flexibility and addition/deletion of
pluggable databases to the CDB requires some attention.
For example, when you create a PDB from the seed database, the same action is done on the standby site (in physical
environments) and the PDB is created correctly, but if you
plug a database that has been previously unplugged, you
have to make sure that the correspondent datafiles exist in
the same location on the standby servers, or the MRP process will stop!
Two words about global data services

Global Data Services is a new product that comes with
the 12c and is intended as a better, bigger and more powerful
replacement for the Oracle Connection Manager. It provides
seamless client redirection to different database services depending on several customizable factors, including the client
geographic location, the database workload and the replication lag between the current primary database and its replicas.
GDS works with replicas made with GoldenGate, Data
Guard (logical or physical with ADG), and advanced replication, and because its included with both GoldenGate and
Active Data Guard licenses, its worth to give it special attention.
As of now, however, it relies on policy-managed services:
this reduces drastically the number of environments where it
can be used. Hopefully this restriction will be removed (or
mitigated) in the next patchset (12.1.0.2)
Conclusion
Oracle Data Guard 12c has several new features. Even if
were not talking about a major rewrite of the product and we
count only average significant features, the overall enhancement expands the possibilities of complex highly available architectures.
It is a pity that most of these improvements require Active
Data Guard, but since it was already desirable option, in my
opinion now it ranks between the top items to consider when
investing in Oracle Licenses.
References
Oracle Data Guard Broker 12c Release 1 (12.1)
http://docs.oracle.com/cd/E16655_01/server.121/e17641/toc.htm
Oracle Database Data Guard Concepts and Administration 12c Release 1 (12.1)
Oracle Database New Features Guide 12c Release 1 (12.1)
Oracle Database SQL Language Reference 12c Release 1 (12.1)
Oracle Database Reference 12c Release 1 (12.1)
Contact
Trivadis AG
Ludovico Caldara
E-Mail:
Ludovico.Caldara@trivadis.com
Teamwork
und Aufstiegschancen.
Sie mchten erfolgreich starten? Mit abwechslungsreichen und spannenden Aufgaben? In einem Team mit flachen
Hierarchien und einem Unternehmen mit Perspektiven? Willkommen bei Trivadis. Wir sind fhrend bei der IT-Beratung,
der Systemintegration, dem Solution-Engineering und bei den IT-Services mit Fokussierung auf Oracle- und MicrosoftTechnologien im D-A-CH-Raum. Unsere Leistungen erbringen wir auf den strategischen Geschftsfeldern Business
Intelligence, Application Development, Infrastructure-Engineering sowie Training und Betrieb. Doch das Wichtigste ist:
Sie haben mehr als 600 Kolleginnen und Kollegen, die Sie untersttzen. Wir freuen uns auf Sie. Weitere Infos zu
aktuellen Stellenangeboten finden Sie auf unserer Website www.trivadis.com.
ZRICH BASEL BERN BRUGG LAUSANNE DSSELDORF

FREIBURG I.BR. HAMBURG MNCHEN STUTTGART WIEN
FRANKFURT A.M.

NL 2014 4 Award Article PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

NL 2014 4 Award Article PDF

Caricato da

Copyright:

Formati disponibili

SWISS ORACLE USER GROUP

Data Guard in Oracle 12c

Ludovico Caldara, Trivadis AG

Oracle 12C Data Guard:

Real-time cascade standby

Oracle Dataguard 11gR2 limitations

The Data Guard Broker wasnt able to manage cascaded

SOUG Newsletter 4/2014

The new Oracle Data Guard 12c overcomes these limitations.

Old 11gR2 behavior

Old 11gR2 behavior

Same behavior as ASYNC

12c LOG_ARCHIVE_DEST_n attributes

1.log_archive_dest_2 = service="REP", optional reopen=300 net_timeout=30,

In the first example, ASYNC is not specified; therefore the

In order to manage different role transition scenarios and

SOUG Newsletter 4/2014

Example of a cascade standby

As for the parameter LOG_ARCHIVE_DEST_n, a standby

8. Add the standby database to the configuration

9. Enable the configuration

10. Verify that everything is working as expected

New RedoRoutes parameter

dgmgrl> show configuration;

PROD - Primary database

Once the 2-node Dataguard is configured, repeat the

SOUG Newsletter 4/2014

2. Verify that the REP database is added but disabled

3. Configure all the RedoRoutes properties to handle all the

4. Enable the REP database:

5. Verify the new output of the show configuration

7. Switchover to the REP database and verify the new show

DGMGRL> show configuration;

DGMGRL> switchover to 'REP';

SOUG Newsletter 4/2014

Far sync instance

Notice that now the DR database is the new primary and

To have protection and performance, with releases up to

FAR_SYNC is an instance that takes part to a cascade

SOUG Newsletter 4/2014

Example of far sync toppology

The FAR_SYNC instance still has the standby redo log

To setup the FAR_SYNC instances:

3. Copy the controlfile just created on the nodes where the

Repeat the steps 1 to 4 for all the FAR_SYNC instances

SOUG Newsletter 4/2014

2. Verify that the instances have been added:

3. Change the RedoRoutes to reflect the desired topology

5. Switchover to DR and verify that DRFS is used to

6. Then switchover to REP and verify again:

4. Verify the new configuration and notice that PRODFS is

Protection Mode: MaxAvailability

SOUG Newsletter 4/2014

SYNC (correspondent to SYNC AFFIRM options in the

and ASYNC (correspondent to ASYNC NOAFFIRM

the network transport should have been synchronous

there was no need to wait for the standby log to be

This means that, while the transport over the network is

SOUG Newsletter 4/2014

Flashback Database Status:

SQL Apply and rolling upgrade

Other minor enhancements