А зачем он тебе?
Каскадный стендбай вполне нормально работает
Тем более, что с 12c журналы на каскадный стендбай уходят так же как на обычный -- через LGWR, пока сеть позволяет

А про латентность -- это надо настраивать на уровне OS, всякие там sysctl tcp_retrans? tcp_timeout ну и типо того. Вроде, даже и здесь было

Хорошо, что такое Far Sync? https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/creating-oracle-data-guard-far-sync-instance.html#GUID-8AD7FBA2-42B0-46CF-852B-1AF0CB4A36E8 An Oracle Data Guard far sync instance is a remote Oracle Data Guard destination that accepts redo from the primary database and then ships that redo to other members of the Oracle Data Guard configuration.

A far sync instance manages a control file, receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs, but that is where the similarity with standbys ends. A far sync instance does not have user data files, cannot be opened for access, cannot run redo apply, and can never function in the primary role or be converted to any type of standby database.
В старых терминах -- это репозитарий архивлогов" target="_blank" rel="ugc">https://docs.oracle.com/cd/B10501_01/server.920/a96653/log_transport.htm#1038631]|> https://docs.oracle.com/cd/B10501_01/server.920/a96653/log_transport.htm D.2.5 Scenario 5
You have a primary database that is currently protected only by nightly backup operations. You have been told that you must implement a major failure recovery strategy immediately. You have another system of the same hardware type in-house, but it does not have enough power to serve as a standby database for failover purposes, and it does not have enough disks for the entire database. The only other system available to you that is large enough to hold the entire database is too far away to be put on the LAN, and the WAN that connects to it is extremely slow. The deadline for implementing the strategy is well before any network upgrades can occur. Adding a destination (on the primary database) to send the redo logs to the remote location would severely affect performance.

The interim solution to this problem would be to create a physical standby database on the remote system and create a distribution repository on the local smaller system. A distribution repository is comprised of only the standby control file and the standby database online redo logs, not the data files. You would configure the primary database to send the redo information to the repository locally using the log writer process (LGWR) in synchronous mode (SYNC). Because the connection is over the LAN, the effect on performance would be minimal. The repository would then be configured to send the data onwards over the WAN to the real standby database.


Т.е. в случае с FarSync имеем:
Primary --> FarSync --> Standby

В случае каскада имеем:
Primary --> ArcLogsRepo --> Standby

Главной (для меня, по крайней мере) фишкой FarSync было то, что на стендбай редо поток, по возможности, передавался через LGWR транспорт, в то время как на каскадный стендбай до версии 12(2?) использовался только ARCH, независимо от настроек. От primary, естественно, и там и там все уходит через LGWR. Естественно, standby редологи настроены.

Упс, точно

Кстати, даже в твоем случае FarSync/каскад спасут ситуацию -- его можно расположить на том же хосте, архивлоги использовать от primary
Задержки между ним и primary не будет, а отправкой на удаленный стендбай именно он и будет заниматься.
В силу того, что на одном хосте (и нет данных) -- отдельного лицензирования не требует

На одном хосте с primary
Памяти ему много не надо, на диске место только под контролфайл и standby redo

Primary и FarSync на одном хосте, сеть у них -- петля, localhost, 127.0.0.1. Откуда там задержки?
Primary отдал редо на FarSync, тот сразу отчитался, что принял. Все, primary больше ничего не волнует
А уже отправку на стендбай выполняет FarSync из своих standby/archived redo logs.

FSF c FarSync работает, с каскадным -- не уверен, надо смотреть

Где-то в Best Practices видел такую схему с гео разнесенными primary и standby, у каждого из них рядом стоял FarSync для передачи потока на удаленный сервер. Там как раз и с поддержкой FSF

Если быстро найдется скину ссылку