Skip to Content
avatar image
Former Member

DIST Subscription Resolution Engine Activity

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



Pavel .

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • Jun 03, 2015 at 03:55 PM

    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 thinking same would be true for the proc replication use 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.

    Add comment
    10|10000 characters needed characters exceeded

    • 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 )


      "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 ?