Subscription retention period is being ignored


  • Hello,

    I have client with a merge publication setup with a retention period of 60 days.

    They reporting that if their subscribers (which are all merge pull subscriptions) do not sync within 2 weeks the subscription is invalidated.

    Is there an additional setting on the subscriber side I don't know about?

    I see history retention on the distributor but that does not seem like it should effect the merge subscriptions.



    Saturday, February 25, 2012 1:28 AM

All replies

  • Hi Rick,

    Subscription to a merge publication expires if it has not synchronized with the Publisher within the publication retention period and this retention has nothing to with distribution history retention. Check following article for details:

    Subscription Expiration and Deactivation

    How Merge Replication Manages Subscription
    Expiration and Metadata Cleanup

    How to: Set the Expiration Period for
    Subscriptions (Replication Transact-SQL Programming)

    I don’t think so there is any other configuration which we need change but may be Repl Guru can add if there is any other setting.

    Excerpt From MSDN
    Article regarding retention


    Keep the following in mind when setting the retention period for merge publications:

    • Cleanup of merge replication metadata is dependent on the publication
      retention period:
      • Replication cannot clean up metadata in the publication and subscription
        databases until the retention period is reached. Use caution in specifying a
        high value for the retention period, because it can negatively impact
        replication performance. It is recommended that you use a lower setting if you
        can reliably predict that all Subscribers will synchronize regularly within
        that time period.
      • It is possible to specify that subscriptions never expire (a value of 0
        @retention), but it is strongly
        recommended that you do not use this value, because metadata cannot be cleaned
    • The retention period for any
      republisher must be set to a value equal to or less than the retention period
      set at the original Publisher. If you use alternate synchronization partners,
      you should use the same publication retention values for the Publishers and all
      alternate synchronization partners. Using different values might lead to
      non-convergence. If you need to change the publication retention value,
      reinitialize the Subscriber to avoid the non-convergence of data.
    • If, after a clean up, the
      publication retention period is increased and a subscription tries to merge
      with the Publisher (which has already deleted the metadata), the subscription
      will not expire because of the increased retention value. However, the
      Publisher does not have enough metadata to download changes to the Subscriber,
      which leads to non-convergence.


    If retention is 60 days and if subscription is still expiring then it would be interesting to check how and why subscriber is expiring. You can consider following steps to isolate this issue:

    • Verify retention time again.
    • Please check if someone clearing merge metadata manually or not?
    • You can enable Verbose Logging for Merge Agent by following 312292 KB article

    • You can run profiler trace on both publication and subscriber before running synchronization process
      and later on you can analyze it

    Vikas Rana

    Monday, February 27, 2012 1:08 AM
  •  Hi Vikas,

    I have confirmed with the client that the retention period is set to 60 days.

    They are a bit vague as to exactly what is going on. I'm going to enable verbose logging for a few weeks to see what the log holds when the problem occurs.  There are no re-publishers in this case.

    I can't imagine the client would be deleting the meta data. Anyway to check?

    Any other thoughts would be great.

    I'll report back when I get some log data but that maybe a week or so.



    Wednesday, February 29, 2012 8:57 PM