Streams Apply latency stays at certain threshold and does not go below that level
(Doc ID 1345707.1)
Last updated on AUGUST 04, 2018
Applies to:
Oracle Database - Enterprise Edition - Version 9.2.0.1 to 11.2.0.3 [Release 9.2 to 11.2]Information in this document applies to any platform.
Symptoms
Streams Apply latency stays at certain level, for example 36,000 seconds (10 hours) and does not go below that level, as shown in the data dictionary view GV$STREAMS_APPLY_READER:
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
102935
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
74384
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
46997
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36001
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36000
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36000
SQL> -- the latency stays at or above 36000
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36001
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
102935
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
74384
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
46997
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36001
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36000
...
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36000
SQL> -- the latency stays at or above 36000
SQL> SELECT ROUND(ABS((DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400),2) LATENCY
2 FROM GV$STREAMS_APPLY_READER;
LATENCY
----------
36001
The Streams Healthcheck reports (Doc ID 273674.1) show the same: the Apply process latency does not go below a certain level, for example 36000 seconds, for example:
...
+ WARNING: The latency of the Capture process 'STRMADMIN_CAPTURE_QEDW' is 36002 seconds!
...
+ WARNING: The latency of the Capture process 'STRMADMIN_CAPTURE_QEDW' is 36002 seconds!
...
...
+ WARNING: The latency of the Capture process 'STRMADMIN_CAPTURE_QEDW' is 36000 seconds!
...
+ WARNING: The latency of the Capture process 'STRMADMIN_CAPTURE_QEDW' is 36000 seconds!
...
...
+ WARNING: The latency of the Capture process 'STRMADMIN_CAPTURE_QEDW' is 36001 seconds!
...
+ WARNING: The latency of the Capture process 'STRMADMIN_CAPTURE_QEDW' is 36001 seconds!
...
Changes
The Capture database is in a different time zone than the Apply side database.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |