Технология Excel для ODI.

Перевод статьи Excel technology in Oracle Data Integrator. В переводе использованы скриншоты из оригинальной заметки.

---

Работа с данными Excel в ODI нелегка, плюс именованные диапазоны данных (named ranges) должны быть созданы в файле Excel. Это происходит по причине того, что существующая технология ODI работает на основе преобразования именованных диапазонов в таблицы.

Мы можем изменить стандартную конфигурацию чтобы работать с данными Excel так же легко, как это происходит с данными других технологий.

Конфигурационные изменения, которые я имею ввиду, были опробованы в ODI 10.3 и java 1.4. Сделать необходимо следующее.

Конфигурация ODI.

Загружаем данные.

При загрузке данных в ХД, как и, например, при загрузке данных от множества датчиков в реляционную СУБД, применяются похожие механизмы - отключение констрейнтов и индексов, кеширование последовательностей, хинт /*+ append */, отключение логгирования таблиц и настройки использования места в блоках данных. Подробнее на примере Oracle DB заметка и комментарии на хабре - http://habrahabr.ru/post/196828/.

Выбрать все джоины и фильтры для интерфейса 11g.

Приветствую.

Когда-то давно я написал скрипт, который должен был помочь найти в репозитории Oracle Data Intergator-а все тексты для соединений таблиц источников в интерфейсе. Этот скрипт мне пригодился не раз, но всегда речь шла о работе со структурой репозитория 10й версии. В ODI 11g структура несколько изменилась, в частности, добавилась возмножность работы с множествами, поэтому мой старый скрипт никаких результатов не возвращал.

Скажу даже больше, новая структура репозитория совсем не содержит информации в двух самых примечательных (ранее) таблицах: SNP_TXT и SNP_EXP_TXT. Они теперь пусты, по крайней мере, на моем текущем проекте в них нет ни одной записи.

Философия оптимизации - Хинты.

Перевод.
Оригинал находится по ссылке.

---

Одна из частей моей работы здесь в Rittman Mead состоит в чтобы следить за производительностью ХД, как с точки зрения запросов, сформированных пользователями, так и с точки зрения ETL процессов, загружающих данные в хранилище данных. Иногда я изучаю ситуацию в уже существующей системе, иногда же моя работа является частью процесса разработки нового комплекса.

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

История о двух мастер репозиториях использующих один рабочий репозиторий и несколько слов об Ordered и Not-ordered соединениях в ODI, иллюстрированных скриншотами и несколькими кусками сложного для разбора SQL кода, приведенного для демонстрации и более глубокого понимания читателями описываемой проблемы и ее успешного завершения.

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

Итак, представьте себе, что на одном из проектов получилось так, что часть ETL разрабатывалась другой командой, и, по несчастливой случайности, оказалось, что настройки технологии Oracle у этих двух команд отличались.

Новый стандарт SQL ISO 2011.

Всем привет.

По сообщению Craig Baumunk 15 декабря 2011 года пять частей нового стандарта ISO SQL 2011 было опубликовано на сайте магазина ISO. Так что теперь каждый, у кого есть много денег, может сразу зайти и купить себе стандарт. Вот ссылка.

Craig организовал специальную группу в ЛинкедИн для обсуждения новых возможностей, определяемых этим стандартом для работы с периодизацией данных.

Переполнение главной таблицы SNP_EXP_TXT.

Привет всем.

Как известно, таблица SNP_EXP_TXT содержит текстовые части команд ODI.
В старых версиях, с 10.1.3.2.0 по 10.1.3.5.1 для ключевой колонки I_TXT из этой таблицы выделялось недостаточно места, таким образом, с течением времени могла возникнуть ситуация, когда свободные номера в колонке заканчивались, и она начинала выделять значения с 0, что приводило к ошибке ORA-00001: unique constraint (SDS1.PK_EXP_TXT) violated.

Сравнение особенностей SQL (Teradata vs Oracle).

Привет всем.

Я долгое время работал над построеннием Хранилища Данных в СУБД Терадата, поэтому привык к хорошему ;-)

А вот по ссылке ниже Boris Knizhnik потрудился и свел, хоть и не до конца, различия между языками SQL запросов в Терадате и Оракле. Очень занимательная заметка.

Показываем в Операторе результат SQL запроса или содержимое файла.

На днях понадобилось мне прочитать содержимое файла, который лежит на том же сервере, где работает агент ODI. Но доступа к этому серверу, например, через ftp, у меня не было.
Но есть Oracle Data Integrator, который мне в этом и помог.

Итак, базируясь на вот этой заметке об отображении результата запроса в Операторе, приступим.

Вводная часть

Удаление потерянных данных в SNP_EXP_TXT.

Приветствую.

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

---

Привет народ. Есть небольшой "баг" в ODI, который заключается в том, что не очищается таблица SNP_EXP_TXT, когда удаляется "родительская" запись.

Так происходит потому, что в модели репозитория нет внешнего ключа между SNP_EXP_TXT и ее несколькими родительскими таблицами, именно потому, что таких таблиц несколько.

Поиск одинаковых JOIN-ов в ODI.

Иногда бывает нужно найти среди множества интерфейсов определенные соединения (join-ы). Например, при тестировании одного интерфейса обнаружилась ошибка при соединении таблицы фактов с одной из таблиц размерностей. В среде разработки таблица измерений имела только одну строку, подпадающую под условие соединения, а в тестовом окружении строк оказалось больше.

В этом случае, чтобы внести исправления во все интерфейсы, которые используют эту таблицу измерений достаточно пойти в модель, найти нужную нам таблицу, и посмотреть, в каких интерфейсах она используется как источник:

Узнаем свойства переменной через таблицу SNP_VAR.

Небольшой полезный SQL запрос, который поможет получить некоторые важные свойства переменных прямо из таблицы репозитория ODI под названием SNP_VAR. Подсмотрено вот здесь. По сравнению с оригиналом добавлена важная характеристика переменной, обозначаемая в интерфейсе как Action.

SELECT DISTINCT
CASE
WHEN SNP_VAR.I_PROJECT IS NULL
THEN 'GLOBAL'
ELSE SNP_PROJECT.PROJECT_NAME
END AS PROJECT_NAME,
SNP_VAR.VAR_NAME AS VARIABLE_NAME,
CASE
WHEN SNP_VAR.VAR_DATATYPE='A' THEN 'ALPHANUMERIC'
WHEN SNP_VAR.VAR_DATATYPE='N' THEN 'NUMERIC'
WHEN SNP_VAR.VAR_DATATYPE='D' THEN 'DATE'
ELSE 'TEXT' END AS DATATYPE,
CASE
WHEN SNP_VAR.IND_STORE = 'S' THEN 'Non persistent'
WHEN SNP_VAR.IND_STORE = 'H' THEN 'Historize'
WHEN SNP_VAR.IND_STORE = 'L' THEN 'Last value'
ELSE '?' END AS ACTION,
CASE WHEN SNP_VAR.VAR_DATATYPE='T' THEN V_TXT.TXT
ELSE SNP_VAR.DEF_v END AS DEFAULT_VALUE,
SNP_VAR.lschema_name AS VARIABLE_QUERY_SCHEMA,
SNP_TXT.TXT AS VARIABLE_QUERY,
S_TXT.TXT AS DESCRIPTION
FROM SNP_VAR
LEFT OUTER JOIN SNP_PROJECT ON SNP_VAR.I_PROJECT=SNP_PROJECT.I_PROJECT
LEFT OUTER JOIN SNP_TXT ON SNP_TXT.I_TXT=SNP_VAR.I_TXT_VAR_IN
LEFT OUTER JOIN SNP_TXT S_TXT ON S_TXT.I_TXT=SNP_VAR.I_TXT_VAR
LEFT OUTER JOIN SNP_TXT V_TXT ON V_TXT.I_TXT=SNP_VAR.i_txt_var_val_txt
ORDER BY project_name

Ну и еще один запрос, показывающий значения исторических переменных. Хотя, до конца, я в нем пока не уверен.

SELECT
d.Var_Name AS "NAME",
d.FIRST_DATE AS "DATE",
CONTEXT_CODE AS "CONTEXT",
CASE
WHEN v.VAR_DATATYPE='A' THEN d.VAR_V
WHEN v.VAR_DATATYPE='N' THEN to_char(d.VAR_N)
WHEN v.VAR_DATATYPE='D' THEN to_char(d.VAR_D)
ELSE 'RUN: select TXT from snp_exp_txt where I_TXT = ' || to_char(d.i_txt_var_t) END AS "VALUE"
FROM snp_var v LEFT OUTER JOIN snp_project p ON v.I_PROJECT=p.I_PROJECT,
SNP_VAR_DATA d
WHERE d.var_name = UPPER(nvl(p.PROJECT_NAME, 'GLOBAL')) || '.' || v.Var_Name

См. также: структура таблиц рабочего репозитория ODI.