Friday , November 22 2024

Far Sync in Oracle 12c

Far SYNC is a feature introduced with 12c.

It is the dummy instance that sends the Redos from the Primary Database to other Standby Databases in the Data Guard configuration.

It has only standby control file, password file, standby redo log and archived logs. Since there are no Datafiles on it, there is no Redo Apply process.

By sending redos to the nearby location as SYNC, it guarantees zero data loss. It also preserves the availability of the Primary Database.

After guaranteeing zero data loss, redos can be sent as SYNC or ASYNC to up to 30 locations via Far SYNC instance.

Its architectural structure is as follows.

As the database will run in Mount mode, you will likely pay license money to Oracle per core.

Redos can be sent to Standby Databases as compressed.

An alternative “Far SYNC” can be used for High Availability.

In Cascade Standby structures in versions prior to 12c, Redos can be sent from Primary to the first Standby as SYNC. However, Redos could not be sent to other Standby Databases as SYNC.

In Cascade structures in 12c, Redos can be sent as SYNC to Far SYNC instances and Physical Standbys.

With this feature, you can have multiple SYNC Standby Databases.

How To Create Far SYNC Instance?

Step1:

Create PFILE from SPFILE in the primary database.

Step2:

Create Control File for Far SYNC instance.

Step3:

Move Control File, PFILE and Password File to Far SYNC instance.

Step4:

Check if the files go to Far SYNC instance.

Step5:

Create the necessary directories in the Far SYNC instance.

Step6:

Edit the PFILE file according to the behavior of the Far SYNC instance.

Update the PFILE parameter file by running :%s/primary/prmyFS/g command as follows.

After the necessary arrangements in the PFILE parameter file, the final version of the current PFILE file is as follows.

Step7:

Copy the Control File file to the locations specified in the Parameter file.

Step8:

Create SPFILE from PFILE on the Far SYNC instance.

Step9:

Mount the Far SYNC instance.

Step10:

Check the Database Role.

Step11:

Update the Primary Database’s LOG_ARCHIVE_DEST_2 parameter to send the logs to the Far SYNC instance.

Step12:

Check if Archives go to Far SYNC instance by performing Log Switch operation.

You can see if Standby Redo Logs are created in Far SYNC instance as below.

Step13:

Test it. To do this, create a new table in Primary and see if it is transferred to Physical Standby.

We saw that the created table was not transferred to Physical Standby. The reason is that the Log Transport attribute in the LOG_ARCHIVE_DEST_2 parameter in the Far SYNC instance is SYNC.

In order for Redos to be transferred in Real-Time, this parameter must be set as ASYNC.

Step14:

Update the LOG_ARCHIVE_DEST_2 parameter in the Far SYNC instance.

Step15:

Check if the created table is transferred to Physical Standby.

Although we updated the LOG_ARCHIVE_DEST_2 parameter, the table was not transferred. This is because the Redo Transport mode will be enabled after the Log Switch operation.

Step16:

Perform Log Switch.

Step17:

Check if the created table is transferred to Physical Standby.

Step18:

Test it again.

Determine Alternative Redo Transport Location

In systems where Far SYNC is used, when Far SYNC instance is inaccessible, it is necessary to send Redos directly to Standby Database in order to maintain the availability of Primary Database.

When the access problem resolves, Oracle Data Guard automatically re-synchronizes the Far SYNC instance, arranging the Redo stream to go from Primary to Far SYNC and then to Standby.

You can do alternative Redo Transport as follows.

Step1:

Update the archive destination parameter that sends the logs to Far SYNC.

Step2:

Update the dest_state parameter that will send the Redos to the alternate location.

Step3:

Update the archive destination parameter that will send the Redos to the alternate location.

Let’s test the system’s functionality.

Step1:

Check the existing sequences in Primary, Far SYNC and Physical Standby.

Step2:

Perform Log Switch.

Step3:

Shut down Far SYNC instance.

Step4:

Check the data to see if the changes are transfferred to the Physical Standby.

Step5:

Drop the table.

Step6:

Check if the archives are transferred to Standby by performing Log Switch operation.

Step7:

Check if the logs have been transferred to the Far SYNC instance.

Step8:

I assume that the access problem in Far SYNC instance has solved. Then I open the instance.

Step9:

Check if the archives are transferred to the Far SYNC instance by performing Log Switch operation.

Step10:

Check if the missing archives are transferred to the Far SYNC instance.

Deleting Unnecessary Archives in Far SYNC Instance

Since Far SYNC instance transfers Redos to Standby Databases, archives do not need to be stored in Far SYNC instance after the archives are processed to Standby Databases. For this reason, archives processed in Standby Databases can be deleted from Far SYNC instance.

You can delete arciheve logs from Far SYNC instance as follows.

Step1:

Connect to RMAN from Far SYNC instance.

Step2:

List the archives in the instance.

Step3:

Check all parameters to make the necessary configuration.

Step4:

Update the parameter so that archives can be deleted after applied in all Standby’s.

Step5:

Check if the parameter has changed.

Step6:

Perform the CROSSCHECK.

Step7:

Delete applied archives on standby’s.

Step8:

Check the current archives.

Step9:

List which archives are stored at the location where the archives are stored.

Step10:

Check if all of the archives are applied.

Create Far SYNC Instance For Role Change

Step1:

The first step is the same as the steps for creating a normal Far SYNC Instance.

Step2:

Check for an error in the LOG.

PING[ARC2]: Heartbeat failed to connect to standby ‘primary’. Error is 16009.

The reason for this error is that FAR SYNC Instance cannot connect to Primary. This error will go away after Role Change. It can be ignored at this stage.

Step3:

Check if Standby Redo Logs are created in Far SYNC Instance.

We have seen that Standby Redo Logs are not created. The reason is that there is no log flow due to the Physical Standby not being in the Primary Role. Standby Redo Log will be created after the role change.

Step4:

Check the LOG_ARCHIVE_DEST_n parameters to ensure successful log transfer after Role Exchange.

Step5:

Check if Physical Standby is suitable for Switchover and perfom switchover operation.

Determine Alternative Location If Far SYNC Cannot Receive Instance Redos

If Far SYNC instance cannot receive Redos due to any situation, we determine Alternative Location to provide High Availability.

Lest test it.

Step1:

Check the Broker Configuration.

Step2:

We set MaxFailue property. If we set 1, the Redos are sent to the Alternative Location after 1 failed redo transfer.

Step3:

Set Alternative Locations.

You will see this error. 🙂

Error: ORA-16680: value contains unbalanced set of parentheses

Set a single Alternative Location.

Step4:

Set Broker Configuration.

We came to the end of our article. You can ask your questions as comments.

Loading

About Onur ARDAHANLI

Leave a Reply

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