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

COLLABORATE 14 – IOUG Forum

Database

1 | P a g e “ORACL E 12C DATA GU AR D: FAR SYNC, R EAL-T IME CASCAD E ST ANDBY AN D OTHER GOODI ES”

Whit e Pa pe r

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

2 | P a g e “ORACL E 12C DATA GU AR D: FAR SYNC, REAL-T IME CASCADE ST ANDBY AND OTHER GOODI ES”

Whit e Pa pe r

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


Whit e Pa pe r

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_role s)

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


Whit e Pa pe r

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


Whit e Pa pe r

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 'P ROD';

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


Whit e Pa pe r

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


Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database DR - Physical standby database REP - Physical standby database (disabled)


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)';

Property "redoroutes" updated DGMGRL> edit database 'PROD' set property 'redoroutes'='(PR OD : DR)';

Property "redoroutes" updated

4. Enable the REP database:

DGMGRL> enable database 'REP';

Enabled.


Database


Whit e Pa pe r

5. Verify the new output of the show configuration command:


Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database DR - Physical standby database

REP - Physical standby database (receiving archived redo)


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)';

Property "redoroutes" updated DGMGRL> show configuration

Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database DR - Physical standby database REP - Physical standby database (receiving current redo)



Database


Whit e Pa pe r

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 data base "DR" Starting instance "DR"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "REP" DGMGRL> show configuration

Configuration – dgprod Protection Mode: MaxPerformance Databases: REP - Primary database DR - Physical standby database

PROD - Physical standby database (receiving c urrent redo)

Fast-Start Failover: DISABLED Configuration Status: 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';

Performing switchover NOW, please wait... New primary database "DR" is opening... Operation requires startup of instance "PROD" on da tabase "PROD" Starting instance "PROD"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "DR" DGMGRL> show configuration

Configuration – dgprod


Database


Whit e Pa pe r

Protection Mode: MaxPerformance Databases: DR - Primary database REP - Physical standby database

PROD - Physical standby database


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

10 | P a g e “ORACL E 12C D AT A GU AR D: FAR SYNC, R EAL-T IME CASCADE ST ANDBY AN D OTHER GOODI ES”

Whit e Pa pe r

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

11 | P a g e “ORACLE 12C D AT A G UAR D: FAR SYNC, R EAL-T IME CASCADE ST ANDBY AND OTHER GOODI ES”

Whit e Pa pe r

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$datab ase;

CONTROL DATABASE_ROLE


Database


Whit e Pa pe r

------- ---------------- 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 op eration

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, group 6; 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 'PRO DFS';

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:


Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database DR - Physical standby database REP - Physical standby database (receiving current redo) PRODFS - Far Sync (disabled) DRFS - Far Sync (disabled)


Database


Whit e Pa pe r


3. Change the RedoRoutes to reflect the desired topology and enable the new FAR_SYNC instances:

DGMGRL> edit database 'PROD' set property 'redoroutes'='(PR OD : PRODFS SYNC)';

Property "redoroutes" updated DGMGRL> edit far_sync 'PRODFS' set property 'redoroutes'='( PROD : DR ASYNC)';

Property "redoroutes" updated DGMGRL> edit database 'DR' set property 'redoroutes'='(PROD : REP ASYNC)(REP : DRFS ASYNC)(LOCAL : REP ASYNC, DRFS SYNC)';

Property "redoroutes" updated DGMGRL> edit database 'REP' set property 'redoroutes'='(REP : DR SYNC)';

Property "redoroutes" updated DGMGRL> edit far_sync 'DRFS' set property 'redoroutes'='(DR : PROD ASYNC)(REP : PROD ASYNC)';

Property "redoroutes" updated 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.


Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database PRODFS - Far Sync

DR - Physical standby database REP - Physical standby database (receivi ng current redo)

DRFS - Far Sync (inactive)



Database


Whit e Pa pe r

5. Switchover to DR and verify that DRFS is used to forward the redo stream from DR to PROD.

DGMGRL> switchover to 'DR';

Performing switchover NOW, please wait... 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 da tabase "PROD" Starting instance "PROD"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "DR" DGMGRL> show configuration;

Configuration – dgprod Protection Mode: MaxAvailability Databases: DR - Primary database

REP - Physical standby database DRFS - Far Sync

PROD - Physical standby database PRODFS - Far Sync (inactive)


6. Then switchover to REP and verify again:

DGMGRL> switchover to 'REP';

Performing switchover NOW, please wait... Operation requires a connection to instance "REP" o n database "REP" Connecting to instance "REP"... Connected as SYSDBA. New primary database "REP" is opening... Operation requires startup of instance "DR" on data base "DR" Starting instance "DR"... ORACLE instance started. Database mounted.


Database


Whit e Pa pe r

Switchover succeeded, new primary is "REP" DGMGRL> show configuration;

Configuration – dgprod Protection Mode: MaxAvailability Databases: REP - Primary database DR - Physical standby database

DRFS - Far Sync (receiving current redo)

PROD - Physical standby database PRODFS - Far Sync (inactive)


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


Whit e Pa pe r

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


Whit e Pa pe r

• <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


Whit e Pa pe r

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

Technology

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