Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

7 656 vues

Publié le

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.

Publié dans : Technologie
  • I like this service ⇒ www.HelpWriting.net ⇐ from Academic Writers. I don't have enough time write it by myself.
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Sex in your area is here: ❶❶❶ http://bit.ly/2F90ZZC ❶❶❶
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • I'm sleeping so much better! Hi David, just a quick message to say thank you so much for this. I have been using a CPAP machine for 3 years and I absolutely hate it. It's so uncomfortable and I sleep worse with it on than I do without it. I'm now sleeping much better thanks to your program. And my wife is so much happier too! ■■■ http://t.cn/Aigi9dEf
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

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

  1. 1. 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
  2. 2. COLLABORATE 14 – IOUG Forum Database 2 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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
  3. 3. COLLABORATE 14 – IOUG Forum Database 3 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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.
  4. 4. COLLABORATE 14 – IOUG Forum Database 4 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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
  5. 5. COLLABORATE 14 – IOUG Forum Database 5 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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
  6. 6. COLLABORATE 14 – IOUG Forum Database 6 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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 DGMGRL> show configuration; Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database DR - Physical standby database REP - Physical standby database (disabled) Fast-Start Failover: DISABLED Configuration Status: 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)'; Property "redoroutes" updated DGMGRL> edit database 'PROD' set property 'redoroutes'='(PROD : DR)'; Property "redoroutes" updated 4. Enable the REP database: DGMGRL> enable database 'REP'; Enabled.
  7. 7. COLLABORATE 14 – IOUG Forum Database 7 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” White Paper 5. Verify the new output of the show configuration command: DGMGRL> show configuration; Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database DR - Physical standby database REP - Physical standby database (receiving archived redo) Fast-Start Failover: DISABLED Configuration Status: 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)'; 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) Fast-Start Failover: DISABLED Configuration Status: SUCCESS
  8. 8. COLLABORATE 14 – IOUG Forum Database 8 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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" DGMGRL> show configuration Configuration – dgprod Protection Mode: MaxPerformance Databases: REP - Primary database DR - Physical standby database PROD - Physical standby database (receiving current 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 database "PROD" Starting instance "PROD"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "DR" DGMGRL> show configuration Configuration – dgprod
  9. 9. COLLABORATE 14 – IOUG Forum Database 9 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” White Paper Protection Mode: MaxPerformance Databases: DR - Primary database REP - Physical standby database PROD - Physical standby database Fast-Start Failover: DISABLED Configuration Status: 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.
  10. 10. COLLABORATE 14 – IOUG Forum Database 10 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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.
  11. 11. COLLABORATE 14 – IOUG Forum Database 11 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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
  12. 12. COLLABORATE 14 – IOUG Forum Database 12 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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: DGMGRL> show configuration; 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)
  13. 13. COLLABORATE 14 – IOUG Forum Database 13 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” White Paper Fast-Start Failover: DISABLED Configuration Status: 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)'; 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. DGMGRL> show configuration; Configuration – dgprod Protection Mode: MaxPerformance Databases: PROD - Primary database PRODFS - Far Sync DR - Physical standby database REP - Physical standby database (receiving current redo) DRFS - Far Sync (inactive) Fast-Start Failover: DISABLED Configuration Status: SUCCESS
  14. 14. COLLABORATE 14 – IOUG Forum Database 14 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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'; 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 database "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) Fast-Start Failover: DISABLED Configuration Status: SUCCESS 6. Then switchover to REP and verify again: DGMGRL> switchover to 'REP'; Performing switchover NOW, please wait... 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"... ORACLE instance started. Database mounted.
  15. 15. COLLABORATE 14 – IOUG Forum Database 15 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” White Paper 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) Fast-Start Failover: DISABLED Configuration Status: 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.
  16. 16. COLLABORATE 14 – IOUG Forum Database 16 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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;
  17. 17. COLLABORATE 14 – IOUG Forum Database 17 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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)
  18. 18. COLLABORATE 14 – IOUG Forum Database 18 | P a g e “ORACLE 12C DATA GUARD: FAR SYNC, REAL-TIME CASCADE STANDBY AND OTHER GOODIES” 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) http://docs.oracle.com/cd/E16655_01/server.121/e17640/toc.htm • Oracle® Database New Features Guide 12c Release 1 (12.1) http://docs.oracle.com/cd/E16655_01/server.121/e17906/toc.htm • Oracle® Database SQL Language Reference 12c Release 1 (12.1) http://docs.oracle.com/cd/E16655_01/server.121/e17209/toc.htm • Oracle® Database Reference 12c Release 1 (12.1) http://docs.oracle.com/cd/E16655_01/server.121/e17615/toc.htm

×