oracle обучение для начинающих

База данных Oracle Database для начинающих: основы базы данных

Светлана Комарова

Автор статьи. Системный администратор, Oracle DBA. Информационные технологии, интернет, телеком. Подробнее.

Здравствуйте, мои читатели. Статья предназначена новичкам в области баз данных Оракл. Тем, кто только собирается изучать эту предметную область и стать администраторами СУБД Oracle. Итак, с чего начать. Сразу отмечу, что никакого идеального исходного уровня подготовки для того, чтобы стать администратором баз данных Oracle, не существует, но крайне желательно, чтобы присутствовал истинный интерес к аппаратной стороне баз данных, а также приличный объем знаний по операционным системам, серверам UNIX и NT, а также вопросам, касающимся дисков и памяти.

Также очень сильно помогает наличие навыков по программированию или разработке, потому что будет часто доводиться работать вместе с разработчиками. Чаще всего для баз данных Oracle применяется операционная система UNIX, а именно — версии UNIX производства компаний Hewlett-Packard (HP) и Sun Microsystems (Sun). Компания IBM поставляет AIX-вариант операционной системы UNIX, но предлагает к ней свой собственный патентованный продукт для построения баз данных под названием DB2 Universal Database.

При желании обучиться на профессионального администратора баз данных Oracle Database 11g, нужно проходить два следующих тренировочных курса от компании Oracle или какого-нибудь другого поставщика: Oracle Database 11g:

Всего существуют три уровня сертификации для администраторов баз данных Oracle. Первый подразумевает получение сертификата OCA (Oracle Certified Associate — дипломированный младший специалист по Oracle), второй — сертификата OCP (Oracle Certified Professional — дипломированный профессионал по Oracle), который чаще все- го стремятся получить люди, профессионально занимающиеся базами данных Oracle, и третий, последний — сертификата OCM (Oracle Certified Master — дипломированный мастер по Oracle), для которого требуется сдавать длинный двухдневный практический экзамен.

Все кандидаты на получение сертификата администратора баз данных Oracle Database 11g обязаны проходить один физический или онлайновый курс из списка одобренных, чтобы отвечать новому требованию практического курса. Те, у кого на фирме используются кластеры RAC (Real Application Clusters — кластеры реальных приложений) или распределенные базы данных Oracle, должны проходить дополнительные, специализированные курсы обучения. Тем, у кого на фирме используется операционная система UNIX, и у кого нет опыта работы с ней, может быть лучше начинать с прохождения базового курса по UNIX (или Linux) от HP, Sun, Red Hat или другого производителя.

Для получения сертификата администратора баз данных Oracle проходит такой курс не обязательно, но он, несомненно, будет полезен для тех, кто является новичком в среде UNIX или Linux. Сама компания Oracle тоже предлагает несколько курсов по администрированию систем Linux, и даже возможность получения сертификата по управлению Oracle в Linux в рамках программы Oracle Certified Expert Program. Конечно, те, кто планирует использовать базы данных Oracle в среде Windows, вполне могут обойтись и без прохождения длинного и формального курса по управлению Windows при условии, что довольно хорошо знакомы с операционной системой Windows, а то и вообще работают системным администратором Windows.

На заметку! Не следует забывать о том, что компания Oracle Corporation не единственная занимается проведением тренингов по Oracle. Хотя Oracle University и является крупным учреждением с замечательными курсами, другие частные поставщики предлагают не менее, а в некоторых случаях даже и более замечательные курсы. Как это бывает со всеми курсами, качество обучения напрямую зависит от опыта и коммуникационных навыков преподавателя. А также не следует забывать и о том, что ходить куда-то на семинары вовсе не обязательное: вполне можно приобретать самообучающие компакт-диски и заниматься самостоятельно, причем в несколько (приблизительно в 15) раз дешевле, чем на физических тренингах с инструктором. Даже еще эффективнее может быть подписаться на онлайновую обучающую программу компании Oracle под названием Oracle iLearning (http://ilearning.oracle.com). Это дешевле, чем покупать DVD-диски, и открывает доступ к сотням курсов Oracle University. Решив проходить эти курсы, нужно обязательно заботиться о наличии доступа к серверу с фактической базой данных. Oracle поставляет очень хорошо спроектированные образцы схем, которые можно использовать для оттачивания своих навыков работы с SQL как с помощью своей собственный базы данных, находящейся на стадии разработки на сервере UNIX, так и с помощью доступной бесплатно для загрузки Windows-версии базы данных Oracle Database 11g Enterprise Edition на настольном компьютере. При таком подходе обучение будет проходить гораздо быстрее.

С началом работы в должности администратора баз данных Oracle Database 11g будет обнаруживаться, что настоящий мир баз данных Oracle гораздо шире и сложнее того, о котором рассказывалось на различных посещавшихся курсах. По мере обнаружения каждой новой грани базы данных будет становиться все понятнее и понятнее, как устроено программное обеспечение, почему оно работает и почему иногда оно не работает. Только тогда о базах данных и применяемом для управления ими программном обеспечении можно будет узнать больше всего. Прочитав действительно все материалы, которые предлагает Oracle и другие, все равно не стоит беспокоиться, потому что всегда появляются новые версии, с новыми функциональными возможностями и новыми механизмами работы, что практически гарантирует бесконечное поступление новой информации.

Проработав администратором баз данных один или два года, вы уже будете знать достаточно для того, чтобы компетентно осуществлять администрирование баз данных и устранять типичные возникающие с ними проблемы. Те, кто за это время также не будет переставать совершенствовать и свои навыки программирования (главным образом посредством написания сценариев для оболочки UNIX и работы с PL/SQL), смогут даже начать создавать сложные сценарии для осуществления мониторинга и настройки производительности баз данных. После этого те, кто двинется дальше, смогут узнавать еще гораздо больше о программном обеспечении своих баз данных и тем самым повышать свои знания и свой вклад в работу организации. Компания Oracle постоянно выпускает новые средства, которые тоже можно осваивать для улучшения производительности производственных баз данных. Хотя разработчики, тестировщики и системные администраторы тоже вовсю стараются во благо организации, именно администратор баз данных в конечном итоге будет прокладывать путь к новым и эффективным способам применения новых возможностей базы данных.

Источник

СУБД Oracle, базы данных, запросы SQL. Обучение, курсы Oracle для чайников, начинающих и профессионалов. Новичкам. Oracle с нуля. Выпуск 1

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

Почему это будет трудно для меня? Дело в том, что я тоже буду учиться вместе с моими подписчиками. А так как на мне лежит ответственность за Ваше продвижение вперед, так как я должен буду отвечать на вопросы, собирать материал, то я просто обязан идти на шаг вперед. И, пока Вы будете изучать текущий выпуск, мне надо будет готовить следующий.

Как я и обещал, начнем мы с самого простого.

Краткая история ORACLE.

В 1977г. Ларри Эллисон, Боб Майнер и Эд Оуэтс организовали свое дело, назвав фирму Relational Software Incorporated (RSI). Именно эта компания положила начало системе управления реляционными базами данных (СУРБД) Oracle. Эллисон, Майнер и Оуэтс решили разработать СУРБД, используя язык C и SQL-интерфейс. И вскоре вышла первая версия (прототип). Покупателям в 1979г. была представлена СУРБД Oracle версии 2, которая работала на Digital PDP-11, под управлением ОС RSX-11. Затем была портирована на систему DEC VAX.

1983г. стал вестником релиза версии 3, который привнес изменения в язык SQL, увеличил производительность системы и добавил некоторые другие улучшения. В отличие от предыдущих, третья версия была полностью написана на С. С этого момента RSI сменила свое название на Oracle Corporation.

Oracle версии 4 был представлен в 1984г. Эта версия поддерживала как ОС VAX, так и IBM VM. Эта версия предоставляла возможность многопользовательского стабильного чтения данных. Версия 5 появилась в 1985г. и стала поворотным пунктом на рынке СУБД, так как впервые представила технологию клиент-сервер, используя SQL*Net. Пятая версия стала также одной из первых MS DOS программ, перешагнувших через 640Kb-ый барьер.

В 1988г. Oracle представила версию 6. В этой версии появилась низкоуровневая блокировка и множество других изменений, увеличивших производительность и функциональность (включая генерацию последовательностей и отложенные записи). Oracle работает уже на множестве платформ и на разных операционных системах. В 1991г. вышел Сервер Параллельной Обработки СУРБД Oracle версии 6.1 для системы DEC VAX. Вскоре эта версия стала поддерживать и другие платформы.

В 1997г. вышла версия 8, которая привнесла объектную модель, новые свойства и средства администрирования.

В 1999г. вышла версия 8i (Oracle 8.1.5) со встроенным языком Java.

Как видите, продукту Oracle уже 25 лет, а нам предстоит наверстать все эти «упущенные» годы за значительно более короткий срок. Последняя версия продукта включает в себя 75 разных серверных продуктов, но большинство из них выходят за рамки нашего курса.

Основные понятия и условные сокращения

Прежде, чем мы начнем изучение Oracle, необходимо, чтобы всем были ясны термины, которые будут встречаться в тексте. В каждом выпуске рассылки будет раздел «Основные понятия», чтобы читатели не тратили свое время на поиск определений незнакомых слов.

Конфигурации ORACLE

Существует много видов конфигураций. Давайте рассмотрим основные из них, проанализируем и определим характеристики.

Видео-сервер : позволяет поддерживать большое количество видеопотоков. Эти видеопотоки могут использоваться по заказу, в качестве развлечения и как обучающие курсы.
Характерные черты видео-сервера : должен иметь широкую полосу пропускания, чтобы поддерживать несколько видеопотоков. Также, должен быть способен справляться с большой нагрузкой ввода/вывода. При чтении с устройств, загружаются сразу большие блоки данных, которые мало фрагментированы.

Веб-сервер : предназначен для работы со статическими и динамическими веб-страницами. Эти страницы могут быть как очень простыми, так и комплексными, генерируемыми из базы данных. Веб-сервер Oracle, как правило, используется для коммерческих веб-приложений. Такие
приложения позволяют покупателям просматривать каталоги, которые содержат изображения товаров и даже видео иллюстрации. Покупатель может приобрести понравившийся товар.
Характерные черты веб-сервера Oracle : обычно поддерживает значительное число пользователей, содержит большое число данных, к которым обращаются часто, и, в то же время, данные, к которым обращаются не очень часто. Производительность сервера может улучшить большое количество оперативной памяти.

Заключение

Источник

Оракл для начинающих | Oracle for beginners (18+)

Оракл для начинающих. Советы программистам, администраторам, IT-специалистам, только начинающим изучать СУБД Oracle. Оракл для чайников.

INNER JOIN vs LEFT RIGHT FULL OUTER JOIN

INNER JOIN
Inner join или просто join возвращает только те строки из двух таблиц, которые удовлетворяют условию указанному в ON:

SELECT
s.id,
s.supplier_name,
o.order_date
FROM suppliers s
INNER JOIN orders o
ON o.supplier_id = s.id;

OUTER JOIN
Outer join возвращает все строки, удовлетворяющие условию, указанному в ON, а также некоторые строки, которые не удовлетворяют этому условию:

Поясняющая картинка из статьи на CodeProject:

Полнотекстовый поиск при помощи Oracle Text

Создадим таблицу документов и наполним ее данными:

create table docs (id number not null, text varchar2(1000) not null);
insert into docs values (1, ‘Шла Саша по шоссе и сосала сушку.’);
insert into docs values (2, ‘London is the capital of The United Kingdom of Great Britain and Northern Ireland.’);

Создадим настройки для полнотекстового индекса и выполним его построение:

begin
ctx_ddl.create_preference(‘my_wordlist’, ‘BASIC_WORDLIST’);
ctx_ddl.create_preference(‘my_lexer’, ‘AUTO_LEXER’);
ctx_ddl.set_attribute(‘my_lexer’, ‘INDEX_STEMS’,’YES’);
end;

create index docs_idx on docs (text) indextype is ctxsys.context parameters (‘LEXER my_lexer WORDLIST my_wordlist’);

Тестируем построенный индекс:

select * from docs where contains(text, ‘саша’) > 0;

ID TEXT
1 Шла Саша по шоссе и сосала сушку.

select * from docs where contains(text, ‘$идти’) > 0;

ID TEXT
1 Шла Саша по шоссе и сосала сушку.

select * from docs where contains(text, ‘united’) > 0;

ID TEXT
2 London is the capital of The United Kingdom of Great Britain and Northern Ireland.

Источник

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криптами, которые будут выполняться параллельно.

Запустим группу параллельных процедур.

По завершении посмотрим лог.

Видим, что время выполнения экземпляров тестовой процедуры соответствует ожиданиям.

Протягивание остатков

Опишем вариант решения достаточно типовой банковской задачи по “протягиванию остатков”. Допустим, имеется таблица фактов изменения остатков по счетам. Требуется на каждый день календаря указать актуальный остаток по счёту (последний за день). Такая информация часто бывает нужна в хранилищах данных. Если в какой-то день не было движений по счёту, то нужно повторить последний известный остаток. Если объёмы данных и вычислительные мощности сервера позволяют, то можно решить такую задачу с помощью SQL-запроса, даже не прибегая к PL/SQL. Поможет нам в этом функция last_value(* ignore nulls) over(partition by * order by *), которая протянет последний известный остаток на последующие даты, в которых не было изменений.
Создадим таблицу и заполним её тестовыми данными.

Нижеприведённый запрос решает нашу задачу. Подзапрос ‘cld’ содержит календарь дат, в подзапросе ‘ab’ группируем остатки за каждый день, в подзапросе ‘a’ запоминаем перечень всех счетов и дату начала истории по каждому счёту, в подзапросе ‘pre’ для каждого счёта составляем календарь дней с начала его истории. Финальный запрос присоединяет к календарю дней активности каждого счёта последние остатки на каждый день и протягивает их на дни, в которых не было изменений.

Результат запроса соответствует ожиданиям.

Объединение нескольких историй в одну

При загрузке данных в хранилища часто решается задача, когда нужно выстроить единую историю по сущности, имея отдельные истории атрибутов этой сущности, пришедшие из различных источников. Допустим, имеется некоторая сущность с первичным ключом primary_key_id, о которой известна история (start_dt — end_dt) трёх её различных атрибутов, расположенная в трёх различных таблицах.

Целью является загрузка единой истории изменения трёх атрибутов в одну таблицу.
Ниже приведён запрос, решающий такую задачу. В нём сначала формируется диагональная таблица q1 с данными из разных источников по разным атрибутам (отсутствующие в источнике атрибуты заполняются null-ами). Затем с помощью функции last_value(* ignore nulls) диагональная таблица схлопывается в единую историю, а последние известные значения атрибутов протягиваются вперёд на те даты, в которые изменений по ним не было:

Результат получается такой:

Нормалайзер

Иногда встаёт задача о нормализации данных, пришедших в формате поля с разделителями. Например, в виде такой таблицы:

Такой запрос нормализует данные, расклеив соединённые запятой поля в виде нескольких строк:

Результат получается такой:

Визуализация в формате 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 и др.

Источник