: f

извлечение ~ % * iP l#

трансформация / загрузкаs

s /

перемещение

Рис. 8.4. Извлечение, перемещение, загрузка, трансформация (стандартный метод Oracle)

Вообще-то, самый эффективный способ организации обработки - когда трансформация выполняется до перемещения данных, однако любая попытка увеличить рабочую нагрузку на унаследованную систему обычно встречает сопротивление (по пр№1инам, которые мы рассматривали в начале этой главы). Следовательно, мы должны исходить из того, что после перемещения данные будут находиться практигески в том же состоянии, что и после извлечения. Возможно, нам удастся выполнить символьное преобразование из EBCDIC в ASCII, и, конечно, можно надеяться, что все десятишые значения будут конвертированы в текст, но остальные задачи трансформации лягут на нащи плечи.

Желательно все данные передавать в текстовом формате. Это значительно облегчит жизнь участвующим в этом процессе, и лищь немного усложнит ее мащинам, осуществляющим преобразование данных на передающей стороне. Если использовать числовой формат, то из-за особенностей внутреннего представления дат и чисел в Oracle на принимающей стороне обязательно потребуется выполнять преобразование типов данных.

Примечание

Бывщий гуру Oracle по SQL и вопросам производительности Крис Эллис когда-то уговорил одного консультанта представить все столбцы таблицы регистрации данных как VARCHAR, хотя все значения в таблице были числовыми. Логика его была такой: поскольку весь доступ осуществлялся из ЗСЕ-кода и преобразование типов было неизбежным, его вполне можно было выполнять под управлением этого ЗСЬ-средства. Конечно, в символьной форме данные загружались гораздо быстрее!

Трансформация данных

Основной упор в этом разделе делается на то, чтобы убедить читателя в том, что, вопреки распространенной практике, самый лучший подход - полностью выполнить трансформацию до загрузки данных в Oracle. Если отложить трансформацию на период после загрузки (первоначальной), то мы гарантируем, что большую часть данных придется загружать дважды - один раз неправильно, а второй раз правильно. Производительность операции вставки в Oracle? довольно высока, но лучше выполнить лишь только такое число этих операций, которое необходимо для выполнения поставленной задачи. Стандартный метод Oracle, изображенный на рис. 8.4 (извлечение, перемешение, загрузка, трансформация), особегшо неэффективен, потому что при этом выполняются минимум одна ненужная вставка и одна ненужная выборка для каждой загружаемой записи. На практике же часто проходится выполнять несколько проходов по таблице.

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

ссылочную целостность;

объем данных, передаваемых в транзакции;

размешение данных.

Давайте рассмотрим простой случай.

Вам предстоит загрузить заказы и строки заказов из корпоративной базы данных на мэйнфрейме, в которой допускается максимум 20 строк на заказ. Обслуживающий персонал мэйнфрейма предложил вам текстовый файл, содержащий по одной записи на каждый заказ; за данными заголовка заказа сразу же располагаются строки заказа (максимум двадцать). Файл содержит разделители, позволяющие загрузить данные в таблицу с помощью SQL*Loader, но нужно откорректировать код статуса заказа, преобразовав его в значения, используемые в Oracle-приложении, а также конвертировать строки заказа так, чтобы они содержали цену единицы вместо произведения цены единицы на количество. Как вы поступите?

Наиболее часто встречается такое решение данной задачи. После загрузки текстового файла в рабочую таблицу с помощью SQL*Loader запускается скрипт SQL*Plus, который берет дагшые заголовка заказа из таблицы WORK TABLE и вставляет их в таблицу ORDERS, используя, например, такой SQL-оператор:

INSERT INTO orders ( order no , cust no , order status

SELECT order no , cust no

decode ( order status

FROM work table;

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

INSERT INTO orders ( order no

, 1i ne no

, product code

, quantity

, unit price

SELECT order no , 01

, product code 01 , quantity 01 , round{line price 01 / quantity 01

FROM work table WHRER product code 01 IS NOT NULL;

В итоге мы правильно загрузили данные в таблицы ORDERS и 0R-DER LINES, но:

Провели двадцать одно полное сканирование рабочей таблицы.

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

Сделали так, что почти наверняка строки заказа будут находиться в разных физических блоках базы данных.

Существует и другой способ - вообще не использовать SQL*Loader, а написать ЗСЕ-программу, которая читает текстовый файл и из каждой строки этого файла образует одну строку в таблице ORDERS и от одной до двадцати строк в таблице ORDER LINES. Операции вставки выполняются с помощью массивного интерфейса, и программа выполняет фиксацию, например, через каждые 50 строк, чтобы удерживать размер сегмента отката На приемлемом уровне.