Learning About Data Guard - Expert Consolidation in Oracle Database 12c - page 329

Figure 9-4. Example for a Far Sync Standby configuration
Unlike a “real” standby database, the Far Sync does not have any requirement for data files, significantly reducing
the storage footprint. Apart from the data files all other physical structures of a database are present: control files,
standby redo logs, archived (standby) redo logs, and the administrative files. Since there are no data files you cannot
expect to open the database at all. Similarly you cannot switch over or fail over to a Far Sync Standby. In effect it really
only serves as a relay for redo information. In addition to helping the primary database send redo, it could also be
used to save bandwidth over long distances. If you considered Data Center A to be in North America, and Data Center
B in the Far East, there is only one set of redo to be transported over the long-distance link, instead of potentially
redundant information multiple times.
Ability to check for switchover readiness
The broker can now check for switchover readiness. In releases before Oracle 12.1 it has always been a manual
process to find out whether a database was ready for a role change or not. This often included checking for potential
archive log gaps, checking whether the network was ready and many more pre-checks. Luckily the Broker supports
the DBA in this task. If everything is ok, you should see output similar to this:
DGMGRL> validate database "STDB1"
Database Role: Physical standby database
Primary Database: CDB1
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Current Log File Groups Configuration:
Thread # Online Redo Log Groups Standby Redo Log Groups
(CDB1) (STDB1)
1 3 2
Future Log File Groups Configuration:
Thread # Online Redo Log Groups Standby Redo Log Groups
(STDB1) (CDB1)
1 3 2