Hmmmm. I would wonder about what happens if the replication of data
volumes (relatively low update level) is allowed to proceed ahead of the
replication of journal volumes (relatively high level of updates).
Without knowing the technical details of the solution you're using, I'm
assuming it shoves things down the pipe as fast as it can, and applies
it on the far end as fast as it can. All this without attempting to
keep things in exact timestamp order across different datasets or
volumes. I would assume it makes this tradeoff in order to avoid
impacting write throughput on the ""live"" side.
IF this can happen, then you might have warmstart/integrity issues.
Chances are probably low, but not zero. The short answer is if the jrnl
replication runs behind the database replication, you WILL have images
on the database files for which you lack sufficient jrnl data to remove
(incomplete or aborted run-units).
Don Casey
Principal Consultant
Run Right, LLC