Determining Redo Log Scanning Latency

The latency in seconds returned by the above query is the difference between the current time, SYSDATE, and the event creation time. The seconds since last status is the difference between SYSDATE and the current process time.

The view v$capture_process shows elapsed times for the various activities as shown below:

• elapsed_capture_time – The elapsed time, in hundredths of a second, scanning for changes in the redo log since the Capture process was last started.
   

• elapsed_rule_time – The elapsed time, in hundredths of a second, evaluating rules since the Capture process was last started.
   

• elapsed_enqueue_time – The elapsed time, in hundredths of a second, messages have been enqueuing since the Capture process was last started.
   

• elapsed_lcr_time - The elapsed time, in hundredths of a second, LCRs have been creating since the Capture process was last started.
   

• elapsed_redo_wait_time – The elapsed time, in hundredths of a second, spent by the Capture process in the WAITING FOR REDO state.

These times tell the DBA where the Capture process is spending most of its time. In this way, the problem area can be pinpointed as a way to tune the process.

The following SQL shows a sample query to verify the timings: