Доброго дня!

Ситуация следующая. Имеется информатика 10.2. Две БД Oracle и большой запрос в качестве источника. На источнике в схеме данных(юзере), под которым с БД работает информатика, включено ограничение на оценочное время выполнения SQL (фича СУБД), если выполнять запрос целиком - валится с этом ошибкой, ибо тяжелый.

Переписан на информатику - несколько соурсов (легкие) и 4-5 лукапов. В лукапах SQL-запросы с большими таблицами. В исходном запросе они использовались таким образом, что сначала в них передавались ключи, а только потом производилась связка с остальными таблицами запроса, иначе без передачи ключей для выборки они работали неимоверно долго.

Попытался то же самое повторить следующим образом: отключил кэшировние лукапов, ожидая, что таким образом из основного потока в каждый из лукапов будет передаваться по одной записи(те самые ключи выборки) и результат буду получать достаточно быстро. Однако, что вижу в логах выполнения сессии, последние две записи в логе:






То есть, как я понимаю, запрос выполняется целиком все-таки, а только после выполнение его результат будет привязан к основному потоку. Убедиться в этом однозначно не имею возможности, так как нет доступа на просмотр сессий на источнике. К слову, в основном потоке данных, что приходит из соурсов всего 53 записи, совсем не много.

Подскажите, как сделать так, чтобы SQL в лукапе выполнялся отдельно для каждой записи в основном потоке (то есть 53 вызова с передачей параметров в текст запроса)?

PS
Дождаться отработки процесса пока не удалось ни разу... Оставлял на ночь, утром увидел те же сообщения в логи последними

По ссылке вот и она]https://docs.informatica.com/data-integration/data-services/10-2/developer-transformation-guide/lookup-caches/uncached-lookup.html английским по белому написано "The Integration Service processes an uncached lookup the same way it processes a cached lookup except that it queries the lookup source instead of building and querying the lookup cache."

Что подразумевается под "тем же путем" - сложно сказать, но, видимо, имеется ввиду, что данные в лукапе вычитываются полностью все-равно, только кэш не строится.

Думал переписать лукапы на соурсы, но тогда, как я понимаю, будет то же самое - джоины начинаются работать только тогда, когда прочитаны данные из соурсов, а не как работает запрос в БД. Значит, такой вариант тоже не подходит - то, что работает вечность у меня в лукапе сейчас так же будет работать в соурсе.

Ищу варианты..

Открыл для себя unconnected lookups, попробовал переделать на этот вариант в надежде, что оно будет работать, как ожидается.. Но нет, не взлетело

Ссылки по теме:

ссылка 1

ссылка 1

Anonymous_20,

Спасибо за ответ. Пока не приходилось SQL Transformaion использовать, не так давно работаю с информатикой. Посмотрю.
У вас есть опыт их использования в подобных ситуациях? Не хочется все переделать, а потом только из логов понять, что работает точно так же.. Или там именно параметрами передаются инпут порты в текст SQL?

Anonymous_20,

Благодарю. Опробовал так и есть. Передал параметры из инпут портов как бинды. Один вопрос остался - я так понял, что сразу несколько SQL transformation вызвать нельзя, чтобы потом вернуть с каждого из них данные в основной поток? Если у меня 5 разных запросов с разными параметрами, то мне нужно вызывать их один за одним - то есть в первый передаю инпут порты, с него передаю аутпут порты в инпут второго и т.д.?
Вроде как логично, так как неизвестно, сколько строк вернет мой SQL transformation. Но, с другой стороны, в моем случае строка будет всегда одна, и было бы удобно вызвать их как лукапы - из потока данных закинуть в них инпут порты и вернуть с каждого из них значения в основной поток, обогатив его таким образом.

Anonymous_20,

Благодарю. Да, речь о PowerCenter, не уточнил с самого начала :)
Сделал в итоге как писал выше - последовательно вызвал. Но про джоин хорошее замечания. Благодарю за помощь!

Господа, столкнулся с новым сервером информатике в другой конторе. Используются Power Exchange и Power Center.
В моем ограниченном мире до этого знакомства ситуация выглядела так - есть ETL-инструмент Informatica Power Center, и в нем я пилу процессы загрузки данных. При этом у Informatica есть некий отдельный продукт для CDC (эдакий аналог OGG).

Теперь:
смотрю уже реализованные маппинги в IPC Designer и обнаруживаю незнакомый мне тип источника и SQ с типом App Multi-Group Source Qualifier

Вопросы:
- Как это все работает? То есть все CDC процессы так же отрисовываются в IPC Designer?
- В папке Source не вижу источников кроме обычных таблиц. Этот источник смотрит на архивлоги (речь об Oracle) и использует их как источник данных? Если да, то как поддерживаются разные dml - в маппинге делается условие в Update Strategy?
- Если соображения выше верны, то по сути это выглядит так, будто функциональность IPC при наличии Power Exchange расширяется новыми источниками (заглянул в импорт источников и собственно их и увидел), а внутри себя уже Power Exchange сам работает с со своими источниками своими же средствами (например, через захват архивлогов, а не просто тянет данных из БД через odbc)?

Благодарю.

Коллеги, прошу помочь.

Используем Informatica PWX, крутятся CDC процессы. В PowerCenter маппинги для захвата информации из источников Power Exchange и загрузки их в целевую базу. Отрисовано все типовым способом - забираем данные, передаем в Update Strategy, там определяем тип dml операции и выполняем ее на таргете. Все сессии реализованы с поддержкой Recover Strategy на случай остановки процесса, а так же, чтобы можно было указать Restart-токены в соответствующих файлах и запустить процесс применения изменений не целевую базу с какого-то чекпоинта.
Теперь нужно сделать несколько другой процесс по логике, а именно что-то вроде SCD2 в самом маппинге - забрать данные, пойти в приемник лукапом (или как-то иначе), проверить наличие такой записи, а дальше уже применить какую-то логику для вставки\обновления\удаления. Попробовал 2 варианта:
1. Собственно с лукапом. Recover Strategy не поддерживается, так как кэшировать лукап нельзя, так как данные лукапа нужны в реальном времени
2. Перерисовал с с использованием SQL Transformation.. Думал, что в таком случае, он будет запоминать точку остановки из сорса, ну дальше пойдет по потоку и вытащит данные из SQL Transformation в реальном времени. Но вновь нет, сессия инвалидная, так как есть данные, которые "not repetable". Вроде тоже все логично.

Но совместить в CDC процессе логику подобную SCD2 и Recover Strategy?
Спасибо

upd.
И если отрисовать через второй Source+Join+логика дальше, где Source и Target - это одна таблица, то можно ли ожидать, что Source не будет кэшироваться при запуске, а каждый раз будет отдавать актуальные данные?

Коллеги, не стал новую тему создавать.

Есть такая задачка. Есть маппинг, в котором производятся некие dml-операции над target по ключу. Есть update strategy, который обрабатывает I, D, U. В случае с D выполняется DD_UPDATE - мягкое удаление, просто проставляется флаг IS_DELETED. При этом мне нужно изменить значение ключа. Ключом является текстовое поле(ROWID записи из источника, Oracle). Изменить его нужно в связи с тем, что запись в источнике удаляется физически, а, значит, через какое-то время может появиться новая запись с таким же ROWID, что вызывает коллизию на моей стороне. Как мне это реализовать?
Думал через post-sql на таргете через mapping variable с заполнением ее в Expression Tramsformation, но, как известно, в post sql будет передаваться только предыдущее значение, а мне нужно оперативно обновить именно по текущем. Находил совет использовать некую таблицу аудита, куда писать записи, подлежащие удалению. Но не понял, как применить это в моем случае..

И еще одна важная деталь - эта сессия работает постоянно, так как обслуживает CDC-процесс Power Exchange. То есть обновлять мне нужно на лету, а не после отработки этой самой сессии

Спасибо!