Whenever a secondary server initially connects to the primary database, it will almost certainly be behind in terms of applied transactions and it will need to catch up with the primary system. This synchronization is achieved by the replay of audit records in journals transferred from the primary to the secondary database.
A secondary database can be taken offline at any time for any purpose. When it reconnects to the primary system, the synchronization process is repeated. When a secondary database server is stopped or it crashes when transactions are in progress and it is subsequently restarted, the SDS server remains in a ‘recovery required’ state until all interrupted transactions have been resolved.
Interrupted transactions are resolved when the commit or abort audit records are eventually replayed. While interrupted transactions exist, read-access to the secondary database is not permitted.