sql server ce - MS Sync framework "Enumerating Inserts for Table xxxx" is suddenly extremely slow -


edited new info.

i inherited project utilizes ms sync framework 2.1 sync sql server ce 3.5 db sql server 2008 r2. there 1 million rows spread on dozen tables. 2 of tables account ~75% of total rows. few dozen rows change per day, , there less 10 users / installations in spoke-and-hub arrangement. sync has little work each day.

the previous version of project complete "do-nothing" sync (zero rows inserted, updated, or deleted on either end) in 1-2 minutes. since re-generated .sdf (including data), taking 9 minutes minimum, , far longer users.

by enabling verbose sync logging, , comparing new log files older ones, narrowed problem down 1 type of operation. time accounted in steps logged "enumerating inserts table xxxxx" (client-side inserts waiting go server). bigger tables take longer smaller tables, of them have increased proportionally, , dramatically, 1 operation, if result 0 rows.

edit: appeared unsupported query syntax (for sql server ce) appearing in sync log, apparently invalid in combination server explorer query window. works fine in vs t-sql editor. have compared 2 actual query plans. same. in 1 sense it's no surprise large table being scanned. however, in t-sql editor takes same time on either db (~35 seconds). apparently more going on in sync engine during operation; though result 0 rows in cases.

when inherited project half way through minor upgrade, not see stands out in source control history. there no documentation describes dev-workstation setup before. have compared tables, columns, , indexes older .sdf. new .sdf , older .sdf same size. there no newer libraries i'm aware of. thoroughly stumped.

what overlooking?

although never learned why newer file performed slower old when enumerating local changes uploaded, figured out how make perform should (wicked fast) in scenario.

as noted before, framework doesn't create indexes when generating cache. little (actually lot of) experimentation revealed creating 1 index (on every table) appears optimal:
create index idx_changetracking on yourtable (__syschangetxbsn, __systrackingcontext, __sysinserttxbsn);

enumerating local changes virtually instant, should have been along. why index not created framework when generating tables, , why didn't matter (as much) previously? guess we'll never know.


Comments

Popular posts from this blog

c# - Better 64-bit byte array hash -

webrtc - Which ICE candidate am I using and why? -

php - Zend Framework / Skeleton-Application / Composer install issue -