The mode of database synchronization that you choose is tied to the importance of two key factors of database recovery, as follows.
The length of time required to restore database access following an interruption
The amount of data that will be lost because of an interruption
Before choosing a synchronization mode, you need to consider the impact of losing data if the primary database becomes unavailable. The more closely synchronized the databases, the smaller the transaction loss will be in a disaster recovery takeover situation.
If most of your transactions can be easily reproduced, having closely synchronized databases might not be so important to you.
The workload and performance of the database, the host machines, and the network are tightly integrated. A heavy workload in any one component can impact the performance of any of the other components. The more closely synchronized the databases, the more sensitive your environment becomes to heavy workloads in any one component.
If you have a secondary database that is synchronized with its primary database when the primary becomes unavailable, you are obviously in a very good position to recover the database quickly and with a minimal loss of data.
As all audit data written to the primary database is sent to the secondary as it is written, in a best-case disaster recovery scenario, zero-transaction loss can be achieved.
However, as a transaction commit on the primary database does not wait for acknowledgements that audit data is stable on disk on the secondary database, this asynchronous synchronization mode does not guarantee zero-transaction loss.
You can still be in a reasonably good position to recover quickly and with a minimal loss of data if you operate SDS with a delayed level of synchronization in journal switch mode.
Because you have a database already set up to take over the operations of the primary database, you can apply outstanding journals as quickly as possible and be back online in a minimal and predictable length of time.