Large Table & Merge

I added a large table to our merge pub, 3.4 million rows. Snapshot ran
rather fast, merge agents pushed rows out to 7 subscribers quickly. All
looking ok. Begin testing. Inserts at subscriber not being replicated. Look
at merge agents, change profile to Verbose. They are all displaying 0
inserts, 100 updates, 0 deletes, 0 conflicts.
Run profiler at subscriber and see the following being executed by merge
agent:
exec sp_MSproxiedmetadata 1708016, 'EACC4DE0-9FAC-420A-A4C4-1569768E01CC',
0x3CE7F05C01000000FF, 0x3CE7F05C010000003CE7F05C01...
Is this part of the synch process? Is a 3.4 mill row table WAY TOO BIG to
add to merge?
Any help much appreciated.
Thanks.
Chris
Yes it is. Basically this is the option to minimize network traffic by using
additional storage at the publisher. The publisher tracks where each row has
come from and has to tag the msmerge_contents table with this info.
However, I think you need to use the conflict viewer to understand what has
happened to your inserts.
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
"Chris" <Chris@.discussions.microsoft.com> wrote in message
news:E058091C-50EB-4D09-8758-2F6A6E7D9785@.microsoft.com...
> I added a large table to our merge pub, 3.4 million rows. Snapshot ran
> rather fast, merge agents pushed rows out to 7 subscribers quickly. All
> looking ok. Begin testing. Inserts at subscriber not being replicated.
> Look
> at merge agents, change profile to Verbose. They are all displaying 0
> inserts, 100 updates, 0 deletes, 0 conflicts.
> Run profiler at subscriber and see the following being executed by merge
> agent:
> exec sp_MSproxiedmetadata 1708016, 'EACC4DE0-9FAC-420A-A4C4-1569768E01CC',
> 0x3CE7F05C01000000FF, 0x3CE7F05C010000003CE7F05C01...
> Is this part of the synch process? Is a 3.4 mill row table WAY TOO BIG to
> add to merge?
> Any help much appreciated.
> Thanks.
> Chris

large MSReplication_queue table?

Hi All,
I have a queued update Transactional Replication with a push subscription
from the publisher. The subscriber's database size is nearly double of the
published database on the publisher side. Further investigation found that
the MsReplication_queue has some old data (about last 6 months). Is there any
agent that is supposed to clean the table? Or I have to clean the table
manually? Can someone help me plz?
Thanks in advance,
has the distribution agent run recently? How about the distribution clean up
agent?
"Franky" <Franky@.discussions.microsoft.com> wrote in message
news:BC9B7884-A1CD-4E59-BFB8-9917F35F64E4@.microsoft.com...
> Hi All,
> I have a queued update Transactional Replication with a push subscription
> from the publisher. The subscriber's database size is nearly double of the
> published database on the publisher side. Further investigation found that
> the MsReplication_queue has some old data (about last 6 months). Is there
> any
> agent that is supposed to clean the table? Or I have to clean the table
> manually? Can someone help me plz?
> Thanks in advance,
|||Hilary,
The distribution agent and distribution clean up agent (both on the
Publisher side) are running and the data is being pushed from the Publisher
to the Subscriber. The Subscriber is a DR site and sometimes it runs
production traffic. The MSReplication_queue table is on the Subscriber side.
Does the distribution cleanup agent on the Publisher clean up the
MSReplication_queue table on the Subscriber side? What side effects if I
manually delete entries in the MSReplication_queue since they are old data.
Thanks,
"Hilary Cotter" wrote:

> has the distribution agent run recently? How about the distribution clean up
> agent?
> "Franky" <Franky@.discussions.microsoft.com> wrote in message
> news:BC9B7884-A1CD-4E59-BFB8-9917F35F64E4@.microsoft.com...
>
>

Large MSMerge_History, MSMerge_genhistory,MSRepl_errors tables in SQL Server 2005 Express ed

SQL Server 2005 Standard Edition act as publisher and distributor.
All subscribers are SQL Server 2005 Express Edition.
According to 2005 book online, "MSMerge_History table exists in distribution database". Howevey I found this table in Subscriber database which is in SQL Server 2005 Express Edition.
The problem is this table (MSMerge_History) and other two tables (MSMerge_genhistory, MSRepl_errors) are quite large. We want to keep SQL Server 2005 Express database as small as possible so we can put more data into it.
Is there anyway (Manually or automatically) to clean those tables in SQL Server 2005 Express? Please help.

On the subscriber typically 10 sessions worth of data are stored in MSmerge_history.

Are you running the merge agent in continuous mode by any chance? If so, the table could grow.

You can manually delete the entries in MSmerge_history and MSRepl_errors as they are for history purposes.

MSmerge_genhistory should NOT be touched. You should allow this table to be cleaned up by the merge agent. One thing that may help you is to reduce the retention period of the publication. However this has the side effect that if any subscriber comes to sync after the retention period, it will be expired and needs to be reinitialized. Choose a value that suits your needs.

|||

Thanks Mahesh. I do appreciate your help.