sql server replication:
We are using sql server 2005 and in our TEST environment --please note TEST-- I have set the subscription expiration interval to be 1 day. We made the mistake in the beginning of setting it to never expire and we are getting errors, performance problems etc. I am trying to test the behavior of changing that setting. What I did was, after I set it to 1 day, I re-ran the snapshot. Fine, it all worked for devices currently synching. 24 hours later, I tried to create a new subscription and I get "The snapshot for this publication has become obsolete. The snapshot agent needs to be run again before the subscription can be synchronized." So fine, I reran the snapshot, THEN 24 hours later I try to create a new subscription and I get "The snapshot for this publication has become obsolete. The snapshot agent needs to be run again before the subscription can be synchronized." ...notice a trend. I understand the concept of snapshots, subscriptions, and publications. I know where they fit into the puzzle, but this behavior is strange. I am thoroughly confused, I am setting a publication setting called "Subscription expiration"...I have looked, I am aware of what it is supposed to do..if a subscription doesn't connect within stated time frame, it's expired...wonderful that is what I am after. Why is it that the Snapshot is becoming obsolete on a new subscription? My understanding of a snapshot is that it would not become obsolete unless there are schema changes, filter changes, etc..then you would have to re-init, but this is on a new subscription. By this logic, if I set the subscription expiration to 14 days, I would have to generate a new snapshot every 13 days? This just doesn't seem right... Sorry so long, any ideas?
For PDAs you should set it to something smallish, but 1 day is too small. I think 4-5 days is a good number. The snapshot contains all the data, schema and metadata required to create all the objects on the subscriber. After one day in your case the metadata on the publisher is purged and what is in the snapshot will not be sufficient to sync with the publisher, hence you need a new snapshot. You want to set a small number so that not a lot of data goes across the wire, but a big enough number so that the majority of your subscribers will sync within the expiration time. If you set it to an infinite amount - never expires, a lot of data will have to go to the subscriber to get it back in sync. I find that sometimes its better to send a new snapshot to your pda's regularly as sometimes the sync times can be more lengthy than deploying an initial snapshot. -- Hilary Cotter Looking for a SQL Server replication book? http://www.nwsu.com/0974973602.html Looking for a FAQ on Indexing Services/SQL FTS http://www.indexserverfaq.com [quoted text, click to view] "Greg J" <greg.judkins@gmail.com> wrote in message news:1170199075.703927.154480@h3g2000cwc.googlegroups.com... > We are using sql server 2005 and in our TEST environment --please note > TEST-- I have set the subscription expiration interval to be 1 day. > We made the mistake in the beginning of setting it to never expire and > we are getting errors, performance problems etc. I am trying to test > the behavior of changing that setting. > > What I did was, after I set it to 1 day, I re-ran the snapshot. Fine, > it all worked for devices currently synching. 24 hours later, I tried > to create a new subscription and I get "The snapshot for this > publication has become obsolete. The snapshot agent needs to be run > again before the subscription can be synchronized." So fine, I reran > the snapshot, THEN 24 hours later I try to create a new subscription > and I get "The snapshot for this publication has become obsolete. The > snapshot agent needs to be run again before the subscription can be > synchronized." ...notice a trend. > > I understand the concept of snapshots, subscriptions, and > publications. I know where they fit into the puzzle, but this > behavior is strange. > > I am thoroughly confused, I am setting a publication setting called > "Subscription expiration"...I have looked, I am aware of what it is > supposed to do..if a subscription doesn't connect within stated time > frame, it's expired...wonderful that is what I am after. > > Why is it that the Snapshot is becoming obsolete on a new > subscription? My understanding of a snapshot is that it would not > become obsolete unless there are schema changes, filter changes, > etc..then you would have to re-init, but this is on a new > subscription. > > By this logic, if I set the subscription expiration to 14 days, I > would have to generate a new snapshot every 13 days? This just > doesn't seem right... > > Sorry so long, any ideas? >
The answer lies in the MSmerge_contents and MSmerge_genhistory tables. These two tables hold the list of data changes that happened for the past x days, x being the subscription expiration days. After x days the record of the data change expire from the MSmerge_contents table. The implication of that is that existing subscriptions that have not synchronised for the past x days will then not be able to merge that change anymore. The same holds true for creating new subscriptions with an old snapshot - remember the snapshot also contains data. If the snapshot was created x-2 days ago you will missing two days of data changes that has already expired from the MSmerge_contents table. [quoted text, click to view] Greg J wrote: > We are using sql server 2005 and in our TEST environment --please note > TEST-- I have set the subscription expiration interval to be 1 day. > We made the mistake in the beginning of setting it to never expire and > we are getting errors, performance problems etc. I am trying to test > the behavior of changing that setting. > > What I did was, after I set it to 1 day, I re-ran the snapshot. Fine, > it all worked for devices currently synching. 24 hours later, I tried > to create a new subscription and I get "The snapshot for this > publication has become obsolete. The snapshot agent needs to be run > again before the subscription can be synchronized." So fine, I reran > the snapshot, THEN 24 hours later I try to create a new subscription > and I get "The snapshot for this publication has become obsolete. The > snapshot agent needs to be run again before the subscription can be > synchronized." ...notice a trend. > > I understand the concept of snapshots, subscriptions, and > publications. I know where they fit into the puzzle, but this > behavior is strange. > > I am thoroughly confused, I am setting a publication setting called > "Subscription expiration"...I have looked, I am aware of what it is > supposed to do..if a subscription doesn't connect within stated time > frame, it's expired...wonderful that is what I am after. > > Why is it that the Snapshot is becoming obsolete on a new > subscription? My understanding of a snapshot is that it would not > become obsolete unless there are schema changes, filter changes, > etc..then you would have to re-init, but this is on a new > subscription. > > By this logic, if I set the subscription expiration to 14 days, I > would have to generate a new snapshot every 13 days? This just > doesn't seem right... > > Sorry so long, any ideas?
Thanks JE, I have some followup thoughts/questions to your post. " The same holds true for creating new subscriptions with an old snapshot " I still do not understand what makes it an old snapshot. I understand that if a subscription expires, I will not be able to see data in a new subscription from the expired subscription, but I should be able to create a new subscription with the information that the snapshot has. I do not understand how the snapshot is valid with an existing subscription A but obsolete with a new subscription B. [quoted text, click to view] On Feb 1, 9:36 am, JE <jgegroups.s...@gmail.nospam.com> wrote: > The answer lies in the MSmerge_contents and MSmerge_genhistory tables. > These two tables hold the list of data changes that happened for the > past x days, x being the subscription expiration days. After x days the > record of the data change expire from the MSmerge_contents table. The > implication of that is that existing subscriptions that have not > synchronised for the past x days will then not be able to merge that > change anymore. The same holds true for creating new subscriptions with > an oldsnapshot- remember thesnapshotalso contains data. If thesnapshotwas created x-2 days ago you will missing two days of data > changes thathasalready expired from the MSmerge_contents table. > > > > Greg J wrote: > > We are using sql server 2005 and in our TEST environment --please note > > TEST-- I have set the subscription expiration interval to be 1 day. > > We made the mistake in the beginning of setting it to never expire and > > we are getting errors, performance problems etc. I am trying to test > > the behavior of changing that setting. > > > What I did was, after I set it to 1 day, I re-ran thesnapshot. Fine, > > it all worked for devices currently synching. 24 hours later, I tried > > to create a new subscription and I get "Thesnapshotfor this > >publicationhasbecomeobsolete. Thesnapshotagent needs to be run > > again before the subscription can be synchronized." So fine, I reran > > thesnapshot, THEN 24 hours later I try to create a new subscription > > and I get "Thesnapshotfor thispublicationhasbecomeobsolete. The > >snapshotagent needs to be run again before the subscription can be > > synchronized." ...notice a trend. > > > I understand the concept of snapshots, subscriptions, and > > publications. I know where they fit into the puzzle, but this > > behavior is strange. > > > I am thoroughly confused, I am setting apublicationsetting called > > "Subscription expiration"...I have looked, I am aware of what it is > > supposed to do..if a subscription doesn't connect within stated time > > frame, it's expired...wonderful that is what I am after. > > > Why is it that theSnapshotis becomingobsoleteon a new > > subscription? My understanding of asnapshotis that it would not > >becomeobsoleteunless there are schema changes, filter changes, > > etc..then you would have to re-init, but this is on a new > > subscription. > > > By this logic, if I set the subscription expiration to 14 days, I > > would have to generate a newsnapshotevery 13 days? This just > > doesn't seem right... > > > Sorry so long, any ideas?- Hide quoted text - > > - Show quoted text -
The snapshot is only really used once: to initialise the subscriber. It contains the schema and data for the initial load before replication starts. Subscriber expiry indicates the amount of days that a log of data changes are kept. For example let us take a snapshot that is 10 days old and the subscriber expiry is set to 5 days. The snapshot will be consistent with the publisher 10 days ago, but your log of changes at the publisher only goes back 5 days. Which means a new subscriber will never be able to catch up - it will always be missing those 5 days of data. Existing subscribers will not be affected by an old snapshot - they don't need it again after initialisation. [quoted text, click to view] Greg J wrote: > Thanks JE, I have some followup thoughts/questions to your post. > > " The same holds true for creating new subscriptions with > an old snapshot " > > I still do not understand what makes it an old snapshot. I understand > that if a subscription expires, I will not be able to see data in a > new subscription from the expired subscription, but I should be able > to create a new subscription with the information that the snapshot > has. I do not understand how the snapshot is valid with an existing > subscription A but obsolete with a new subscription B. > > > > On Feb 1, 9:36 am, JE <jgegroups.s...@gmail.nospam.com> wrote: >> The answer lies in the MSmerge_contents and MSmerge_genhistory tables. >> These two tables hold the list of data changes that happened for the >> past x days, x being the subscription expiration days. After x days the >> record of the data change expire from the MSmerge_contents table. The >> implication of that is that existing subscriptions that have not >> synchronised for the past x days will then not be able to merge that >> change anymore. The same holds true for creating new subscriptions with >> an oldsnapshot- remember thesnapshotalso contains data. If thesnapshotwas created x-2 days ago you will missing two days of data >> changes thathasalready expired from the MSmerge_contents table. >> >> >> >> Greg J wrote: >>> We are using sql server 2005 and in our TEST environment --please note >>> TEST-- I have set the subscription expiration interval to be 1 day. >>> We made the mistake in the beginning of setting it to never expire and >>> we are getting errors, performance problems etc. I am trying to test >>> the behavior of changing that setting. >>> What I did was, after I set it to 1 day, I re-ran thesnapshot. Fine, >>> it all worked for devices currently synching. 24 hours later, I tried >>> to create a new subscription and I get "Thesnapshotfor this >>> publicationhasbecomeobsolete. Thesnapshotagent needs to be run >>> again before the subscription can be synchronized." So fine, I reran >>> thesnapshot, THEN 24 hours later I try to create a new subscription >>> and I get "Thesnapshotfor thispublicationhasbecomeobsolete. The >>> snapshotagent needs to be run again before the subscription can be >>> synchronized." ...notice a trend. >>> I understand the concept of snapshots, subscriptions, and >>> publications. I know where they fit into the puzzle, but this >>> behavior is strange. >>> I am thoroughly confused, I am setting apublicationsetting called >>> "Subscription expiration"...I have looked, I am aware of what it is >>> supposed to do..if a subscription doesn't connect within stated time >>> frame, it's expired...wonderful that is what I am after. >>> Why is it that theSnapshotis becomingobsoleteon a new >>> subscription? My understanding of asnapshotis that it would not >>> becomeobsoleteunless there are schema changes, filter changes, >>> etc..then you would have to re-init, but this is on a new >>> subscription. >>> By this logic, if I set the subscription expiration to 14 days, I >>> would have to generate a newsnapshotevery 13 days? This just >>> doesn't seem right... >>> Sorry so long, any ideas?- Hide quoted text - >> - Show quoted text - >
Don't see what you're looking for? Try a search.
|