I am wondering about the behavior and if any details are appended to the redo/archived logs for transactions which were not committed at the time of a DB Failover, and specifically on a Failover to a Data Guard Physical Standby when Maximum Performance is used and there may be some data loss due to async transport of redo data.
When the Standby goes through Role Transition to Primary and a Resetlog is required, this clears the standby online log and archives it, does that also handle the rollback of uncommitted transactions ( if any in the data files, ) and would any rollback segments be added to the log on the Standby for that process before the new DB incarnation is initiated ?
From my understanding, at the point of the Primary failure, there is possibly change data recorded to the data tables and redo logs for open transactions in the Primary database redo logs.
Under Maximum Performance Protection Mode, would some of these uncommitted blocks also be received on the Standby or only fully committed transaction blocks sent and applied which would require Rollback recovery before Opening the database to be Primary following the switchover ?
What is critical is having standby redo logs.
There's a really nice write up on them here
https://community.oracle.com/docs/DOC-1007036 but assuming they are in place, then under max performance mode you might get some small latency (typically in the matter of seconds) between redo being written on the primary and redo being applied on the standby.
So there is small chance that you could have a committed transaction on the primary, for which the redo has not *fully* been transmitted to the standby, ie, that transaction appears "uncommitted" on the standby.
Thus when opening the standby, they would be rolled back (hence the small window of data loss).
If you dont have standby logs, then the window for loss is much greater because we dont apply a "half written" archived redo log, so you could lose a "redo log's worth" of data.