ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES

COLLABORATE 14 – IOUG Forum
Database
1 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES”
White Paper
ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME
CASCADE STANDBY AND OTHER GOODIES
Ludovico Caldara, Trivadis AG
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
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 white-paper, you should be able to:
• Review the principal Data Guard features introduced with the release 12c
• Discover new replication topologies and possibilities with Data Guard
• List the new DG features that require special licensing

Database
White Paper
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:
• The Data Guard Broker wasn’t 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.
The new Oracle Data Guard 12c overcomes these limitations.
Oracle Data Guard 12c overcomes these limitations
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, I’ve tested it with a four-level cascade).
Oracle Dataguard 11gR2 limitations

Database
White Paper
Moreover, cascading standbys can now send the redo stream immediately, as soon as it is received from the primary database.
It’s 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 it’s 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.
ROLE ATTRIBUTE RESULT
PRIMARY SYNC Old 11gR2 behavior
ASYNC Old 11gR2 behavior
<none> Same behavior as ASYNC
STANDBY ASYNC Use LGWR: Real-Time Cascade ENABLED
<none> USE ARCH: Real-Time Cascade DISABLED
12c LOG_ARCHIVE_DEST_n attributes
As an example, keep the following two configurations on the same cascading, standby database:
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.

Database
White Paper
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.
As for the parameter LOG_ARCHIVE_DEST_n, a standby database can have only ASYNC transport mode in the property
RedoRoutes, and depending whether it’s specified or not, the real-time cascade feature is respectively enabled or disabled. So
take care: if you don’t 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:
New RedoRoutes parameter

Database
White Paper
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 doesn’t forward the redo stream.
• REP database sends its redo stream to the DR database when REP is the primary. In all other situations it doesn’t
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.
EXAMPLE OF A CASCADE STANDBY SCENARIO
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 (let’s 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)
DGMGRL> show configuration;
Configuration – dgprod
Protection Mode: MaxPerformance
Databases:
PROD - Primary database
DR - Physical standby database

Database
White Paper
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
2. Verify that the REP database is added but disabled
Databases:
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.

Database
White Paper
5. Verify the new output of the show configuration command:
Databases:
REP - Physical standby database (receiving archived redo)
SUCCESS
Notice that PROD is the primary database, DR is the first-level “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.
Also notice that the configuration is not using the Real-Time Cascade feature because of the label “receiving
archived redo”.
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

Database
White Paper
7. Switchover to the REP database and verify the new show configuration output:
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)
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).
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"

Database
White Paper
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.
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 it’s 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.
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.

Database
White Paper
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:
• It uses a special control file that is created from the primary database using the command:
ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS …;
• It doesn’t have data files, so the storage requirements are far lower than a standard cascading database
• It doesn’t apply the redo stream, rather it just writes it to the standby redo logs and forwards the stream to the
cascaded standby
• It can’t 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 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
• …
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.
Each candidate primary database should send its redo stream synchronously to a local FAR_SYNC instance in order to reduce
the latencies; therefore it’s better to plan one FAR_SYNC instance for each location.

Database
White Paper
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 don’t 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).
EXAMPLE OF FAR SYNC TOPOLOGY
As an example, let’s 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:
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:
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. You’ll 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

Database
White Paper
------- ----------------
BACKUP FAR SYNC
Also notice that FAR_SYNC instances cannot be opened because they’re 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.
Once the instances are ready, it’s 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)

Database
White Paper
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.
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

Database
White Paper
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)
SUCCESS
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.

Database
White Paper
Switchover succeeded, new primary is "REP"
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 don’t expect to find the MRP process because redo applying is not possible.
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 wasn’t
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.

Database
White Paper
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 doesn’t 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: Yes
Ready for Failover: 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 doesn’t 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;

Database
White Paper
• <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 wasn’t 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.
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, you’re 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), there’s 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
there’s 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 it’s included with both GoldenGate and Active Data Guard licenses, it’s 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)

Database
White Paper
MY CONCLUSION
Oracle Data Guard 12c has several new features. Even if we’re 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)

ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES

Similaire à ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES (20)

Plus de Ludovico Caldara

Plus de Ludovico Caldara (16)

Dernier

Dernier (20)

ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES