Знакомство с Oracle Database Express Edition (XE) – что это такое?
Приветствую всех посетителей сайта Info-Comp.ru! Сегодня мы с Вами познакомимся с Oracle Database Express Edition (XE) – это бесплатная редакция системы управления базами данных Oracle Database. Мы поговорим о том, что это за система, какие ограничения у бесплатной редакции и для чего ее можно использовать.
Oracle Database
Oracle – это крупнейшая в мире компания по разработке программного обеспечения для предприятий. Специализацией Oracle является разработка систем управления базами данных, таких как Oracle Database, а также других бизнес-приложений.
Oracle Database — это объектно-реляционная система управления базами данных (RDBMS или Relational DataBase Management System). Многие крупнейшие компании мира в качестве системы хранения баз данных выбирают именно Oracle Database.
В названии каждой версий Oracle Database мы наблюдаем номер версии и букву, например 11g, где g – это «grid» или сеть, символизируя тем самым поддержку grid-вычислений.
В 2013 году вышла версия 12c, где c означает cloud (облако).
В 2018 году вышла версия 18c, а на текущий момент активно используется версия 19с, которая вышла в 2019 году.
Данная СУБД поддерживает работу на многих платформах, включая: Linux, Windows, Oracle Solaris, Mac OS X Server и т.д.
В Oracle Database используется язык программирования PL/SQL (Procedural Language / Structured Query Language) — это расширение языка SQL, которое разработала компания Oracle.
Редакции Oracle Database
У компании Oracle есть несколько предложений в отношении продукта Oracle Database, при этом есть редакции, которые можно использовать локально (On-Premise) и в облаке (Cloud).
Давайте коротко рассмотрим эти редакции.
On-Premise
Oracle Database Standard Edition 2 (SE2)
Стандартная редакция, включающая в себя все средства, необходимые для создания критически важных бизнес-приложений. Данная редакция не поддерживает кластеризацию Oracle Real Application Clusters (Oracle RAC).
Примечание. Oracle Database Standard Edition 2 доступна, начиная с Oracle Database 12 c Release 1 (12.1.0.2). Для версии 12.1.0.1 доступны Oracle Database Standard Edition One и Oracle Database Standard Edition.
Oracle Database Enterprise Edition (EE)
Oracle Database Enterprise Edition обеспечивает производительность, доступность, масштабируемость и безопасность для разработки приложений, таких как: приложения для обработки больших объемов транзакций (OLTP), хранилища данных с интенсивными запросами и требовательные интернет-приложения.
Oracle Database Enterprise Edition содержит все компоненты Oracle Database, но может быть дополнительно расширена путем приобретения опций и пакетов.
Oracle Database Enterprise Edition on Engineered Systems (EE-ES)
Специальная редакция для установки в локальной системе Oracle Exadata Database Machine или Oracle Database Appliance.
Включает в себя все компоненты Oracle Database, но может быть дополнительно расширена путем приобретения опций и пакетов.
Политики лицензирования EE-ES различаются в зависимости от того, установлена ли она на Oracle Exadata Database Machine или Oracle Database Appliance.
Oracle Database Personal Edition (PE)
Редакция Oracle Database Personal Edition поддерживает однопользовательские среды разработки и развертывания, требующие полной совместимости с Oracle Database Standard Edition 2 и Oracle Database Enterprise Edition.
Данная редакция включает в себя все компоненты и опции, входящие в Enterprise Edition, за исключением опции Oracle RAC One Node и Oracle Real Application Clusters, которые нельзя использовать с Personal Edition. Кроме этого пакеты управления Oracle также не получится использовать с редакцией Personal Edition.
Oracle Database Express Edition (XE)
Oracle Database Express Edition – это бесплатная редакция, которую можно использовать для обучения или для разработки небольших приложений.
Безусловно данная редакция имеет много ограничений как в части функциональности, так и в объеме использования ресурсов, но об этом чуть позже.
Кроме этого, поддержка предоставляется только на онлайн-форуме.
Cloud
Кроме редакций, которые можно установить локально, есть еще и несколько облачных редакций:
Более подробно о редакциях, их возможностях и ограничениях можете почитать на официальном сайте в разделе – Информация о лицензировании базы данных.
Ну а мы перейдем к знакомству с редакцией Oracle Database Express Edition (XE), которую можно использовать абсолютно бесплатно.
Oracle Database Express Edition (XE)
Oracle Database Express Edition (Oracle Database XE) – это бесплатная редакция системы управления базами данных Oracle Database.
Данная редакция хоть и бесплатна, но обладает достаточно хорошим функционалом, это и Oracle Database In-Memory, и секционирование, функционал для аналитики и безопасности данных и многое другое.
Иными словами, не нужно думать, что в этой редакции нет никакого функционала, он есть, и может удовлетворить многие предприятия. Безусловно, для крупных компаний данная редакция не подойдет, но для компаний, которые только стартуют, Oracle Database Express Edition будет неплохим выбором, а если вдруг компания вырастет и ей нужно будет масштабироваться, то она легко может перейти на более функциональные редакции Oracle Database, и тем самым получать регулярные исправления и круглосуточную поддержку.
Ограничения редакции Oracle Database Express Edition (XE)
Данная редакция имеет ограничения как в части функциональности, так и в объеме использования ресурсов, а также в формате поддержки:
Для чего можно использовать Oracle Database Express Edition (XE)
Давайте поговорим о том, в каких случаях нам может пригодиться данная редакция, кто и для чего ее может использовать.
Для разработки приложений
Если Вы планируете разрабатывать различные приложения для клиентов, при этом эти приложения должны иметь возможность хранения и обработки данных, то в качестве системы хранения данных Вы можете использовать бесплатную редакцию Oracle Database Express Edition (XE) и тем самым снижать стоимость своего продукта и, как следствие, первоначальные расходы своих клиентов.
А в случае, если компания клиент вырастет, и у него возникнет необходимость масштабироваться, то он без каких-либо проблем сможет это сделать путем приобретения лицензии и обновления системы до соответствующей редакции. Таким образом, никаких проблем с миграцией данных, адаптации приложения у клиента не возникнет.
Для хранения и анализа небольших данных
Если в Вашей компании возникла необходимость в хранении, обработке и анализе данных, при этом текущая информационная система не обладает теми преимуществами, которыми обладает реляционная система управления базами данных, то Вы можете использовать бесплатную редакцию Oracle Database Express Edition (XE) и тем самым хранить какую-то часть данных в реляционном виде и решать определенные задачи.
Для изучения языка SQL
Если Вы хотите изучить язык SQL, то Вам обязательно необходима площадка для обучения, где бы Вы смогли практиковаться и решать различные задачки.
Однако для таких целей покупать целую систему управления базами данных, конечно же, не стоит, да и не требуется, так как есть бесплатные системы, которые отлично справятся с такой ролью. В число таких систем входит как раз Oracle Database Express Edition (XE), которую можно использовать для изучения языка SQL или языка PL/SQL, который является процедурным расширением языка SQL в Oracle Database.
Например, если Вы планируете устроиться в компанию, где используется Oracle Database и требуются знания языка SQL, или Вы уже работаете в такой компании и Вам предстоит работать с этой системой, то Вы можете абсолютно свободно установить Oracle Database Express Edition (XE) к себе на домашний компьютер с целью изучения языков SQL и PL/SQL.
Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней очень подробно рассмотрены основные конструкции языка.
Для тестирования функционала Oracle Database
Безусловно, данную редакцию не стоит рассматривать в качестве системы хранения данных для крупных Enterprise проектов, так как ограничения этой редакции не позволят Вам в полном объёме использовать возможности и функционал этой системы.
Однако, крупные компании перед покупкой лицензии, с целью тестирования функционала системы, планирования инфраструктуры, а также тестирования приложений, могут абсолютно свободно использовать для таких задач бесплатную редакцию Oracle Database Express Edition (XE).
Для реализации разовых проектов
Кроме всего вышеперечисленного Вы можете использовать данную редакцию в проектах, в которых требуется применение реляционной базы данных или конкретно технологий Oracle Database, но при этом нет жестких требований к функциональности и производительности.
Например, у меня как-то раз стояла задача мигрировать данные с Microsoft SQL Server в Oracle Database, дело в том, что компания внедряла новую информационную систему, разработкой которой занимался подрядчик, и этому подрядчику необходимо было предоставлять данные из нашей прежней системы в формате дампа Oracle Database.
Но, как было уже отмечено, наша система работала с Microsoft SQL Server, поэтому чтобы представлять данные в формате дампа Oracle, мне пришлось установить бесплатную редакцию Oracle Database Express Edition (XE), загружать данные с Microsoft SQL Server в эту промежуточную систему, и затем выгружать данные в дамп.
Подробно о том, как создать дамп базы данных Oracle Database, я рассказывал в материале – Экспорт и импорт дампа базы данных Oracle с помощью утилит expdp и impdp.
Таким образом, Oracle Database Express Edition (XE) можно использовать не только для хранения данных на постоянной основе, но и для хранения промежуточных данных при реализации того или иного проекта.
На сегодня это все. В следующих материалах мы продолжим знакомство с Oracle Database Express Edition (XE) и начнем с рассмотрения процесса установки, поэтому следите за выходом новых статей в моих группах в социальных сетях: ВКонтакте, Facebook, Одноклассники, Twitter и Tumblr. Подписывайтесь, и Вы не пропустите выход нового материала!
10 приёмов работы с Oracle
В Сбере есть несколько практик Oracle, которые могут оказаться вам полезны. Думаю, часть вам знакома, но мы используем для загрузки не только ETL-средства, но и хранимые процедуры Oracle. На Oracle PL/SQL реализованы наиболее сложные алгоритмы загрузки данных в хранилища, где требуется «прочувствовать каждый байт».
Автоматическое журналирование компиляций
На некоторых базах данных Oracle в Сбере стоит триггер на компиляцию, который запоминает, кто, когда и что менял в коде серверных объектов. Тем самым из таблицы журнала компиляций можно установить автора изменений. Также автоматически реализуется система контроля версий. Во всяком случае, если программист забыл сдать изменения в Git, то этот механизм его подстрахует. Опишем пример реализации такой системы автоматического журналирования компиляций. Один из упрощённых вариантов триггера на компиляцию, пишущего в журнал в виде таблицы ddl_changes_log, выглядит так:
В этом триггере получают название и новое содержимое компилируемого объекта, дополняют его предыдущим содержимым из словаря данных и записывают в лог изменений.
Как быть, если хочется сделать вьюшку с параметрами
Такое желание может часто посещать разработчика на Oracle. Почему можно сделать процедуру или функцию с параметрами, но не бывает вьюшек с входными параметрами, которые можно использовать при вычислениях? В Oracle есть чем заменить это недостающее, на наш взгляд, понятие.
Рассмотрим пример. Пусть есть таблица с продажами по подразделениям за каждый день.
Такой запрос сравнивает продажи по подразделениям за два дня. В данном случае, 30.04.2020 и 11.09.2020.
Вот вьюшка, которую хочется написать для обобщения такого запроса. Хочется передавать даты в качестве параметров. Однако синтаксис не позволяет такое сделать.
Предлагается такое обходное решение. Создадим тип под строку из этой вьюшки.
И создадим тип под таблицу из таких строк.
Вместо вьюшки напишем pipelined функцию с входными параметрами-датами.
Обращаться к ней можно так:
Этот запрос и выдаст нам такой же результат, как запрос в начале этой заметки с явным образом подставленными датами.
Pipelined функции могут быть также полезны, если нужно передать параметр внутрь сложного запроса.
Например, рассмотрим сложную вьюшку, в которой поле field1, по которому хочется отфильтровать данные, запрятано где-то глубоко во вьюшке.
И запрос из вьюшки с фиксированным значением field1 может иметь плохой план выполнения.
Т.е. вместо того, чтобы сначала отфильтровать deep_table по условию field1 = ‘myvalue’, запрос может сначала соединить все таблицы, обработав излишне большой объём данных, а потом уже фильтровать результат по условию field1 = ‘myvalue’. Такой сложности можно избежать, если сделать вместо вьюшки pipelined функцию с параметром, значение которого присваивается полю field1.
Использование динамической статистики в запросах
Бывает, что один и тот же запрос в БД Oracle обрабатывает всякий раз различный объём данных в использующихся в нём таблицах и подзапросах. Как заставить оптимизатор всякий раз понимать, какой из способов соединения таблиц на этот раз лучше и какие индексы использовать? Рассмотрим, например, запрос, который соединяет порцию изменившихся с последней загрузки остатков по счетам со справочником счетов. Порция изменившихся остатков по счетам сильно меняется от загрузки к загрузке, составляя то сотни строк, то миллионы строк. В зависимости от размера этой порции требуется соединять изменившиеся остатки со счетами то способом /*+ use_nl*/, то способом /*+ use_hash*/. Всякий раз повторно собирать статистику неудобно, особенно, если от загрузки к загрузке изменяется количество строк не в соединяемой таблице, а в соединяемом подзапросе. На помощь тут может прийти хинт /*+ dynamic_sampling()*/. Покажем, как он влияет, на примере запроса. Пусть таблица change_balances содержит изменения остатков, а accounts – справочник счетов. Соединяем эти таблицы по полям account_id, имеющимся в каждой из таблиц. В начале эксперимента запишем в эти таблицы побольше строк и не будем менять их содержимое.
Сначала возьмём 10% изменений остатков в таблице change_balances и посмотрим, какой план будет с использованием dynamic_sampling:
Итак, видим, что предлагается пройти таблицы change_balances и accounts с помощью full scan и соединить их посредством hash join.
Теперь резко уменьшим выборку из change_balances. Возьмём 0.1% изменений остатков и посмотрим, какой план будет с использованием dynamic_sampling:
На этот раз к таблице change_balances таблица accounts присоединяется посредством nested loops и используется индекс для чтения строк из accounts.
Если же хинт dynamic_sampling убрать, то во втором случае план останется такой же, как в первом случае, и это не оптимально.
Подробности о хинте dynamic_sampling и возможных значениях его числового аргумента можно найти в документации.
Как сохранить план запроса при вставке данных через database link
Решаем такую задачу. На сервере-источнике данных имеются таблицы, которые нужно соединить и загрузить в хранилище данных. Допустим, на сервере-источнике написана вьюшка, которая содержит в себе всю нужную ETL-логику преобразований. Вьюшка написана оптимально, в ней указаны хинты оптимизатору, подсказывающие, как соединять таблицы и какие индексы использовать. На стороне сервера хранилища данных нужно сделать несложную вещь – вставить данные из вьюшки в целевую таблицу. И тут могут возникнуть сложности. Если вставку в целевую таблицу осуществить командой вида
, то вся логика плана запроса, содержащаяся во вьюшке, из которой читаем данные по database link, может быть проигнорирована. Все хинты, зашитые в этой вьюшке могут быть не учтены.
Чтобы сохранить план запроса во вьюшке, можно воспользоваться вставкой данных в целевую таблицу из курсора:
в отличие от вставки
сохранит план запроса, заложенный во вьюшку на сервере-источнике.
Запуск процедур в параллельных сессиях
Часто стоит задача запустить из некоторой родительской процедуры несколько параллельных расчётов и, дождавшись завершения каждого из них, продолжить выполнение родительской процедуры. Это может быть полезно при параллельных вычислениях, если ресурсы сервера позволяют это. Есть много способов сделать это.
Опишем очень простой вариант реализации такого механизма. Параллельные процедуры будем выполнять в параллельных “одноразовых” джобах, родительская же процедура в цикле будет ожидать завершения всех этих джобов.
Создадим таблицы с метаданными для этого механизма. Для начала сделаем таблицу с группами параллельно запускаемых процедур:
Далее создадим таблицу со скриптами, которые будут параллельно выполняться в группах. Наполнение этой таблицы может быть как статическим, так и создаваться динамически:
И сделаем таблицу журнала, где будем собирать лог того, какая процедура когда в каком джобе запускалась:
Теперь приведём код процедуры по запуску параллельных потоков:
Проверим, как работает процедура run_in_parallel. Создадим тестовую процедуру, которую будем вызывать в параллельных сессиях.
Заполним название группы и таблицу со cкриптами, которые будут выполняться параллельно.
Запустим группу параллельных процедур.
По завершении посмотрим лог.
| RUN_ID | GROUP_ID | PROC_SCRIPT | JOB_ID | START_TIME | END_TIME |
| 1 | 1 | begin sleep(5); end; | 1 | 11.09.2020 15:00:51 | 11.09.2020 15:00:56 |
| 1 | 1 | begin sleep(10); end; | 2 | 11.09.2020 15:00:51 | 11.09.2020 15:01:01 |
Видим, что время выполнения экземпляров тестовой процедуры соответствует ожиданиям.
Протягивание остатков
Опишем вариант решения достаточно типовой банковской задачи по “протягиванию остатков”. Допустим, имеется таблица фактов изменения остатков по счетам. Требуется на каждый день календаря указать актуальный остаток по счёту (последний за день). Такая информация часто бывает нужна в хранилищах данных. Если в какой-то день не было движений по счёту, то нужно повторить последний известный остаток. Если объёмы данных и вычислительные мощности сервера позволяют, то можно решить такую задачу с помощью SQL-запроса, даже не прибегая к PL/SQL. Поможет нам в этом функция last_value(* ignore nulls) over(partition by * order by *), которая протянет последний известный остаток на последующие даты, в которых не было изменений.
Создадим таблицу и заполним её тестовыми данными.
Нижеприведённый запрос решает нашу задачу. Подзапрос ‘cld’ содержит календарь дат, в подзапросе ‘ab’ группируем остатки за каждый день, в подзапросе ‘a’ запоминаем перечень всех счетов и дату начала истории по каждому счёту, в подзапросе ‘pre’ для каждого счёта составляем календарь дней с начала его истории. Финальный запрос присоединяет к календарю дней активности каждого счёта последние остатки на каждый день и протягивает их на дни, в которых не было изменений.
Результат запроса соответствует ожиданиям.
| DT | ACCOUNT_ID | BALANCE_AMT | TURNOVER_AMT |
| 01.01.2020 | 1 | 23 | 23 |
| 02.01.2020 | 1 | 23 | 0 |
| 03.01.2020 | 1 | 23 | 0 |
| 04.01.2020 | 1 | 23 | 0 |
| 05.01.2020 | 1 | 44 | 21 |
| 06.01.2020 | 1 | 44 | 0 |
| 07.01.2020 | 1 | 44 | 0 |
| 08.01.2020 | 1 | 44 | 0 |
| 09.01.2020 | 1 | 44 | 0 |
| 10.01.2020 | 1 | 44 | 0 |
| 05.01.2020 | 2 | 77 | 77 |
| 06.01.2020 | 2 | 77 | 0 |
| 07.01.2020 | 2 | 72 | -5 |
| 08.01.2020 | 2 | 72 | 0 |
| 09.01.2020 | 2 | 72 | 0 |
| 10.01.2020 | 2 | 72 | 0 |
Объединение нескольких историй в одну
При загрузке данных в хранилища часто решается задача, когда нужно выстроить единую историю по сущности, имея отдельные истории атрибутов этой сущности, пришедшие из различных источников. Допустим, имеется некоторая сущность с первичным ключом primary_key_id, о которой известна история (start_dt — end_dt) трёх её различных атрибутов, расположенная в трёх различных таблицах.
Целью является загрузка единой истории изменения трёх атрибутов в одну таблицу.
Ниже приведён запрос, решающий такую задачу. В нём сначала формируется диагональная таблица q1 с данными из разных источников по разным атрибутам (отсутствующие в источнике атрибуты заполняются null-ами). Затем с помощью функции last_value(* ignore nulls) диагональная таблица схлопывается в единую историю, а последние известные значения атрибутов протягиваются вперёд на те даты, в которые изменений по ним не было:
Результат получается такой:
| PRIMARY_KEY_ID | START_DT | END_DT | ATTRIBUTE1 | ATTRIBUTE2 | ATTRIBUTE3 |
| 1 | 01.01.2014 | 31.12.2014 | 7 | NULL | NULL |
| 1 | 01.01.2015 | 31.12.2015 | 8 | 4 | NULL |
| 1 | 01.01.2016 | 31.12.2016 | 9 | 5 | 10 |
| 1 | 01.01.2017 | 31.12.2017 | 9 | 6 | 20 |
| 1 | 01.01.2018 | 31.12.9999 | 9 | 6 | 30 |
| 2 | 01.01.2014 | 31.12.2014 | 17 | NULL | NULL |
| 2 | 01.01.2015 | 31.12.2015 | 18 | 14 | NULL |
| 2 | 01.01.2016 | 31.12.2016 | 19 | 15 | 110 |
| 2 | 01.01.2017 | 31.12.2017 | 19 | 16 | 120 |
| 2 | 01.01.2018 | 31.12.9999 | 19 | 16 | 130 |
Нормалайзер
Иногда встаёт задача о нормализации данных, пришедших в формате поля с разделителями. Например, в виде такой таблицы:
Такой запрос нормализует данные, расклеив соединённые запятой поля в виде нескольких строк:
Результат получается такой:
| ID | VAL | COLUMN_VALUE |
| 1 | aaa | 1 |
| 1 | cccc | 2 |
| 1 | bb | 3 |
| 2 | ddd | 1 |
| 3 | fffff | 1 |
| 3 | e | 2 |
Визуализация в формате SVG
Часто возникает желание как-то визуализировать числовые показатели, хранящиеся в базе данных. Например, построить графики, гистограммы, диаграммы. В этом могут помочь специализированные средства, например, Oracle BI. Но лицензии на эти средства могут стоить денег, а настройка их может занять больше времени, чем написание “на коленке” SQL-запроса к Oracle, который выдаст готовую картинку. Продемонстрируем на примере, как с помощью запроса быстро нарисовать такую картинку в формате SVG.
Предположим, у нас есть таблица с данными
dt – это дата актуальности,
val – это числовой показатель, динамику которого по времени мы визуализируем,
radius – это ещё один числовой показатель, который будем рисовать в виде кружка с таким радиусом.
Скажем пару слов о формате SVG. Это формат векторной графики, который можно смотреть в современных браузерах и конвертировать в другие графические форматы. В нём, среди прочего, можно рисовать линии, кружки и писать текст:
Ниже SQL-запрос к Oracle, который строит график из данных в этой таблице. Здесь подзапрос const содержит различные константные настройки – размеры картинки, количество меток на осях графика, цвета линий и кружочков, размеры шрифта и т.д. В подзапросе gd1 мы приводим данные из таблицы graph_data к координатам x и y на рисунке. Подзапрос gd2 запоминает предыдущие по времени точки, из которых нужно вести линии к новым точкам. Блок ‘header’ – это заголовок картинки с белым фоном. Блок ‘vertical lines’ рисует вертикальные линии. Блок ‘dates under vertical lines’ подписывает даты на оси x. Блок ‘horizontal lines’ рисует горизонтальные линии. Блок ‘values near horizontal lines’ подписывает значения на оси y. Блок ‘circles’ рисует кружочки указанного в таблице graph_data радиуса. Блок ‘graph data’ строит из линий график динамики показателя val из таблицы graph_data. Блок ‘footer’ добавляет замыкающий тэг.
Результат запроса можно сохранить в файл с расширением *.svg и посмотреть в браузере. При желании можно с помощью какой-либо из утилит конвертировать его в другие графические форматы, размещать на веб-страницах своего приложения и т.д.
Получилась такая картинка:
Приложение поиска по метаданным Oracle
Клиентская часть не сложная. Веб-интерфейс получает введённую пользователем поисковую строку, список серверов для поиска и логин пользователя. Веб-страница передаёт их в хранимую процедуру Oracle на сервере-обработчике. История обращений к поисковику, т.е. кто какой запрос выполнял, на всякий случай журналируется.
Получив поисковый запрос, серверная часть на поисковом сервере Oracle запускает в параллельных джобах несколько процедур, которые по database links на выбранных серверах Oracle сканируют следующие представления словаря данных в поисках искомой строки: dba_col_comments, dba_jobs, dba_mviews, dba_objects, dba_scheduler_jobs, dba_source, dba_tab_cols, dba_tab_comments, dba_views. Каждая из процедур, если что-то обнаружила, записывает найденное в таблицу результатов поиска (с соответствующим ID поискового запроса).
Когда все поисковые процедуры завершили работу, клиентская часть выдаёт пользователю всё, что записалось в таблицу результатов поиска с соответствующим ID поискового запроса.
Но это ещё не всё. Помимо поиска по словарю данных Oracle в описанный механизм прикрутили ещё и поиск по репозиторию Informatica PowerCenter. Informatica PowerCenter является популярным ETL-средством, использующимся в Сбербанке при загрузке различной информации в хранилища данных. Informatica PowerCenter имеет открытую хорошо задокументированную структуру репозитория. По этому репозиторию есть возможность искать информацию так же, как и по словарю данных Oracle. Какие таблицы и поля используются в коде загрузок, разработанном на Informatica PowerCenter? Что можно найти в трансформациях портов и явных SQL-запросах? Вся эта информация имеется в структурах репозитория и может быть найдена. Для знатоков PowerCenter напишу, что наш поисковик сканирует следующие места репозитория в поисках маппингов, сессий или воркфловов, содержащих в себе где-то искомую строку: sql override, mapplet attributes, ports, source definitions in mappings, source definitions, target definitions in mappings, target_definitions, mappings, mapplets, workflows, worklets, sessions, commands, expression ports, session instances, source definition fields, target definition fields, email tasks.
Автор: Михаил Гричик, эксперт профессионального сообщества Сбербанка SberProfi DWH/BigData.
Профессиональное сообщество SberProfi DWH/BigData отвечает за развитие компетенций в таких направлениях, как экосистема Hadoop, Teradata, Oracle DB, GreenPlum, а также BI инструментах Qlik, SAP BO, Tableau и др.