Имеется веб-приложение (разработка не собственная), взимодействующее с базой MSSQL (2008 R2). У одной таблицы в базе имеется индекс полнотекстового поиска. Почти год эта штука работала нормально, а с недавнего времени стали появляться блокировки примерно такого вида:

spidblockedwait_infoopen_transtatusprogram_nameloginamecmd17101runnableMicrosoft JDBC Driver for SQL ServerfooSELECT 29171908.017 sec - LCK_M_IX (TAB: 54:1017770683:63)2backgroundsaFT GATHERER 25629908.015 sec - LCK_M_S (TAB: 54:1017770683:63)1suspendedMicrosoft JDBC Driver for SQL ServerfooSELECT 115256648.329 sec - LCK_M_S (TAB: 54:1017770683:63)1suspendedMicrosoft JDBC Driver for SQL ServerfooSELECT 196256595.737 sec - LCK_M_S (TAB: 54:1017770683:63)1suspendedMicrosoft JDBC Driver for SQL ServerfooSELECT 31290.346 sec - LCK_M_SCH_M (MD: database_id = 54 FULLTEXT_INDEX(object_id = 87671360))2backgroundsaFT GATHERER
поле wait_info формируется на основании полей sys.sysprocesses так:


На самом деле сессий, висящих на spid=256, достаточно много - 150-200, где-то так.
У самого полнотекстового индекса change tracking=automatic, и при возникновении вышеприведённой картины у свойства Table Full-Text Pending Changes значение больше 0.
Порылся в интернете, прочитал, что FT GATHERER - это процесс, обновляющий полнотекстовый индекс, и при change tracking=automatic он запускается тогда, когда сервер сочтёт нужным. Советы по ликвидации блокировок - менять тип обновления индекса на ручной, и обновлять индекс в джобе, например, ночью - но, насколько я понимаю, тогда изменения, которые были внесены днём, до отработки джоба не будут доступны для поиска?
Если убить сессию, на которой висит процесс FT GATHERER (самую верхнюю), то ситуация нормализуется, но этот вариант мне как-то не особенно нравится - нужно постоянно, по несколько раз в день убивать такие сессии, да и вообще это не особенно правильно.
Есть ли ещё какие-нибудь способы устранить вышеописанное?