It is unlikely you'll need such a process. DataGuard is a real-time or near real time (you can choose) replica of the primary database. You don't need to run a replication process as such - it will be constantly be staying up to date with your primary database.

If you are using Active DataGuard, then the database will be open read-only all the time, even though it will still be staying up to date with the primary.

But lets say that

a) you are using standard DataGuard, *and*
b) it is lagging behind the primary for either deliberate reasons or some unknown cause

you could have a script that does an occasional:

- stop recovery
- open read only
- query a relevant table that indicates it is "ready" to start running reports
- if yes, then stay open
- if not, then close and resume recovery

Or even without needing to the stop the recovery you can compare the SCN's on primary and secondary databases, and use SCN_TO_TIMESTAMP to map this to true timestamps.

Plenty of options at your disposal, but I would start simply on the assumption that your dataguard node will most likely always be up to date, and then *not* commence reporting if you find for some rare reason that this is not the case.