CC BY
60
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Тур чин С. Программный инструментарий менеджера проектов. Компьютерное обозрение, №34, 2000.
2. Тур чин С. Как управля ют проектами. Компьютерное обозрение, №25, 2000.
УДК 004.658
Б.А. Державец
ONLINE - РЕСИНХРОНИЗАЦИЯ ПОСЛЕ СБОЯ ENTERPRISE REPLICATION СЕРВЕРА, ВХОДЯЩЕГО В UPDATE ANYWHERE ENTERPRISE REPLICATION SYSTEM
Задача синхронизации Informix Enterprise Replication серверов в режиме online исторически возникла с появлением Informix Enterprise Replication 7.24. Однако, High Performance Loader не предоставлял режима “Deluxe without replication” в версиях 7.24, 7.30, 7.31, что фактически приводило к необходимости остановки системы для ресинхронизации.
Начиная с версии 9.2 и выше, появление упомянутого режима сделало возможным перенос реальных данных и загрузку этих данных на добавляемом к системе сервере в режиме “Online”.
, , промышленном режиме в проекте, проводившемся Verizon Inc. (GTE до 2001 года), Dallas, TX, USA (1999/2000 гг.).
Краткое описание утилит Informix Dynamic Server^^^^^^^TOBaHHbix для решения описанной задачи:
High Performance Loader ,
, , -пользуется специальный пул в разделяемой памяти OS UNIX. High Performance Loader реализован как бинарный файл “ipload”.
Комманда: $ ipload & приводит к загрузке определенного графического ин-X- .
High Performance Loader “onpload”, -
редь может работать и автономно в среде командного интерпретатора “shell”, используя обьекты “Jobs” (работы), предварительно созданные в среде HPL и загру-c “onpload”.
Например, команда: $ onpload -p name_of_project -j name_of_job -fcl ссылается на проект: name_of_project и работу name_of_job. Эти обьекты должны быть предварительно созданы в среде HPL и сохранены в базе данных “onpload”.Ключи f,c,l управляют загрузкой данных “Deluxe without replication” - это режим, в котором может выполняться утилита “onpload”, загружая данные в таблицы с чрезвычайно высокой скоростью, причем невидимо для процессов, отвечающих за репликации.
Фактически утилита onpload является много-потоковым процессом OS UNIX, эмулирующим стратегию Query Optimizer of Informix Extended Parallel Server (8.X) для версий ,отличных от 8.X Реализация этих утилит в Informix Dynamic Server 9.2 с упомянутой выше опцией “Deluxe without replication” на взгляд
, Verizon Inc.
лета 1999 года была чрезвычайно критична, если учесть, что официальный релиз Informix Dynamic Server 9.2 датирован сентябрем 1999 года.
TimeStamp - , , -
хронизованы все сервера системы. Он используется для разрешения конфликтов,
- .
“cdrtime” каждой реплицируемой таблицы. Сравнение поля “cdrtime” со значением TimeStamp -
нии либо отклонении обновления.
“Enterprise Replications” предоставляют возможность реплицировать изме-
, ,
, .
Enterprise Replication
“Online”.
Допустим,что g_cp ,g_fW ,g_tp ,g_sc Enterprise Replication (ER) серве-, Update Anywhere Enterprise Replication. In-
formix Dynamic Server 9.2UC2 в среде AIX 4.2.
Каждый из серверов имеет по два сетевых адаптера для отделения репли-кационного трафика, т.е. каждый скрипт, вызывающий утилиту “cdr”, экспортирует значение $INFORMIXSERVER, совпадающее с DBSERVER-NAME алиасом, привязанным ко второму сетевому адаптеру . Привязка определяется соответствующей записью в файле $INFORMIXDIR/ etc/sqlhosts, которая может ссылаться IP , UNIX -
ти
В данном случае файл $INFORMIXDIR/etc/sqlhosts на всех серверах имеет
:
g_cp group - - i=1
dbserver_ ucp onsoctcp server_ucp svc1 g=g_cp
dbserver_ cp onsoctcp server_cp svc1 g=g_cp
g_fw group - - i=2
dbserver_ufw onsoctcp server_ufw svc2 g=g_fw
dbserver_fw onsoctcp server_fw svc2 g=g fw
g_sc group - - i=3
dbserver_ usc onsoctcp server_usc svc3 g=g_sc
dbserver_ sc onsoctcp server_sc svc3 g=g_sc
g_tp group - - i=4
dbserver_utp onsoctcp server_utp svc4 g=g_tp
dbserver_tp onsoctcp server_tp svc4 g=g_tp
Соответствующие вхождения в SONCONFIG файл на хосте server_cp: DBSERVERNAME dbserver_cp DBSERVERALIASES dbserver_ucp
Экспортируемое значение $INFORMIXSERVER должно быть dbserver_cp. , , , “cdrserver”, -
даваемая в любой из реплицируемых таблиц, содержит нужное значение DBSERVERNAME.
, ER g_cp ( ,
Informix Dynamic Server server_cp online, -
). ER g_cp ,
утилиту “cdr”:
15Q
informix@server_cp$ cdr delete server g_cp informix@server_tp$ cdr delete server g_cp -connect server_tp
ER
, .
Допустим UNIX хост server_cp восстановлен и готов к синхронизации. Определим g_cp как Enterprise Replication сервер в системе синхронизуем его с g_tp (ключи -I -S):
informix@server_cp$ cdr def server -connect server_cp -I -S g_tp g_cp \
-A $INFORMIXDIR/ats -R $INFORMIXDIR/ris -s SendDbspace \
-r RecieveDbspace
-A определяет Aborted Transaction Spooling Directory;
-R определяет Row Information Spooling Directory.
Определим репликации на g_cp, выполнив в цикле по всем требуемым таб:
cdr change replicate -a repl_${TABLE} \
“sitesdata@server_cp:informix.${TABLE}” select * from ${TABLE}" Enterprise Replication “ ”
( suspended):
informix@server_cp$ cdr suspend server g_cp g_tp g_fw g_sc
g_cp, -
:
cdr start replication repl_${TABLE} g_cp
С этого момента транзакции на всех серверах помещаются в очереди, но не реплицируются.
Выгрузим данные на UNIX сервере server_tp (g_tp) , выполнив в том же
:
onpload -p sites -j unload_${TABLE} -fu
g_cp
же цикле по всем требуемым таблицам:
onpload -p sites -j load_${TABLE} -fcl
, (“jobs”),
“Deluxe without replication”
“onpload” .
Enterprise Replication , -
туе “suspended” c помощью команды “resume”:
informix@server_tp$ cdr resume server g_cp g_tp g_fw g_sc С этого момента система может войти в режим с чрезвычайно высокой ак, Update Anywhere
Enterprise Replication. ,
т.е. SendDbspace и ReceiveDbspace, на приостановленных (suspended) серверах дожны быть достаточно велики, чтобы аккомодировать эту активность.
Общая длина журналов протоколирования транзакций тоже должна быть достаточно большой из-за риска отката длинных транзакций.
Для Enterprise Replication сервера LTXHWM > 2* LTHWM, т.е. транзакция всегда должна быть откачена до достижения Long Transaction Exclusive High Water Mark.
“DDR threads” “catch up
phase” .
нормальное.
Выводы. Informix Enterprise Replication версии 9.2 и выше могут рассматриваться как устойчивое к сбоям решение, приемлемое для промышленной эксплуатации.
Надежная схема для восстановления после сбоя является чрезвычайно важной компонентой для промышленной системы. Время необходимое для восстановления, как правило, означает недоступность системы для пользователей, что практически и происходило вплоть до версии Informix Dynamic Server 7.31.
Версии 9.2, 9.3, 9.4 позволяют осуществить синхронизацию в режиме “Online”. , ,
правило, оправдан при достаточно высокой квалификации персонала, сопровож-, , роста баз данных и (или) изменении интенсивности потока транзакций.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Guide to Informix Enterprise Replication Version 9.2 (G251-0336-00).
2. Guide to High Performance Loader Version 9.2 (G251-0337-00). http://www-306.ibm.com/software/data/informix/pubs/library/ids_92.html.
УДК 658.012.011
AX. Свиридов
МЕТОД ПОСТРОЕНИЯ МАТЕМАТИЧЕСКОЙ МОДЕЛИ ИНФОРМАЦИОННЫХ ПОТОКОВ ПРЕДПРИЯТИЯ
Одним из важнейших моментов при проектировании автоматизированных информационных систем (АИС) является рассмотрение информационных потоков, циркулирующих а предприятии. Эти потоки являются отражением любой хозяйственно-производственной деятельности и имеют центральное значение. Для проведения анализа потоков возникает задача создания математической модели информационных потоков, циркулирующих на предприятии [1].
Целью построения модели является проведение анализа существующего положения на объекте автоматизации. В таком случае информационная модель может служить основой для проведения различных исследований:
- количественного анализа документооборота и организационной структу-, -
зацию потоков информации, а также на основе количественных характеристик документооборота возможно проведение обоснованного расчета характеристик информационной сети предприятия;
- построения визуальной инфор мационной модели предприятия, например, построенные с помощью инструментальных CASE-средств.
