=> Yes redo gets applied on the physical standby, but the dirty blocks which
were marked as *not to write* on the primary can get flushed out to disk with
all the dirty changes on the standby before "*not to write* redo is applied on
the standby, causing blocks not matching with primary at binary level. If
there
was higher level checkpoint (datafile or system level) happened at the same
time
"TRUNCATE" operation is marking dirty blocks as *not to write* and instance
crashing before "TRUNCATE" operation is fully completed; it can introduce
logical corruption. Even though oracle can fix it if they wanted to, but why?
The whole concept of physical standby and primary not matching at binary level
can introduce code regression in other areas. I think it does not worth all
this
for improving infrequent "TRUNCATE or DROP" operations to perform little
faster.
=> If there was a rollover of flashback logs (and higher level checkpoint)
happening at the same time dirty blocks being marked as *not to write* and
flashing back the database to right before the completion of "TRUNCATE"
operation, then there is a possibility of logical corruption.
