"SandiDBA" <SandiDBA@discussions.microsoft.com> wrote in message
news:58CF081D-5141-4F87-B9C9-54ACD0D514AE@microsoft.com...
> 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=0x0000000000000000000000000080070000000000000000000000000000000000,
> > metadata_type=3,
> > lineage_old=0x00,
> > generation=296,
> > lineage_new=0xECFA93F002000000FF,
> > colv= 0xECFA93F001000000ECFA93F001000000ECFA93F001000000ECFA93F00100000
> >
> > 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',
> > > 0x0000000000000000000000000080070000000000000000000000000000000000, 3,
> > 0x00,
> > > 296, 0xECFA93F002000000FF,
> > > 0xECFA93F001000000ECFA93F001000000ECFA93F001000000ECFA93F00100000
> > >
> > > 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.
> >
> >
> >

"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
> 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=0x0000000000000000000000000080070000000000000000000000000000000000,
> > metadata_type=3,
> > lineage_old=0x00,
> > generation=296,
> > lineage_new=0xECFA93F002000000FF,
> > colv= 0xECFA93F001000000ECFA93F001000000ECFA93F001000000ECFA93F00100000
> >
> > 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',
> > > 0x0000000000000000000000000080070000000000000000000000000000000000, 3,
> > 0x00,
> > > 296, 0xECFA93F002000000FF,
> > > 0xECFA93F001000000ECFA93F001000000ECFA93F001000000ECFA93F00100000
> > >
> > > 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.
> >
> >
> >