Meta Data Cleanup options SQL Server 2008
- From: Toni <Toni@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 22 Jun 2009 10:54:02 -0700
We are currently on SQL Server 2008 and have laptops that we transfer data to
and when they come back (3-5 days later) we transfer the data back to the
network (this is done about 4 times a year). We have had problems in the
past with the metadata. While we were on SQL Server 2000 we used the
SP_MergeCleanupMetaData and this worked fine. Per BOL, it states do not use
this for higher versions of SQL Server. After further research it looks like
the best way to handle the metadata cleanup is by changing the subscription
expiration interval to a shorter period (Correct me if I am wrong). We
currently have it set to 7 days. If we change it to 1 day Per BOL it will
still take 2 days. BOL also states when increasing the period (which we would
like to set it back to 7 days) "if, after a cleanup, 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." I am not quite sure what this means or do I need to
worry about this.
If we tried this approach, our users will have to wait two days to delete
records, which maybe doable... I did find another article stating the
subscriptions.MetadataCleanupTime can be changed to fool the system to think
it has not been cleaned up recently. The link is
http://www.replicationanswers.com/MetaDataCleanupImprovements2005.asp
Does anyone know of a reason why I should not use this method? I would
probably set the date back 7 days.
Additional information:
WE use Merge replication and we have 1 publisher and 1 subscriber.
Thank in advance
Toni
.
- Prev by Date: Re: Sql transaction log size because of reindexing
- Next by Date: Re: SS2005 Licensing in VM environments
- Previous by thread: Sql transaction log size because of reindexing
- Next by thread: SQL 2008 Database Mail: Ad-Hoc "from"
- Index(es):
Relevant Pages
|
