Hi everyone,
I am working with a large Oracle 19c Data Guard environment and would like to better understand the internal behavior of the RECOVER DATAFILE ... NONLOGGED BLOCK command. I could not find documentation describing how Oracle processes nonlogged block recovery internally, especially after the operation is cancelled.
The environment contains a very large number of nonlogged blocks, and I use the V$NONLOGGED_BLOCK view to monitor the progress of the recovery.
Current values from `V$NONLOGGED_BLOCK` for one of the affected datafiles are approximately:
* MIN(BLOCK#): 406,021
* MAX(BLOCK#): 911,931,232
* COUNT(*): 68,375 ranges
* SUM(BLOCKS): 511,040,075 blocks
Because the recovery takes a very long time, I periodically stop RECOVER DATAFILE ... NONLOGGED BLOCK, restart Managed Recovery (MRP) so that archived redo can be applied and the standby can catch up with the primary, and then start the nonlogged block recovery again.
My observations are:
1. During the first execution, I cancelled the operation when it had reached approximately block 16 million (based on the `P2` value of the `db file sequential read` wait event).
2. During the second execution, the reads appeared to begin again around block 16 million and eventually reached approximately block 250 million before I cancelled the operation.
3. During the third execution, I expected Oracle to continue from approximately block 250 million. Instead, it appeared to start again around block 16 million.
However, there is an interesting observation:
Although the operation appears to start from the same area again, the `db file sequential read` activity progresses much faster through the ranges that were already visited in the previous execution.
This makes me wonder whether Oracle:
* performs a fresh validation of the remaining entries in `V$NONLOGGED_BLOCK` each time,
* quickly skips ranges that have already been processed,
* but does not maintain a true resume checkpoint after a cancelled execution.
I understand that the `P2` value only represents the current block being read and not necessarily the actual starting point of the internal algorithm, so I cannot draw a definitive conclusion.
I have a few questions for anyone who has investigated this feature or worked with Oracle Support:
1. How does Oracle internally use `V$NONLOGGED_BLOCK` during `RECOVER DATAFILE ... NONLOGGED BLOCK`?
2. Does Oracle maintain any resume information after the command is cancelled, or is the validation restarted from the beginning of the remaining ranges?
3. Is progress recorded continuously or only at specific checkpoints?
4. Has anyone traced this operation (10046 trace or other internal events) and identified how Oracle selects the next range to process?
5. Is there any technical reason why `RECOVER DATAFILE ... NONLOGGED BLOCK` cannot run in parallel? Considering that recovery of hundreds of millions of nonlogged blocks may take many hours or even days, a parallel implementation would significantly reduce recovery time. Is this a design limitation, or is there an internal consistency requirement that prevents parallel execution?
Any information, Oracle Support experience, or internal implementation details would be greatly appreciated.
Thank you.