Question: I get the following error: Cannot make the change because a snapshot is already generated. Set @force_invalidate_snapshot to 1, in order to force the change and invalidate the existing snapshot. How do I resolve this error?

Answer:When we add an article to an existing publication that we have already initialized, now as we have added one more article to it, snapshot will become obsolete and will have be reinitialized to incorporate the changes. Adding parameter @force_invalidate_snapshot=1 will force snapshot to be regenerated.

Question: Every time I add an article, entire snapshot is generated. Why is that so?

Answer: There is a property called @immediate_sync in the publication that enforces full snapshot to be generated immediately whenever a new article is added. Setting the value to false for the @immediate_sync will generate snapshot for only the newly added article.

Execute the following command at the Publisher end to reset the value for @immediate_sync option:

sp_changepublication @publication='publicationname',
@property='immediate_sync',@value='FALSE'

In this case, do not forget to call sp_addsubscription procedure for every subscription so that a newly added article can be added. And finally, call sp_refreshsubscriptions to refresh the existing Subscribers.

Question: Why did Snapshot Agent fail to start?

Answer: This question is often found in many newsgroups and various SQL Server forums. Most often this error is caused by login failure error or if there is an issue with the NTFS or share permissions. We need to make sure that we have given appropriate permission for both share and NTFS.

Question: My snapshot has returned the following error: initial snapshot timeout.

Answer: This means that the snapshot that has been generated is large enough or we may have an issue with the network (network congestion or DNS, among others). To overcome this problem:

Question: Why has my transaction log grown so big?

Answer: Replication is using BCP In and BCP Out to synchronize database. Also, BCP operations are fully logged under Full Recovery model and minimally logged when database is set to bulk-logged mode. It all results in all the transactions getting logged, making the transaction log to grow bigger in size.

Although we may change the database recovery model to bulk-logged mode during bulk operation, it is not recommended as it affects the point-in-time recovery. The recommendation is that we should schedule T-Log backup for regular intervals at minimum latency, for example, every 15 minutes, so that we can have point-in-time recovery and we can also keep our T-log in shape.