DIST Subscription Resolution Engine Activity

[former_member405857]

Hi all!

Please, could you tell me more about SRE module ...

What does mean performance counter with id 30023 (SREDiscard) ?

In one of our replication systems we have half of all cmds in SREDiscard.

-We use one  subscription for database replication definition

-all tables that marked as replicate have their own table definition for performance

-we not replicate the "worktable"

Replication Server/15.7.1/EBF 24048 SP206

Thanks!

Regards,

Pavel .

[former_member182259]

A good place to always start is to run 'select * from rs_statcounters where counter_id=####'.   This table lists all the counters for the SRS version you are running and has some "short" explanations.   For example, in your case 30023 likely will have description value similar to:

DIST commands with no subscription resolution that are discarded by a DIST thread. This implies either there is no subscription or the 'where' clause associated with the subscription does not result in row qualification.

One possibility I can think of is that when using database repdefs/subscriptions, often people mark the entire database for replication (e.g. sp_reptostandby) - so the worktables (if in that database) are forwarded to SRS.   You likely have "do not replicate tables" clause that excludes them and this might be tripping the counter (keep in mind that not every possible cause of the counter being tripped could be in the explanation - field is too short).   If so, then the way to fix it is to use sp_setreptable <worktable>, 'never' - in which case the RepAgent will ignore any modifications to those tables entirely (which will help your throughput as well).

There are other possibilities.   E.g. someone may have marked a user proc for replication, but deliberately left off repdef/subscription as a way to avoid having delete/purge/archive processes from being replicated.   Of course, there also is the most obvious case of a table marked for replication with no subscription - but since you are using database repdef/subscription + table repdef, this is not likely as the database subscription would be used.....am thinking same would be true for the proc replication use case.....so that makes me lean towards work tables are not marked with 'never' and the counter is tracking rows discarded due to the "do not replicate" clause.

[former_member405857]

Jeff,

- We use database replication definition with "replicate tables in (...)" .( 170 tables )
- We don't use sp_reptostandby, ONLY sp_setreptable
- List of tables marked for replication is identical to the list of tables in DBrepdef
- Table repdefs using "replicate minimal columns" ,NOT using "where"

Mark,
we always have (30013/CmdsNoRepdef) = 0, and (30023/SREstmtDiscard) = half of all cmds (30018/SREget)

Avinash,
- All of the marked tables in primary DB exists in the target DB

[former_member89972]

Mark is right 🙂

If target table for replication does not exist,

DSI for that connection comes down.

( I verified that in my sandbox set up )

Pavel

"where" clause is typically on subscription side to qualify or not a DML operation going to the target.

What do rs_helpsub and rs_helpdbsub return ?

Are you using table level subscriptions at all ?  For other targets ?

So if you are

- not using "where" clause in table level subscriptions 

- setting each table for replication

- using (only ?) database level repdef and repsub

May be Jeff can shed some light on where else SRE may come into picture ?

Avinash