Здравствуйте!

Подскажите, пожалуйста, концепцию оптимального обновления данных между двумя базами данных серверным агентом.

При следующих условиях:
1. База назначения "Сканирует" базу источник. В случае выявления новых и измененных документов с даты последнего запуска должна записать данные по новым и измененным документам.
2. Время работы серверного агента ограничено и составляет, к примеру 15 минут.
3. База источник наполняется документами на разных серверах (документы реплицируются с некоторым промежутком)

Если использовать db.Search и дату отсечки, то коллекция получается корректная, однако неясно, как продолжить дальше, если за время работы агента успеваешь обработать не всю коллекцию и хотелось бы продолжить с оставшихся документов.

 

Если использовать db.Search и дату отсечки, то коллекция получается корректная, однако неясно, как продолжить дальше, если за время работы агента успеваешь обработать не всю коллекцию и хотелось бы продолжить с оставшихся документов.

Так если обработанный документ между запусками еще раз изменят, то он станет необработанным и его надо заново найти.
Время последнего запуска агента надо просто записывать в профайл и брать при первом запуске, если в профайле нет значения - значит самый первый запуска и берется текущее время.
Так же, есть ли смысл делать именно синхронизацию по расписанию? да еще и всей базы?
Может при изменении документа где-то создавать метку об этом, скажет тот же документ в базе рядом, а агент уже на основании этих "необработанных" документов будет получать целевые и тащить из них данные.

 

Есть база в которую накидываются доки. Из нее во вторую базу надо забирать часть информации по триггеру изменения.
db.Search отрабатывает как надо, берет все новые и изменившееся документы с даты предыдущего запуска работы агента.
Причем я проверял, документы пришедшие по реплике тоже туда попадают.
Синхронизация по расписанию цепляет 5-10 документов изменившихся с последнего запуска и все работает корректно и быстро.
Однако в базе источнике может быть пересчет документов и придет коллекция на 100к+ документов. И вот такая коллекция потенциально может не успеть обработаться за 15 минут.
Нужна идея как вот эти 100к+ документов обработать порционно, причем пока обрабатывается, часть может измениться.

Наверное есть вариант с видом в базе источнике с сортировкой по @ModifiedInThisFile и бежать по этому виду.
Но иногда нет возможности вставить вид в базу источник.

 

При изменении документа прописываем в него поле, например $$Modified = 1, а после того, как данные по документу были перенесены в другую базу, удаляем это поле. Таким образом мы уходим от оперирования временем, которое гораздо дольше, и не так надёжно, + гарантируем, что изменённые документы будут доставлены во вторую БД, и это не будет зависеть от того, успел отработать агент пачку за один запуск или нет.
И ещё я бы не использовал параметр отсечки по времени. Сейчас не помню, но были какие-то жёсткие глюки с этим (не все документы отбирались), потому от параметра отказался, и там, где нужно оперировать датами, добавляю соотв. кусок в формулу поиска.

 

2 агента + папка. Первый агент отбирает документы для обработки и скидывает их в папку и всё. Второй агент обрабатывает документы которые находятся в папке, после обработки удаляет из папки. (учтите что при удалении из папки могут возникнуть проблемы с получением следующего документа - как вариант, autoupdate оставте true и берите всегда первый )

 

А можно в базе-источнике агента создать?

 

Большое спасибо всем, кто ответил.

Пока остановился на варианте с db.search с датой отсечки.
Тесты показали, что что просто пробежка по большому количеству доков без обработки с запасом успевает вложится во время работы агента.
Таким образом, в случае массовой модификации, агент с некоторого раза сможет обработать все доки.

увидел также интересные функции типа

Set NotesNoteCollection = NotesDatabase .GetModifiedDocumentsWithOptions( Modifiedsince , Modifieduntil , Options)