Развитие программного обеспечения - Доставка данных на интеграционный сервер

Новости it-компаний

Предлагаем ознакомиться

Dell представил ЖК-монитор будущего

News image

Компания Dell представила прототип ЖК-монитора будущего. В устройстве использована инновационная технология DisplayPort, благодаря чему толщину ус...

Авторизация



Развитие технологий:

Процессор Pentium Pro

Шестое поколение процессоров х8б начало свой отсчет от процессора Pentium Pro и нашло свое развитие в Pentium II и III. Пр...

История организации IBM

История компании восходит к концу 19 века, когда немецкий эмигрант Герман Холлерит, работавший в Бюро переписи населения, предложил автоматизировать статистический уч...



Доставка данных на интеграционный сервер
История - Развитие программного обеспечения

После того, как мы установили и наладили шлюзы к DB2/400 и MS SQL Server, необходимо заняться собственно передачей данных. Существует несколько вариантов решения.

Можно создать на интеграционном сервере временную таблицу, выбрав в нее все данные из исходной (в рамках одного оператора SQL), например:

Листинг 8

CREATE TABLE oracle_table AS

SELECT * FROM db2_table.db2_database@dblink

Для заполнения временной таблицы можно использовать оператор INSERT:

Листинг 9

INSERT INTO oracle_table

SELECT * FROM db2_table.db2_database@dblink

Однако мы хотели бы обеспечить периодическую подкачку данных на интеграционный сервер из целевой системы. Наиболее очевидным подходом является использование одного из простейших механизмов репликации Oracle механизма моментальных копий или снимков (snapshot). Ниже мы будем говорить только о необновляемых снимках.

Следуя определению Oracle, снимок представляет собой предназначенную только для чтения копию главной таблицы (master table), расположенную на удаленном узле. К снимку можно обращаться с запросами на выборку, но нельзя его обновлять: обновляется главная таблица, а затем изменения автоматически переносятся на снимок.

Рассмотрим пример, где:

cusomers - имя снимка; clients - имя главной таблицы; accounts - имя исходной базы данных; remotedb - ссылка к исходной базе данных.

Листинг 10

CREATE SNAPSHOT customers

PCTREE 5

PCTUSET 60

TABLESPACE users

STORAGE (INITIAL 50K NEXT 50K)

REFRESH COMPLETE NEXT SYSDATE+1

AS

SELECT * FROM client.account@remotedb

Данный оператор создает снимок с таблицы удаленной базы данных. REFRESH специфицирует режим обновления (refresh) снимка. Значение COMPLETE необходимо задавать, когда предполагается полное обновление снимка, то есть данные из исходной таблицы целиком переносятся в снимок. Значение FAST соответствует так называемому быстрому обновлению, когда в снимок помещаются не целиком все данные из исходной таблицы, а только изменения, имевшие место с момента последнего обновления. Возможен также режим FORCE, когда Oracle определяет по ситуации, возможно ли применить режим быстрого обновления и, если да, использует его; в противном случае действует режим COMPLETE.

Здесь речь идет об автоматическом обновлении снимка, в отличии от обновления (update), выполняемого приложением над таблицами. Как было сказано выше, эту операцию над необновляемыми снимками выполнять нельзя.

NEXT задает интервал между автоматическими обновлениями. Значение SYSDATE+1 соответствует обновлению с интервалом времени в сутки. Первое обновление производится в момент создания снимка.

Смысл созданного снимка таков. На интеграционном сервере в базе данных Oracle под именем customers создан образ таблицы clients в удаленной базе данных accounts. В момент создания в него помещены все данные из таблицы clients. После этого OLTP-система, работающая с базой данных DB2/400, может вносить в таблицу clients любые изменения. Пройдут сутки, и сервер Oracle скопирует через шлюз TGDB2400 целиком всю таблицу clients в customers и будет повторять эту процедуру и далее с интервалом в сутки. Разумеется, интервал времени между копированиями может быть установлен так, как это необходимо, непосредственно при создании снимка либо используя оператор ALTER SNAPSHOT.

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

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

Казалось бы, Oracle позволяет создать моментальный снимок с передачей только изменений (режим FAST REFRESH). Однако не все так просто. Дело в том, что этот режим можно использовать только в том случае, когда в целевой системе определен и используется некоторый механизм накопления изменений в главной таблице и их отображения в снимке.

Предположим первоначально, что исходная БД это база данных Oracle. Тогда все выглядит просто. В целевой системе создается (оператором CREATE SNAPESHOT LOG) журнал снимков (snapshot log). Это таблица, ассоциированная с главной таблицей. Сервер Oracle (в составе целевой системы) сохраняет изменения, выполненные в главной таблице, в журнале снимков, и затем использует его для обновления снимков, ассоциированных с данной главной таблицей. То есть ответственность за накопление и передачу изменений берет на себя сервер Oracle. К сожалению, в данном пилотном проекте этот подход использовать мы не могли, так как целевая система представляла собой DB2/400.

Репликация данных из других систем

Однако и в этой ситуации было найдено решение. Выше мы уже говорили, что семейство Oracle Open Gateways включает группу продуктов Replication Service. Продукт Oracle Replication Service for Data Propogator (ORSDP) позволяет решить поставленную задачу, то есть реплицировать только изменения в исходных таблицах целевой системы (DB2/MVS и DB2/400), но не все содержимое таблиц целиком.

Конфигурация включает следующие компоненты:

Какие действия необходимо предпринять, чтобы изменения, выполненные над таблицами DB2/400, отразить на таблицы Oracle? Во-первых, необходимо захватывать изменения в таблицах DB2 и где-то их накапливать. Во-вторых, необходимо накопленные изменения периодически применять к таблицам Oracle.

Первое выполняет продукт IBM DataPropogator Relational Capture (DPROP). Конкретно, DPROP сканирует журналы DB2 и помещает захваченные изменения в таблицы DB2/400. Вполне естественно, что эту часть работы осуществляет продукт IBM, понимающий формат журналов DB2/400.

Второе ложится на плечи Oracle Replication Services. Продукт поставляется для ОС Windows NT и Windows95 и устанавливается на отдельную рабочую станцию, которая берет на себя функции консоли для администрирования процесса репликации. Сам процесс переноса изменений в таблицы Oracle выполняется средствами PL/SQL (язык для разработки хранимых процедур Oracle), функционирующими на интеграционном сервере. Они извлекают (pull) изменения из таблиц DB2/400 и применяют их к результирующим таблицам Oracle. Oracle Replication Service также включает утилиты для администрирования окружения DPROP. Отметим, что с помощью Oracle Replication Services for DataPropogator можно реплицировать данные и в обратном направлении, то есть из Oracle в DB2.

Очевидно, почему Oracle Replication Services был разработан в первую очередь для СУБД DB2. Она очень распространена на мэйнфремах, а для AS/400 DB2 это вообще стандарт (собственно, для AS/400 других баз данных, кроме DB2/400, нет). Видимо, в дальнейшем технология Oracle Replication Service будет распространена на другие системы.

Transparent Gateway for Microsoft SQL Server

В отличие от TGDB2400, который может быть установлен только в стационарной конфигурации, прозрачный шлюз к Microsoft SQL Server может работать и как стационарный, и как удаленный.Однако предпочтение все-таки стоит отдать стационарному варианту конфигурации. Причина была указана выше целесообразно унифицировать сетевой протокол прикладного уровня, выбрав SQL*Net, что достигается в стационарном варианте и было использовано в пилотном проекте

Для организации доступа к Microsoft SQL Server и доставки данных на интеграционный сервер используются описанные выше механизмы (ссылки к базам данных и снимки). Однако в случае Microsoft SQL Server можно использовать только полную репликацию главной таблицы в снимок (режим COMPLETE REFRESH). Мы не можем накапливать изменения в исходных таблицах и передавать их в результирующие, так как для Microsoft SQL Server пока не существует продуктов, аналогичных ORSDP.

Transparent Gateway for ODBC

Допустим, что мы хотели бы разместить компонент унификации доступа на стороне сервера. Кроме того, мы хотели бы использовать для организации доступа к различным БД обобщенный (ODBC) API. В случае ODBC на сервере устанавливаются все компоненты ODBC, описанные выше (кроме, разумеется, приложения), а также Oracle Server и компонент доступа к БД (например, Oracle Transparent Gateway for ODBC TGODBC), транслирующий запросы приложения к базе данных (на Oracle SQL) в запросы на SQL ODBC и направляющий их целевой базе данных. Очевидно, что здесь мы имеем дело с удаленной конфигурацией. Отметим, что пока TGODBC доступен только для Windows NT.

 


Читайте:


Добавить комментарий


Защитный код
Обновить

Дэвид Паккард, один из основателей компании Hewlett-Packard

News image

За свою легендарную полувековую карьеру Дэвид Паккард оказал огромное влияние на развитие современной электронной индустрии и методов управления. Сегодня Hewlett-Packard - ...

Стив Джобс признан лучшим гендиректором

News image

В десятку наиболее эффективных топ-менеджеров попали также главы Газпрома , Samsung, Cisco, Amazon и других Руководитель компании Apple Стив Джобс пр...

Жесткие диски для ноутбуков становятся тоньше

News image

На данный момент жесткие диски для ноутбуков могут быть толщиной 9,5 мм и 12,5 мм. Первые получили наибольшее распространение, а об...

MacBU подытоживает две тысячи девятый год

News image

Как прошел 2009 год в компании, которую традиционно принято считать вторым крупнейшим разработчиков ПО для платформы Apple Macintosh? В Microsoft Ma...

Financial Times обещает iTablet уже в следующем месяце

News image

Конец декабря редакция Financial Times решила скрасить очередной порцией слухов о планшетнике Apple. По данным издания, это устройство, покорившее заголовки СМ...

Внедрение 6-ядерных процессоров Intel Xeon может потребовать

News image

Изданию Fudzilla стали известны подробности по первому 6-ядерному процессору Intel Xeon. Он получит обозначение Core i7 980X, а его несущая тактовая ча...

VESA официально утвердила стандарт mini DisplayPort

News image

Презентованный Apple осенью 2008-го новый видеоинтерфейс mini DisplayPort (сокращенно mDP) вызвал неоднозначную реакцию, отголоски которой оставались различимыми вплоть до вчерашнего дн...

Планшетный Мак покажут 26 января?

News image

За несколько дней до начала нового 2010 года онлайн-пресса разразилась новым потоком слухов на тему планшетного компьютера Apple: сначала хорошо ос...