Staging location for D2D data before messages are posted to the producer_cache table with the message (payload).

You can get some idea of how and what is pending by querying the table, to see the messages which are being updated and which are waiting to be published to the rps.producer_cache table.

Select * from rps.pub_dataevent_queue;

Producer_cache: 

Contains the message which each subscriber will get.

It notes if the messages is an initialization and the status of that message (locked or not).

Producer_cache_destination:

Contains the relationship of which queues (stores) the related message will be delivered to.

* Status: 0 = normal, 1 = locked | INIT: 0 = D2D, 1 = Initialization

Select pc.resource_name, pc.status, pc.init, count(*) from RPS.producer_cache pc

group by pc.resource_name, pc.status, pc.init;

Select pd.to_server, pc.resource_name, pc.status, pc.init, count(*) from RPS.producer_cache pc,

RPS.producer_cache_destination pd

where pc.sid = pd.producer_cache_sid

group by pd.to_server, pc.resource_name, pc.status, pc.init;

Identify and monitor init process.

The following will give you a list of init sessions and the their state.

You may need to change the state value if the init process is stuck.

The Connection Manager UI gets the init status and progress details from these tables.

Those updates for records processed come from the store (replication_status table) via mgmt queue.

* Status: 0 = canceled, 1 = in progress, 2 = complete

Select ic.sid, ic.created_datetime, c.controller_name, ic.total_processed, ic.total_failed, ic.status

from RPS.remote_connection rc, RPS.init_status_connection ic, RPS.controller c

where ic.remote_connection_sid = rc.sid and rc.remote_controller_sid = c.sid

order by ic.created_datetime desc;

D2D sessions. 

Used to see and monitor those sessions. Connection Manager UI gets data from here.

This will give a general idea of the data here.

Select c.controller_name, rs.session_type, rs.state, rs.init_status, rs.messages_expected,

rs.messages_received, rs.messages_sent, rs.messages_failed

from RPS.remote_connection rc, RPS.replication_status rs, RPS.controller c

where rs.remote_connection_sid = rc.sid and rc.remote_controller_sid = c.sid;

Session: (0 = V9 init, 2 = POA init, 1 = V9 D2D, 3 = POA D2D)

State: (0 = canceled, 1 = in progress, 2 = complete, 4 = paused)

Init_status: (1 = end of init message processed)

consumer_cache contains the message received from POA and Prism Stores.

* INIT: 0 = D2D, 1 = Initialization

Select resource_name, status, pc.init, count(*) from rps.consumer_cache

Group by resource_name, status, init;

You can filter and look for messages from a particular connection (from_server) or for a particular message type (resource_name) to determine if the messages are just pending processing.

Messages are processed based on the "process_order" value (lowest to highest) and by oldest to newest messages (created_datetime).

You can also filter for a specific message (resource_data). If you know what the document SID is or some unique value for that Document you could filter for that document by using a "like" statement.

If there is a lot of data here, this could be slow.

EXAMPLE: Select * from rps.consumer_cachewhere resource_data like ‘%123%'; -- where 123 is the sid value

Provides you with a list of the resources and the process order.

EXAMPLE: Select resource_name, process_order from RPS.prism_resource

where process_order > 0

order by process_order

Lists those queues that are locked.

EXAMPLE: Select * from RPS.replication_locked_queue;

Staging location for D2D data before messages are posted to the corresponding DRS.PUB_* table.

Example: When someone/something edits a record in inventory, an entry for that item SID will be posted in the drs.drs_invn_sbs table.

If the quantity was updated too, it would have a corresponding entry in the drs.drs_invn_sbs_qty table as well.

Note: this table will only contain one entry for a unique record and will publish this to the corresponding drs.pub_* table at the interval defined.

DRS.exe is responsible for inserting entries in this table.

Staging location for D2D data before messages are posted to the producer_cache table with the message (payload).

You can get some idea of how and what is being processed and what is pending by querying the table.

Select drs_initialize_flag, count(*) from drs.pub_invn_sbs group by drs_initialize_flag;

* drs_initialize_flag: 1 = pending, 2 = processing, 4 = processed pending deletion

Producer_cache:

Contains the message which each subscriber will get.

It notes if the message is an initialization and the status of that message (locked or not).

Producer_cache_destination:

Contains the relationship of which queues (stores) the related message will be delivered to.

* Status: 0 = normal, 1 = locked | INIT: 0 = D2D, 1 = Initialization

Select pc.resource_name, pc.status, pc.init, count(*) from DRS.producer_cache pc

Group by pc.resource_name, pc.status, pc.init;

Select pd.to_server, pc.resource_name, pc.status, pc.init, count(*) from DRS.producer_cache pc, DRS.producer_cache_destination pd

where pc.sid = pd.producer_cache_sid

group by pd.to_server, pc.resource_name, pc.status, pc.init;

Identify and monitor init process.

The following will give you a list of init sessions and their current state.

You may need to change the state value if the init process is stuck.

Connection Manager UI gets init status and progress details from these tables.

Those updates for records processed come from the store (replication_status table) via mgmt queue.

* Status: 0 = canceled, 1 = in progress, 2 = complete

Select ic.sid, ih.load_starttime, rc.connection_name, ic.total_processed, ic.total_failed, ic.status

from DRS.remote_connection rc, DRS.pub_initload_status_header ih, DRS.pub_initload_connection ic

where ih.sid = ic.header_sid and ic.remote_connection_sid = rc.sid

order by ih.load_starttime desc;

D2D sessions. 

Used to see and monitor those sessions. Connection Manager UI gets data from here.

This will give a general idea of the data here.

Select rs.sid, rc.connection_name, rsr.messages_received, rsr.messages_sent, rsr.messages_failed, rsr.resource_name, rs.state

from DRS.remote_connection rc, DRS.replication_status rs, drs.rep_status_resource rsr

where rs.remote_connection_sid = rc.sid and rs.sid = rsr.rep_status_sid order by rc.connection_name;

consumer_cache contains the messages received from POA and Prism Stores.

* INIT: 0 = D2D, 1 = Initialization

Select resource_name, status, pc.init, count(*) from DRS.consumer_cachegroup by resource_name, status, init;

You can filter and look for messages from a particular connection (from_server) or for a particular message type (resource_name) to determine if the messages are just pending processing.

Messages are processed based on the "process_order" value (lowest to highest) and by oldest to newest messages (created_datetime).

You can also filter for a specific message (resource_data). If you know what the document SID is or some unique value for that Document you could filter for that document by using a "like" statement.

If there is a lot of data here, this could be slow.

EXAMPLE: Select * from drs.consumer_cachewhere resource_data like ‘%123%'; -- where 123 is the sid valuerps.

Lists those queues that are locked.

EXAMPLE: Select * from drs.replication_locked_queue;