9.84 V$STREAMS_APPLY_COORDINATOR
V$STREAMS_APPLY_COORDINATOR
displays information about each apply process coordinator. The coordinator for an apply process gets transactions from the apply process reader and passes them to apply servers. An apply process coordinator is a subcomponent of an apply process, outbound server, or inbound server.
Column | Datatype | Description |
---|---|---|
|
|
Session ID of the coordinator's session |
|
|
Serial number of the coordinator's session |
|
|
State of the coordinator:
|
|
|
Apply process number. An apply process coordinator is an Oracle background process, prefixed by |
|
|
Name of the apply process |
|
|
Total number of transactions applied by the apply process since the apply process was last started |
|
|
Number of times since the apply process was last started that an apply server waited to apply a logical change record (LCR) in a transaction until another apply server applied a transaction because of a dependency between the transactions |
|
|
Number of times since the apply process was last started that an apply server waited to commit a transaction until another apply server committed a transaction to serialize commits |
|
|
Number of administrative jobs issued since the apply process was last started |
|
|
Number of transactions assigned to apply servers since the apply process was last started |
|
|
Total number of transactions received by the coordinator process since the apply process was last started |
|
|
Number of transactions which were received by the coordinator but were ignored because they had been previously applied |
|
|
Number of transactions which were rolled back due to unexpected contention |
|
|
Number of transactions applied by the apply process that resulted in an apply error since the apply process was last started |
|
|
Total number of complete transactions that the coordinator has not assigned to any apply servers |
|
|
Current value of transaction buffer size. Transaction buffer size refers to the number of transactions that the apply reader can assemble ahead of apply servers. The apply process periodically adjusts the transaction buffer size. |
|
|
Time when the message with the lowest message number was recorded. The creation time of the message with the lowest message number was also recorded at this time. |
|
|
Number of the message corresponding to the low watermark. That is, messages with a commit message number less than or equal to this message number have definitely been applied, but some messages with a higher commit message number also may have been applied. |
|
|
For captured messages, creation time at the source database of the message corresponding to the low watermark. For user-enqueued messages, time when the message corresponding to the low watermark was enqueued into the queue at the local database. |
|
|
Time when the message with the highest message number was recorded. The creation time of the message with the highest message number was also recorded at this time. |
|
|
Number of the message corresponding to the high watermark. That is, no messages with a commit message number greater than this message number have been applied. |
|
|
For captured messages, creation time at the source database of the message corresponding to the high watermark. For user-enqueued messages, time when the message corresponding to the high watermark was enqueued into the queue at the local database. |
|
|
Time when the apply process was last started |
|
|
Time elapsed (in hundredths of a second) scheduling messages since the apply process was last started |
|
|
Elapsed idle time |
|
|
Position of the low-watermark LCR |
|
|
Position of the high-watermark LCR |
|
|
Message number currently processed by the apply coordinator |
|
|
The ID of the container to which the data pertains. Possible values include:
|
|
|
Active server count |
Note:
The ELAPSED_SCHEDULE_TIME
column is only populated if the TIMED_STATISTICS
initialization parameter is set to true
, or if the STATISTICS_LEVEL
initialization parameter is set to TYPICAL
or ALL
.
See Also: