Из Oracle 7 в Oracle 7: особый случай

Существует один метод переноса данных, который мы еще не обсуждали и который в действительности касается случая с распределенными базами данных, рассматриваемого в главе 12. Если мы можем непосредственно, при помощи запроса, извлечь данные, которые хотим принять, то должны учесть несколько иных факторов. Очевидно, что такая ситуация возникает в случае, когда данные уже находятся в таблицах, принадлежащих другому приложению этой же базы данных. Данные также могут находиться в другой базе данных Oracle где-то в сети или в базе данных, доступ к которой возможен через SQL*Net и шлюзовую технологию Oracle или через один из картриджей данных, выпускаемых для архитектуры NCA. С помощью синонимов можно сделать так, что, с точки зрения программиста, все эти варианты (кроме последнего, процедурного) будут одинаковыми на вид. То есть мы можем писать запросы для обращения к объекту PRICEMASTER, будь это:

таблица в локальной схеме базе данных;

синоним таблицы, относящейся к другой схеме этой же физической базы данных, к которой нам предоставлен доступ при помощи запросов;

синоним, в котором используется канал базы данных для обращения к таблице в другой базе данных Oracle;

синоним, в котором используется канал базы данных для обращения к объекту в не-0гас1е-базе данных, доступ к которой осуществляется через прозрачный шлюз.

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

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

INSERT INTO local orders SELECT *

FROM orders@hg WHERE processing office = my location;

DELETE FROM orders@hg

WHERE processing office = my location;

COMMIT;

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

Как и прежде, в данном случае все зависит от того, получаем ли мы данные из SQL-запроса в нужном виде или же понадобится выполнить их пред- или постобработку. Оператор INSERT...SELECT... очень эффективен, поскольку нет необходимости конвертировать данные из внутреннего формата Oracle, а также потому, что (на таких платформах, как Unix, где Oracle использует двухзадачную архитектуру) для переключения из пользовательского процесса в Oracle-процесс и обратно никакое переключение контекста не требуется. Если же необходимы преобразование или проверка данных, то помещение данных в рабочую таблицу и обмен ими может оказаться неприемлемо неэффективным.

Поскольку данные можно получить при помощи SQL-запроса, то можно написать ЗОЕ-программу, которая вместо чтения текстового файла сгенерирует удаленный запрос, выполнит необходимую обработку, а затем вставит данные в локальную базу данных.

Если такая процедура делается часто, а не от случая к случаю, то мы, вероятно, говорим уже о распределенной базе данных, а не о механизме подачи или приема данных. Если вы захотите перейти сразу к главе 12 и узнать подробности, то мы должны предупредить, что распределенные базы данных и архитектуры клиент/сервер имеют общие особенности в методах проектирования, которые описаны в главе 11. Рекомендуем поэтому сначала прочитать главу 11.

Выходные данные

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

Все сказанное в предыдущих разделах можно в равной степени отнести и к выходным данным. Если мы хотим предоставить другой БД Oracle доступ для чтения нащих данных, то можно воспользоваться каналом или снимком базы данных - в зависимости от того, насколько актуальными должны быть передаваемые данные. Однако здесь мы опять попадаем в сферу распределенных баз данных и отсылаем читателя к главе 12.

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

Oracle-утилиту EXPort;

скрипты SQL*Plus;

ЗОЕ-программу;

генератор отчетов.

Выбор будет зависеть от сложности требований. Например, SQL*Plus - хороший вариант для создания простых текстовых файлов с записями фиксированной длины. Если вам нужно взять всю таблицу из одной БД Oracle и просто перенести ее в другую БД, то достаточно будет утилиты EXPort. Вероятно, не стоит использовать для этого сложное полнофункциональное средство генерации отчетов. Кроме того, некоторые генераторы отчетов работают только на клиентской платформе, и вы наверняка не захотите выполнять задачу получения дампа данных по сети. Мы предпочитаем опять-таки ЗСЕ-средство, которое может эффективно работать с массивами и обеспечивает более высокую степень когггроля.

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

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

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

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

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

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