Consolidated: SQL Server 2008 R2
Initial sync's for my users are prohibitively long. Using -vm verbosity (see below) I've narrowed the issue down to the "fetch_download" phase (anywhere from 5 - 10 minutes). Subsequent sync's work fine (typically within seconds), this only happens on initial sync's.
Initial sync sends down about 3500 rows. With a total size when sent of around 300KB.
I suspect there is some issue or conflict happening in the "fetch_download" phase. I've tried verbosity level v+ and couldn't find any obvious issues.
What other additional steps could I take to track down the issue? Any ideas on what could be causing the issue? The status quo isn't working as you can imagine clients are abandoning with such a long initial sync.
Thanks in advance!
I. 2014-06-13 15:23:02. <3> PHASE: start_time: 2014-06-13 15:12:40.949
asked 13 Jun '14, 11:52
The fetch_download phase time is the time taken to fetch the rows to be downloaded from the consolidated database. Bascially that's time taken to run your download_delete_cursor and download_cursor SQL statements in your SQL Server database. For initial syncs, it's likely the time taken to run your download_cursor SQL statements that is longest. You'll probably have to tune your SQL Server database once you identify what is taking so long.
BTW, the MobiLink Profiler in version 16 records the times for each MobiLink event and table, to more easily narrow down performance bottlenecks. (In earlier versions you can use the MobiLink Monitor to see timings at the phase level, but you have to use a verbose log file for more detailed timings.)
The verbose MobiLink log that you already have should have the information you need, though the timing is indirect: you have to look at the differences between the timestamps of log entries.
FYI the MobiLink plug-in of Sybase Central includes a MobiLink Server Log File Viewer. You might find that helpful, for example to see the log messages of only one synchronization.
answered 13 Jun '14, 12:53
Thanks for the quick response. The Mobilink Server Log File Viewer was very helpful. I've narrowed down the performance issues to this
See log below:
answered 13 Jun '14, 14:14