DISPLAY,REPL command
You can use the DISPLAY,REPL command to query a source server for metrics for subscriptions and replication mappings. You can also check the activity level of subscriptions. The commands generate reports that are issued to the console as WTO messages.
The following warning message displays on the report if no subscriptions are found:
CECM0050W A subscription matching subscriptionName was not found.DISPLAY,REPL output could be truncated because of the multi-line WTO limitation. The last line in
this case would be **** TRUNCATED ****.
Displaying subscription summary
Displaying subscription detail
Displaying replication mappings
Displaying subscription activity level
This command displays when the last UOR commit was sent from the source server and the time that elapsed since the last UOR commit.
You can use the report output to keep track of how long it has been since the source server sent a UOR to the target.
Displaying subscription activity and data flow
This command produces a report that is a superset of the ACTIVITY modifier, meaning it contains all the information of the ACTIVITY report with additional information.
Use this command in your source server. If you use this command in the target server, the result is the same as the ACTIVITY command. This command displays the time that the last UOR commit was sent from the source server and the amount of time that elapsed since that commit was sent. The command also displays the source datastore commit time of the last sent UOR and the time that elapsed since that commit time, relative to when the report was requested. Additionally, this command displays EWouldBlock counts that are encountered for the subscription.
You can use the report output to keep track of how long it has been since the source server sent a UOR to the target and how latent the source sending is compared with when that UOR was committed in the source datastore. Increasing counts of EWouldBlocks between successive command reports indicates that in the period between commands the source experienced a delay sending data because the network is temporarily not accepting more data. That delay might be because of either a network problem or a slow target reader that caused data to fill the TCP/IP buffers.
You are more likely to see increasing EWouldBlock counts when processing historical data from the log if the source server processes data faster than the target can apply the changes, but during those periods the cause is known. The report is more useful during normal, continuous replication when you are determining the cause of unexpected latency. Seeing that EWouldBlock counts are increasing rapidly can move your analysis toward the target server and the network.
Parameters
- subscription name
- The name of the subscription to display. You can specify the subscription name as an identifier with or without quotation marks.
- asterisk (*)
- An asterisk (*) displays information for all subscriptions. You can also specify an * as a wildcard character at the end of a partial subscription name. For example, specifying SUBSCR=ABC* will display all the subscription names that begin with ABC.
- DETAIL
- Displays detailed information about subscriptions and replication mappings.
- MAPPING
- Displays information about subscriptions that contain replication mappings.
- replication object
- The name of the replication object to display. You can specify the replication object name as an identifier with or without quotation marks.
- DATAFLOW
- When you specify this parameter the report includes the following detail:
- Last UOR Sent
- As explained in the ACTIVITY report.
- Activity Delta
- As explained in the ACTIVITY report.
- EWouldBlock
- The number of times since the subscridtion started that attemdts to send data to the target
returned a response that the send could not be completed immediately and must be retried. This
situation occurs when the network buffers are full of data for the connection. A small number (10s
per second) of these responses during high volume periods might not signal a serious problem, but a
number that grows while latency increases is a sign of either a slow network or a problem that is
causing the target server to not read fast enough.Note: This value is cumulative while the subscridtion is replicating and might wrap at the maximum for an unsigned 32-bit integer (about 4 billion). The discrete value itself is not particularly important; it is more important to see if the value is increasing between multiple invocations of the report and how fast the rate of increase is.
- Last Commit
- The DBMS commit timestamp of when the last UOR commit that was sent was committed at the source.
- Commit Delta
- The time that elapsed between when the report is produced and the last DBMS UOR commit time that
was sent to the target server. This value is displayed as a number followed by the unit of measure
(h, m, s, or ms). If the Commit Delta value grows in a production deployment
then it might indicate a problem in the replication system that needs further review. A high
Commit Delta value might be shown when historical changes are being processed
from the replication log.Note: When no cadture cache exists, you will not see either the Last Commit or Commit Delta values for an inactive subscridtion.
- ACTIVITY
- When you specify this parameter the report includes the following detail:
- Last UOR Sent
- The local machine timestamp of when the last UOR commit was forwarded to the target server.
- Activity Delta
- The time that elapsed since the last UOR commit was forwarded to the target server. This value is displayed as a number followed by the unit of measure (h, m, s, or ms).
If the Activity Delta value grows in a production deployment then it might indicate a problem in the replication system that needs further review. You must decide what period of inactivity is considered to be a problem. This period might be consistent for all subscriptions or might vary by subscription. Note that inactivity is normal under the following circumstances:
- The subscription is not replicating (state is not REPLICATE CONTINUOUS)
- Normal periods of inactivity such as the middle of the night.
You can use system automation to issue the DISPLAY,REPL,SUBSCR=subname,ACTIVITY and look at the following fields:
- Subscription Name (if only interested in certain subscriptions)
- State: If the subscription is not REPLICATE CONTINUOUS, then the Activity Delta is meaningless because it continues to grow.
- Activity Delta: Check the value to see if it exceeds what would be considered normal. The value could be minutes for high-volume subscriptions or hours for low volume.
- INFLIGHT
- When you specify this parameter the report includes the following detail:
- Inflight UOR Identifier
- It indicates the Identifier of the UOR. For more Information, refer to Understanding IMS units of recovery.
- Program
- It indicates the IMS PSB name.
- Inserts
- It indicates the number of inserts in the UOR.
- Updates
- It indicates the number of updates in the UOR.
- Deletes
- It indicates the no: of deletes in the UOR.
- Messages Staged
- It indicates the staged message count
- Start time
- It is the Timestamp of the UOR start time.
- Restart time
- It represents the Timestamp for the Restart point of the subscription.
Example 1
This example shows the output of the DISPLAY,REPL,SUBSCR command for all subscriptions whose name begins with the string 'UDB'. Note that the quantity and size of data that is received and sent can vary widely, depending on factors such as these:
- Log data size
- Table mappings (number and data size of mapped columns)
- Change messages that are the result of formatting the source data
- Data that is stored in caches after you stop and restart replication for a subscription
CAC00200I DISPLAY,REPL,SUBSCR=UDB*
CECM0052I SUBSCRIPTION METRICS REPORT
SrcSysID Subscription Name
======== =============================================================
UDBSUB01 UDBSUB01
Received Sent State: REPLICATE CONTINUOUS
=============== =============== Cache: 3%
Bytes 5430644 7550973
Rows 16456 16456
Refresh 0 0
Commits 1153 1152
Inserts 16456 16456
Updates 0 0
Deletes 0 0
UDBSUB02 UDBSUB02
Received Sent State: REPLICATE CONTINUOUS
=============== =============== Cache: 3%
Bytes 684234436 111590430
Rows 1002000 1002000
Refresh 0 0
Commits 1004 1000
Inserts 0 0
Updates 1002000 102000
Deletes 0 0
UDBSUB03 UDBSUB03
Received Sent State: REFRESH BEFORE REPLI
=============== =============== Cache: 0%
Bytes 13464 85916
Rows 42 42
Refresh 42 42
Commits 0 0
Inserts 0 0
Updates 0 0
Deletes 0 0
UDBSUB04 UDBSUB04
Received Sent State: STARTING
=============== =============== Cache: 0%
Bytes 0 1723
Rows 0 0
Refresh 0 0
Commits 0 0
Inserts 0 0
Updates 0 0
Deletes 0 0
UDBSUB05 UDBSUB05
Received Sent State: INACTIVE
=============== =============== Cache: 0%
Bytes 0 0
Rows 0 0
Refresh 0 0
Commits 0 0
Inserts 0 0
Updates 0 0
Deletes 0 0
Number of source subscriptions reported: 5
END OF REPORTExample 2
In this example, the subscription UDBSUB6 is in the state REFRESH PENDING. Table refresh operations can be expensive, so a single subscription refreshes its replication mappings serially to save system resources. The data server automatically limits the number of concurrent refreshes across multiple subscriptions, placing refresh requests that exceed the limit on a pending queue.
UDBSUB6 UDBSUB6
Received Sent State: REFRESH PENDING
=============== =============== Cache: 0%
Bytes 0 1514
Rows 0 0
Refresh 0 0
Commits 0 0
Inserts 0 0
Updates 0 0
Deletes 0 0
Total number of subscriptions in refresh pending: 1Example 3
This example checks the activity level of subscription L3DBDS00.
DISPLAY,REPL,SUBSCR=L3DBDS00,ACTIVITY
CECM0052I SUBSCRIPTION METRICS REPORT
SrcSysID Subscription Name
======== =============================================================
L3DBDS00 L3DBDS00
Received Sent State: REPLICATE CONTINUOUS
=============== =============== Cache: 1%
Bytes 43008089 43008089
Rows 181000 181000
Commits 1810 1810
Inserts 60331 60331
Updates 60335 60335
Deletes 60334 60334
Last UOR Sent: 2014-10-10-07.22.02.709000 Activity Delta: 41.722(ms)
Number of source subscriptions reported: 1Example 4
This example shows a data flow report.
CECM0060I SUBSCRIPTION METRICS DATA FLOW REPORT 451
SrcSysID Subscription Name
======== =============================================================
DEMO0001 DEMO0001
Received Sent State: REPLICATE CONTINUOUS
=============== =============== Cache: 4%
Bytes 207311178 207311178 EWouldBlock: 65013
Rows 1000200 1000200
Refresh 0 0
Commits 10620 10620
Inserts 400200 400200
Updates 600000 600000
Deletes 0 0
Last UOR Sent: 2021-06-11-05.20.23.586225 Activity Delta: 2.283(m)
Last Commit : 2021-06-11-05.11.29.238023 Commit Delta: 11.189(m)
Number of source subscriptions reported: 1
END OF REPORTExample 7
This is an example from the source server which displays the inflight report.
CECM0061I SUBSCRIPTION METRICS INFLIGHT REPORT 867
SrcSysID Subscription Name
======== =============================================================
DEMO0001 DEMO0001
Received Sent State: REPLICATE CONTINUOUS
=============== =============== Cache: 0%
Bytes 0 0
Rows 0 0
Refresh 0 0
Commits 425 425
Inserts 0 0
Updates 0 0
Deletes 0 0
Inflight UOR Identifer
Program
Inserts Updates Deletes Messages Staged
Start time Restart time
---------------- -------------- --------------- -----------------
0000000000000001IME1 de237adbeb5c7c8c
DFSIVP1
7 0 0 7
2023-11-02-01.44.23.273927 2023-11-02-01.44.23.273927
Number of source subscriptions reported : 1
END OF REPORT
Example 8
This is an example from the source server that shows the date and time when the
DISPLAY,REPL command is run with DISPLAYDATETIME parameter set to
TRUE.
CAC00200I DISPLAY,REPL,SUBSCR=L3DBDS00
CECM0064I 2024-12-16-01.39.19.870574
CECM0052I SUBSCRIPTION METRICS REPORT
SrcSysID Subscription Name
======== =============================================================
L3DBDS00 L3DBDS00
Received Sent State: REPLICATE CONTINUOUS
=============== =============== Cache: 1%
Bytes 43008089 43008089
Rows 181000 181000
Commits 1810 1810
Inserts 60331 60331
Updates 60335 60335
Deletes 60334 60334
Number of source subscriptions reported: 1