Hi Kevin,

I can't help you with why the query is slow when run by the merge agent, but I think I do know what makes it run fast when run manually: the view MSmerge_repl_view_63666C4AA85D46329603479A5E32376A_D633BCAFDDAC4F348FE5BA277E7BAA48 (yours has a different string of characters) internally checks for permissions of the current user. Or in other words, though you're executing the same T-SQL, you're not executing the same query. Here's the implementation for my replicated table:

create view dbo.MSmerge_repl_view_63666C4AA85D46329603479A5E32376A_D633BCAFDDAC4F348FE5BA277E7BAA48

as

select *

from [dbo].[FileEventLogs]

where ({fn ISPALUSER('63666C4A-A85D-4632-9603-479A5E32376A')} = 1

or (HAS_PERMS_BY_NAME('[dbo].[FileEventLogs]', 'OBJECT', 'SELECT')

| HAS_PERMS_BY_NAME('[dbo].[FileEventLogs]', 'OBJECT', 'UPDATE')

| HAS_PERMS_BY_NAME('[dbo].[FileEventLogs]', 'OBJECT', 'INSERT')

| HAS_PERMS_BY_NAME('[dbo].[FileEventLogs]', 'OBJECT', 'DELETE'))=1)

So you need to be sure you've got exactly the same user that the agent is using when trying to reproduce the issue. The ISPALUSER is another unpredictable factor in here. I don't know what exactly it does. I've not found many references to it on the net, but here's one that does give a little bit of info: http://stackoverflow.com/questions/1232570/what-does-the-ispaluser-function-call-in-the-msmerge-view-views-do. What I do know is that when a large number of entries exists in msMerge_contents this function can become incredibly slow. Up to a point where it slows down a merge agent to a point where it times out constantly. This is how I encountered it.