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.
[oracle@prmyFS dbs]$ vi initprmyFS.ora
Update the PFILE parameter file by runningcommand 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.
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.
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.
No comments:
Post a Comment