Merge Replication Performance Issues/Trace Files

We have a merge replication configuration with the distributor and subscriber
on one server and the publisher on another. The performance of the merge
slows down more and more as runs. The bandwidth between servers has already
been ruled out because there they run on a Sonet ring and T3 line between
them. We put SQL Profiler trace on the subscriber end of the merge process
using textdata and duration to try to pin point it down to the source of the
problem. However, the Textdata column has unreadable data, for instance
exec([sp_upd_4FAB988B754745CDECFA93F09EC34073]
'8D8EF6A0-8EDA-4C71-934F-0FAE3E79AFFE',
0x000000000000000000000000008007000000000000000000 0000000000000000, 3, 0x00,
296, 0xECFA93F002000000FF,
0xECFA93F001000000ECFA93F001000000ECFA93F001000000 ECFA93F00100000
Does anyone know if there is any way to translate this into the actual query
executed? Otherwise, I don't see how this helps. I got the trace setup
from a Microsoft web site.
This update proc is being run in binary format.
run this query in your subscription database
select name from sysmergearticles where update_proc
='sp_upd_4FAB988B754745CDECFA93F09EC34073'
to determine which table it is updating.
Basically here are the parameters
Rowguid=0x0000000000000000000000000080070000000000 000000000000000000000000,
metadata_type=3,
lineage_old=0x00,
generation=296,
lineage_new=0xECFA93F002000000FF,
colv= 0xECFA93F001000000ECFA93F001000000ECFA93F001000000 ECFA93F00100000
Then there should be a bunch of parameters whose values you have not
supplied me with
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"SandiDBA" <SandiDBA@.discussions.microsoft.com> wrote in message
news:4946584E-0713-4190-BC0A-A35998E63CDA@.microsoft.com...
> We have a merge replication configuration with the distributor and
subscriber
> on one server and the publisher on another. The performance of the
merge
> slows down more and more as runs. The bandwidth between servers has
already
> been ruled out because there they run on a Sonet ring and T3 line between
> them. We put SQL Profiler trace on the subscriber end of the merge
process
> using textdata and duration to try to pin point it down to the source of
the
> problem. However, the Textdata column has unreadable data, for instance
> exec([sp_upd_4FAB988B754745CDECFA93F09EC34073]
> '8D8EF6A0-8EDA-4C71-934F-0FAE3E79AFFE',
> 0x000000000000000000000000008007000000000000000000 0000000000000000, 3,
0x00,
> 296, 0xECFA93F002000000FF,
> 0xECFA93F001000000ECFA93F001000000ECFA93F001000000 ECFA93F00100000
> Does anyone know if there is any way to translate this into the actual
query
> executed? Otherwise, I don't see how this helps. I got the trace
setup
> from a Microsoft web site.
|||Thanks so much, that helps. Do you also know where can I translate the
index being used for the update?
"Hilary Cotter" wrote:

> This update proc is being run in binary format.
> run this query in your subscription database
> select name from sysmergearticles where update_proc
> ='sp_upd_4FAB988B754745CDECFA93F09EC34073'
> to determine which table it is updating.
> Basically here are the parameters
> Rowguid=0x0000000000000000000000000080070000000000 000000000000000000000000,
> metadata_type=3,
> lineage_old=0x00,
> generation=296,
> lineage_new=0xECFA93F002000000FF,
> colv= 0xECFA93F001000000ECFA93F001000000ECFA93F001000000 ECFA93F00100000
> Then there should be a bunch of parameters whose values you have not
> supplied me with
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> "SandiDBA" <SandiDBA@.discussions.microsoft.com> wrote in message
> news:4946584E-0713-4190-BC0A-A35998E63CDA@.microsoft.com...
> subscriber
> merge
> already
> process
> the
> 0x00,
> query
> setup
>
>
|||What index?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"SandiDBA" <SandiDBA@.discussions.microsoft.com> wrote in message
news:58CF081D-5141-4F87-B9C9-54ACD0D514AE@.microsoft.com...[vbcol=seagreen]
> Thanks so much, that helps. Do you also know where can I translate the
> index being used for the update?
> "Hilary Cotter" wrote:
Rowguid=0x0000000000000000000000000080070000000000 000000000000000000000000,[vbcol=seagreen]
between[vbcol=seagreen]
of[vbcol=seagreen]
instance[vbcol=seagreen]
|||The update statement must have a where clause in it. I would like to know
what columns the where clause use to find the row to update. Then from
there, determine if an index is being used for optimization.
"Hilary Cotter" wrote:

> This update proc is being run in binary format.
> run this query in your subscription database
> select name from sysmergearticles where update_proc
> ='sp_upd_4FAB988B754745CDECFA93F09EC34073'
> to determine which table it is updating.
> Basically here are the parameters
> Rowguid=0x0000000000000000000000000080070000000000 000000000000000000000000,
> metadata_type=3,
> lineage_old=0x00,
> generation=296,
> lineage_new=0xECFA93F002000000FF,
> colv= 0xECFA93F001000000ECFA93F001000000ECFA93F001000000 ECFA93F00100000
> Then there should be a bunch of parameters whose values you have not
> supplied me with
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> "SandiDBA" <SandiDBA@.discussions.microsoft.com> wrote in message
> news:4946584E-0713-4190-BC0A-A35998E63CDA@.microsoft.com...
> subscriber
> merge
> already
> process
> the
> 0x00,
> query
> setup
>
>
|||use the index tuning wizard to help you determine this.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"SandiDBA" <SandiDBA@.discussions.microsoft.com> wrote in message
news:732D8E62-ECA5-4D75-B793-6E4F6F0544D6@.microsoft.com...
> The update statement must have a where clause in it. I would like to
know[vbcol=seagreen]
> what columns the where clause use to find the row to update. Then from
> there, determine if an index is being used for optimization.
> "Hilary Cotter" wrote:
Rowguid=0x0000000000000000000000000080070000000000 000000000000000000000000,[vbcol=seagreen]
between[vbcol=seagreen]
of[vbcol=seagreen]
instance[vbcol=seagreen]