September 18, 2006 at 1:13 pm
Rangark,
The Redmond guys did not miss a step. The expiration parameter indicates how long to wait for a subscriber to get data before the subscriber is dropped. If it were based on there being any data in the queue, then the subscriber would never be dropped, and the publisher would be stuck keeping track of data changes for ever. Just choose a number that represents a resonable amount of data to keep at the publisher while waiting for a subscriber to successfully download it. We set ours to 45 days, but each application will have its own requirements.
Have Fun!
Ronzo
October 14, 2006 at 8:48 am
The cleanup is done by "expired subscirption cleanup" job, which is not dependent on the rention period. The sp sp_expired_publication_cleanup is deleting the subcription,irrespective of the data is in queue or not
I am planning to disable this job. Any adverse impact due to this disabling?
rangark.
October 14, 2006 at 3:21 pm
No, there is no adverse impact other than never dropping a subscription. It sounds like this is exactly what you want. You are right that there are two dates. We retain 48 hours of data in our queue (distribution database), but we expire subscriptions after 45 days. The real downside to never expiring a subscription is that your distribution database will retain the data until the subscriber picks it up, meaning the distribution database can get very large over time if the subscriber never picks it up.
Viewing 3 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply