Data Guard Cascaded Standby Support in DB12c

Oracle Database 12c brought more than 500 new features, and many of them are related to Data Guard enhancements. Along with overall improvement of Data Guard Broker, support for cascaded standby databases finally came with the release. Moreover, cascaded destinations now receive redo in real-time, without waiting for archived log to be switched.

To configure different variations of standby destinations, the new parameter RedoRoutes was implemented. It defines redo routing rules that transfer redo depending on databases status in Data Guard configuration.

To see how it works, I configured Data Guard with 2 standby databases using an easy naming connection string for simplicity:

CREATE CONFIGURATION dg AS PRIMARY DATABASE
IS d1 CONNECT IDENTIFIER IS '//o641.home/d1';
ADD DATABASE d12 AS CONNECT IDENTIFIER IS '//o642.home/d12';
ADD DATABASE d13 AS CONNECT IDENTIFIER IS '//o643.home/d13';
enable configuration
DGMGRL> show configuration
Configuration - dg
  Protection Mode: MaxPerformance
  Databases:
  d1  - Primary database
    d12 - Physical standby database
    d13 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> show database d1 redoroutes
RedoRoutes = ''
DGMGRL> show database d12 redoroutes
RedoRoutes = ''
DGMGRL> show database d13 redoroutes
RedoRoutes = ''

Using the documentation for RedoRoutes, I set up the cascaded standby databases’ configuration by changing the parameter for primary and for one of the standby databases (d12):

edit database d1 set property redoroutes = '(local:d12)';
edit database d12 set property redoroutes = '(d1:d13)';
DGMGRL> show configuration
Configuration - dg
  Protection Mode: MaxPerformance
  Databases:
  d1  - Primary database
    d12 - Physical standby database
      d13 - Physical standby database (receiving archived redo)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Primary database now sends redo to d12, and in return, d12 sends redo further to d13. However, RedoRoutes can have several route rules and can support redo transport after roles change, like a switchover between d1 and d12. It can be easily done:

edit database d1 set property redoroutes = '(local:d12)(d12:d13)';
edit database d12 set property redoroutes = '(d1:d13)(local:d1)';
DGMGRL> show configuration
Configuration - dg
  Protection Mode: MaxPerformance
  Databases:
  d1  - Primary database
    d12 - Physical standby database
      d13 - Physical standby database (receiving archived redo)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

When d12 becomes primary, it will be using the (local:d1) rule for redo transport and d1 will be taken under (d12:d13) regulations.

And for support of real-time redo transport to cascaded destinations, the parameter should be updated with ASYNC attribute:

edit database d12 set property redoroutes = '(d1:d13 async)(local:d1)';
DGMGRL> show configuration
Configuration - dg
  Protection Mode: MaxPerformance
  Databases:
  d1  - Primary database
    d12 - Physical standby database
      d13 - Physical standby database (receiving current redo)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

As you can see, d13 is now receiving current redo rather than archived like in the previous example.

In the end, it’s worth mentioning that visual support of cascaded standby configuration is implemented in DGMGRL only. Even the latest version of OEM 12c does not represent hierarchy of standby databases; it is just showing them as a list.

Happy Data Guard’ing!