What is the Fast Sync Oracle Data Guard feature?

FAST SYNC (SYNC NOAFFIRM) :

FAST SYNC is a new Data guard feature introduced in Oracle 12cR1 and it's required Oracle Active Data Guard(ADG) license to use for production. 

Maximum Availability mode now allows the LOG_ARCHIVE_DEST_n attributes SYNC and NOAFFIRM to be used together for redo transport service. This enables asynchronous standby database to be deployed at a farther distance from the primary site without increasing the impact on primary DB performance. 

The attribute NOAFFIRM in LOG_ARCHIVE_DEST_n parameter  instructs the standby to acknowledge the receipt of redo changes without waiting for the Remote File Server (RFS) to write to a Standby  Redo Logs (SRL).

This mode is only available in maximum availability protection mode.

example of SYNC NOAFFIRM attribute in LOG_ARCHIVE_DEST_n param on primary DB:

SQL> show parameter log_archive_dest_2

NAME                                    TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                    string       service="STNDBYDB", SYNC NOAFFIRM
                                                   delay=0 optional compression=
                                                   disable max_failure=0 max_conn
                                                   ections=1 reopen=300 db_unique
                                                   _name="PRIMEDB" net_timeout=30,
                                                   valid_for=(online_logfile,all_
                                                   roles)

References:

https://uhesse.com/2015/08/01/fastsync-redo-transport-for-data-guard-in-oracle-12c/

https://mandysandhu.com/2018/02/20/dataguard-12-1-fastsycn-and-farsync/

http://joordsblog.vandenoord.eu/2017/09/dataguard-fastsync-define-redo.html

https://www.wysheid.com/blog/new-features-on-oracle-12c-dataguard/

What is the Far Sync Oracle Data Guard feature?

Far Sync: 

Far Sync feature was  first introduced in 12c Release 1 and it requires Oracle Active Data Guard (ADG) License to use for production purpose.

An Oracle Standby Far SYNC instance is a  remote log transport proxy Oracle standby instance that accepts redo changes from the primary DB and write them into Standby Redo Logs (SRLs) at Far Sync instance's  local destination and then ships that redo changes to the target standby DB. It also archives those Standby Redo Logs(SRLs) to local destination at Far SYNC instance.

A far SYNC instance requires only control file and SRLs and it does not have data files and hence you can't open far sync instance to read/write data.

 Far Sync feature will require an Oracle Active Data Guard (ADG) license to use for production purpose.

It's recommended that Far Sync instance to be placed near(1-150 miles apart) to the primary DB so that there is low network latency between primary and Far Sync instance, which will help in minimizing impact on commit response time and guarantees higher data protection.

References:

https://docs.oracle.com/database/121/SBYDB/create_fs.htm#SBYDB5416
https://oracledbwr.com/step-by-step-configure-oracle-12c-data-guard-far-sync-standby-database/

Why Extra Standby Redo Log Group is required at Oracle Standby Database?

If You create fewer or equal Standby Redo Log (SRL) groups than Oracle Redo Log (ORL) groups, then you may run into trouble when the primary has a high rate of redo generation, especially if the primary is RAC db.  You should have enough SRL groups so that the Network Server SYNC(NSSn) process involved in maximum protection mode  and Network Server ASYNC(NSAn) process involved in maximum performance mode can write from all of the ORL groups from Primary database to SRLS at Standby database. 

For better understanding purpose consider below scenario:

In standalone (Non-RAC) DB, if the primary DB has 2 ORL groups #1 and #2 and redo switches are high due to heavy DML activities , in that case, we want to make sure that standby DB can keep up with the primary. If LGWR on primary just finished #1 and switched to #2, and now it needs to switch back to #1 again because #2 just become full, the standby must catch up, otherwise the primary LGWR cannot reuse #1 because standby is still archiving the standby's #1 SRL. Now, if you have the extra SRL group #3 on standby, then standby in this case can start to use #3 while its #1 SRL is being archived. That way, the primary can reuse the primary's #1 without delay.  

Reference: 

Nice article on Why and  How SRL by Brian Peasland:

https://community.oracle.com/docs/DOC-1007036

https://grokbase.com/t/freelists.org/oracle-l/0944n2j7ek/why-extra-standby-redo-log-group

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:8746767700346579512