Мы использовали шаблон SSIS, основанный на инверсии строк, для синхронизации записей между двумя базами данных путем просмотра только тех строк в источнике, которые были вставлены или обновлены с момента последнего запуска пакета. Данные примечаний никогда не удаляются из исходной таблицы, что является обязательным условием для этого шаблона служб SSIS.
Однако в последнее время мы обнаружили, что, несмотря на ежедневную работу, наш импорт фактически пропустил строки с прошлого месяца, полностью исключив их из нашего хранилища данных! Это то, что я ищу решение ... как мы можем изменить наш шаблон ETL, чтобы избежать этой проблемы, не возвращаясь к чтению каждой строки из источника каждый день?
Из поиска в Интернете мы нашлиобъяснение того, почему это может происходить, но не решение. Недостаток, по-видимому, связан с тем фактом, что версия строки столбца SQL получает свое значение при запуске вставки / обновления, а не при фиксации, что может привести к тому, что строки не будут доступны во время выполнения пакета, но будут зафиксированы позднее при меньших значениях версии строкичем ваше сохраненное значение ETLRowversion, поэтому при следующем запуске задания они будут пропущены.
Короче говоря, наш шаблон в настоящее время выглядит следующим образом: (я упустил шаги, включающие обслуживание индекса и т. д. для простоты.)
- Получите последнюю активную версию строки из исходной БД, используя
min_active_rowversion() вызов, @MaxRv. - Получите значение строки при последнем успешном выполнении нашей задачи SSIS (хранится в нашемхранилище данных в таблице под названием
ETLRowversions). Вызовите это @LSERV. - Чтение строк из исходной таблицы
WHERE rowversion is >= @LSERV and rowversion is <= @MaxRv - Для каждого чтения строки проверьте, существует ли строка в целевой БД (если это так, добавьте строку в этап обновления)таблица) или нет (в этом случае вставьте ее непосредственно в таблицу назначения)
- Обновите таблицу назначения с помощью промежуточной таблицы обновления
- Обновите таблицу
ETLrowVersions в нашем хранилище данных с помощью @MaxRv значение.
Редактировать: В комментариях было предложено использовать отслеживание изменений и изоляцию моментальных снимков как лучшее решение этой проблемы. К сожалению, и отслеживание изменений, и allow_snapshot_isolation отключены для исходной базы данных ... и я пессимистично оцениваю свои шансы на включение этих функций. Что бы там ни было, наши проблемы с бизнес-аналитикой имеют гораздо меньший вес, чем проблемы производительности производственного приложения / БД, являющегося нашим источником.