hVosttТ.е. инфа на момент начала загрузки была одна, а вот актуальность данных меняется с течением времени, и с 15:00 до 18:00 база данных вообще непонятно в каком состоянии, и как можно с этим работать, не понимаю? Это что нормально?
Твою неопытность видно за версту :) Процессинг, ETL, DWH, репликация и иже с ними - априори не могут быть актуальными относительно источника данных. Всегда есть какая временная дельта, разрыв во времени. Это нормально.

hVosttТ.е. активные пользователи получают не просто не актуальную информацию (когда данные ещё не загрузились), а вообще непонятно что. Совершенно очевидно, что сводными отчётами в процессе загрузки можно только зад подтереть. Если бы обеспечивалась транзакционность, то хотябы состояние базы было бы актуально на определённый момент (до загрузки или после), а не черти что. В чём великий смысл этого идиотизма, не понимаю.
Работал когда-нибудь с OLAP DWH? Процессинг кубов, мер, измерений всегда трудозатратная по времени операция, временное расхождение актуальных данных с боевой БД достигает от 1 дня и выше. Это нормально.

hVosttДа не про временную дельту идёт речь. То, что для загрузки требуется время, это понятно. Речь идёт об консистентности. Короче, неблокирующую транзакцию как обеспечить знаешь или нет, скажи мне, опытный ты наш.
1. "Консистентности" всего процессинга? :) Такого не бывает, это сказки. А от консистентности батча (пакета, группы, экземпляра) - всегда вэлкам.
2. Что такое "неблокирующая транзакция"? Опять жжешь напалмом?

hVosttМСУРаботал когда-нибудь с OLAP DWH? Процессинг кубов, мер, измерений всегда трудозатратная по времени операция, временное расхождение актуальных данных с боевой БД достигает от 1 дня и выше. Это нормально.
Немного, но да, работал. Ещё раз повторяю, проблема не в актуальности, а в её нарушении. Пусть данные будут актуальны за вчера, но целостны. Разрывы не уместны.
Если ты под "данными" за вчера понимаешь весь процессинг, то я тебе уже 100 раз сказал, что это глупость. Объясняю 101 раз.

1. Процессинг "данных за вчера" обвалился на 99% выполненной работе.
2. Сегодня ты хочешь получить "данные за вчера", а их там нет. Что делать?
3. Одному пользователю нужен только 1% информации из этих 99%, другому нужно 5% из 99%, третьему - 10% из 99%. Зачем их лишать этих данных?
4. Образно говоря, в моём случае 80% сотрудников будут работать в штатном режиме и только 20% будут испытывать трудности, т.к. 1% невыполненной работы у тебя завалился. В твоём случае 100% работников будут сосать писю.
5. Профиты?

hVosttМСУ1. "Консистентности" всего процессинга? :) Такого не бывает, это сказки. А от консистентности батча (пакета, группы, экземпляра) - всегда вэлкам.
Ну почему не бывает, просто никто не говорит, что это просто. В зависимости от задачи можно разработать различные сценарии для достижения этого результата. Или будешь утверждать, что это задача абсолютно не выполнимая?
Речь не о простоте или сложности, речь о бывает или не бывает. Сценарий просессинга всегда прост - процессить. В процессинге единичного экземпляра или группы интереса никакого нет, процессят всегда набор экземпляров или групп. Оборачивать процессинг экземпляров или групп в ACID - смертоубийственная затея, о которой тебе тут все тылдычат.

hVosttМСУ2. Что такое "неблокирующая транзакция"? Опять жжешь напалмом?
Это значит, что существует два состояния: до загрузки/обработки/синхронизации данных и после, а не где-то между. При больших объёмах использование транзакции базы данных приносит много боли пользователям ради достижения этой цели. И ты хочешь сказать, что по-другому нельзя? Либо блокирующие страдания, либо батчи?
Я тебе выше уже сказал, что оборачивать процессинг в ACID - это как упаковать столичное Киевское шоссе в презерватив. Лопнет или не лопнет. А зачем? А фиг его знает. Так хвост захотел.

hVosttМСУ1. Процессинг "данных за вчера" обвалился на 99% выполненной работе.
Да, обвалился по причине неизвестной заранее ошибки, потому что иначе ситуация была бы правильно обработана, и ошибки бы не случилось. Раз имеется такая ошибка, значит и всей логике загрузки доверять как-то сомнительно, это надо чинить. Лучше пару раз поймать и починить, чем постоянно ловить «недосказанность» + постоянные периоды времени в полу-недоактуальном половинчатом хер пойми каком недосостоянии.
Да причем тут логика? Обвалился процессинг по причине того, что сервер ушел в ребут, нештатная ситуация у DBA и отвалилась база, закончилось место, уборщица жопой задела витую пару, затопило серверную, ураган, смерч, цунами, пьяный админ попутал, террористы, проводка погорела, попёрло гавно из санузла и давлением вдавило каки в стойку, ... Ещё?

hVosttМСУ2. Сегодня ты хочешь получить "данные за вчера", а их там нет. Что делать?
Ну я хочу получить данные за вчера, а не что-то-за-вчера-а-что-то-за-позавчера, полусостояние какое-то. Особенно если требуется сводные цифры, с учётом «до копья».
Сводные цифры сами по себе никому не нужны. Сводные цифры всегда в разрезе чего-то (период, тип, операция и так далее). Это называется измерением, мерой. Кто-то мерит одной мерой, кто-то другой. Зачем лишать пользователей 100% мер? Улавливаешь суть? Представь ситуацию, в горводе произошла авария и пропала холодная вода. А тебе за это отключили свет, газ и антенну. Справедливо? Ты начинаешь писать жалобы, а тебе в ответ - "раз имеется такая ошибка, значит и всей логике жилобеспечения доверять как-то сомнительно, это надо чинить". Занавес.

hVosttМСУ4. Образно говоря, в моём случае 80% сотрудников будут работать в штатном режиме и только 20% будут испытывать трудности, т.к. 1% невыполненной работы у тебя завалился. В твоём случае 100% работников будут сосать писю.
Как раз наоборот. В штатном режиме должно всё работать и давать 100% результат. Если что-то упало, значит косяк в логике, значит нафиг такая загрузка хоть в каком процентном эквиваленте нужна. Надо чинить. Или, если система не какая-нибудь банковская, то пох?
Никогда никто не даст таких гарантий, что всегда будет штатная ситуация и всё 100% отработает. Ты в космосе что ли? Я выше сказал, упало - это обязательно косяк в логике. Осознай это.

hVosttМСУ5. Профиты?
Ну, если постепенная побатчевая загрузка вообще никому не мешает, не портит и не влияет никоим образом ни на какие отчёты, ни с чем и ни с кем не конфликтует, всем юзерам целостность данных по барабану, если это заранее известно, что не надо строить иллюзий на 100% уверенность в актуальной инфе, пусть загружается хоть сколько-нибудь. То да, в твоём решении имеется чистый профит.
В моём решении - единственно верный вариант. Других вариантов быть не может. Абсолютно.

МСУЯ выше сказал, упало - это не обязательно косяк в логике. Осознай это.