Can a physical standby database receive the redo SYNC if the Far Sync instance fails?

The answer is YES.

In the following configuration, cdgsima_lhr1pq (primary) sends synchronously to cdgsima_farsync1 (far sync), which forwards the redo stream asynchronously to cdgsima_lhr1bm (physical standby):

But if cdgsima_farsync1 is not available, I want the primary to send synchronously to the physical standby database. I accept a performance penalty, but I do not want to compromise my data protection.

I just need to set up the Redoroutes as follows:

This is defined the second part of the RedoRoutes rules:

Let’s test. If I shutdown abort the farsync instance:

I can see the new SYNC destination being open almost instantaneously (because the old destination fails immediately with ORA-03113):

Indeed, I can see the new NSS process (synchronous redo transport) spawn at that time:

Ludo

The following two tabs change content below.

Ludovico

Principal Product Manager at Oracle
Ludovico is a member of the Oracle Database High Availability (HA), Scalability & Maximum Availability Architecture (MAA) Product Management team in Oracle. He focuses on Oracle Data Guard, Flashback technologies, and Cloud MAA.

2 thoughts on “Can a physical standby database receive the redo SYNC if the Far Sync instance fails?

  1. Hi
    If there are two physical standby databases how shipping is prioritized between standby databases? By the way , data broker is not configured.

    • Hi Zulal,
      Assuming you have Pri, Sb1, Sb2 as Primary and two standby databases.
      In general, there is no priority.

      You can have several combinations:

      Both direct and sync:
      Pri -> Sb1 (SYNC)
      Pri -> Sb2 (SYNC)
      In this case: both destinations are SYNC and the respective NSS process send the info in parallel. The commit is not returned to the used until the ACK is received from both destinations (unless a timeouts occurs)

      Both direct and Async:
      Pri -> Sb1 (ASYNC)
      Pri -> Sb2 (ASYNC)
      In this case: both destinations are ASYNC and one TT process send the info to all destinations in parallel. The commit is returned as soon as it’s written to the ORLs.

      Both direct, one ASYNC and the other SYNC:
      Pri -> Sb1 (SYNC)
      Pri -> Sb2 (ASYNC)
      In this case the SYNC one “has the priority” as it’s a sync destination.

      Cascaded standby:
      Pri -> Sb1 (SYNC or ASYNC)
      Sb1 -> Sb2 (ASYNC)
      In this case the direct standby “has the priority” as it’s the only one receiving directly from the primary.
      HTH

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.