CC BY
51
диагностического заключения применительно к описанному классу ЭС ПФД, создаваемых в рамках АТ, в том числе для определения направлений дальнейшего развития этой технологии.
Литература
1. Приобретение знаний; [пер. с япон.; под ред. С. Осуги, Ю. Саэки]. М.: Мир, 1990. 304 с.
2. Асаи К., Ватада Д., Иваи С. Прикладные нечеткие системы; [пер. с япон.; под ред. Т. Тэрано, К. Асаи, М. Сугэно]. М.: Мир, 1993. 368 с.
3. Таунсенд К., Фохт Д. Проектирование и программная реализация экспертных систем на персональных ЭВМ; [пер. с англ.]. М.: Финансы и статистика, 1990. 320 с.
4. Найденова К.А., Ермаков А.Е. Технология автоматизированной разработки адаптивных компьютерных систем психологической и физиологической диагностики // Автоматизация проектирования дискретных систем: матер. 3-й Междунар. конф. Минск, 1999. Т. 3. С. 72-79.
5. Модель знаний для автоматизированного проектирования экспертных психодиагностических систем / К.А. Найденова [и др.] / Искусственный интеллект-96: сб. науч. тр. 5-й На-цион. конф. с междунар. участ. Казань, 1996. Т. 2. С. 275-279.
УДК 004.658.6:042
ВРЕМЕННОЙ АНАЛИЗ ОБРАБОТКИ КОНФЛИКТНЫХ ТРАНЗАКЦИЙ В ORACLE ENTERPRISE MANAGER И ERRMANAGER
Е.В. Базилевский
(Сургутский государственный университет Ханты-Мансийского автономного округа - Югры,
chester91 7@yandex.ru)
Временные оценки обработки конфликтных транзакций в Oracle Enterprise Manager и разработанном приложении EnManager показали, что последнее позволяет существенно повысить эффективность разрешения конфликтов репликации и сократить затраты не только на обслуживание промышленной БД, но и на решение проблем, возникающих из-за простоев и отказов информационных систем предприятия.
Ключевые слова: БД, репликация данных, конфликты репликации, Oracle.
Одним из лидеров в разработке корпоративных СУБД является компания «Oracle», предоставляющая наиболее гибкое и законченное решение для создания распределенных БД, обеспечивающих различные механизмы репликации данных между узлами, включая множественные обновления [1]. СУБД Oracle также включает механизмы обнаружения и устранения конфликтов репликации. Однако для управления процессом репликации и разрешения конфликтных транзакций администратору предлагается продукт Oracle Enterprise Manager (OEM), который не позволяет использовать все возможности СУБД Oracle, а принципы его реализации делают работу неэффективной и неустойчивой, что приводит к нарушению производственного процесса и дополнительным затратам из-за длительной блокировки объектов БД [2].
Недостатки OEM обусловили необходимость поиска альтернативных средств для разрешения конфликтов репликации и разработки автором специального программного продукта ErrManager [3]. Актуальной задачей является оценка адекватности полученного решения и его эффективности по сравнению с OEM посредством выполнения тестовых заданий для обоих программных продуктов.
Для определения временных затрат обработки конфликтных транзакций в Oracle Enterprise Manager и ErrManager проведен временной анализ
обработки конфликтов по каждому продукту в отдельности. На двух узлах распределенной БД, между которыми настроено реплицирование данных, одновременно сформировано 20 транзакций по 20 вызовов в каждой. Все 20 транзакций содержат по одному конфликтному вызову. Операции произведены над объектом БД «таблица», имеющим 7 полей. В результате на каждом узле вся группа транзакций попадет в очередь конфликтных транзакций, нарушив таким образом бесперебойное реплицирование данных между узлами.
Приведем системные и программные требования к рабочим местам пользователей обеих систем, а также технические характеристики серверов, на которых расположены узлы БД, участвовавших в эксперименте.
Минимальные требования к рабочему месту администраторов OEM и ErrManager:
- ОС Microsoft Windows 2000/XP;
- клиентское приложение: СУБД Oracle 9i для OEM, Oracle 8 для ErrManager;
- Internet Explorer 6.0;
- процессор Intel Pentium III, 800 МГц;
- оперативная память 512 Мб;
- сетевой адаптер Ethernet, 100 Мбит/сек.;
- накопитель на жестком диске с доступной емкостью: 1 Гб для OEM, 800 Мб для ErrManager;
- дисплей с разрешением 1024x768 точек (цветной);
- наличие локальной сети и доступа к серверу с БД.
Кроме того, для ErrManager требуется Oracle OLEDB Provider версии установленного клиентского приложения СУБД Oracle.
Технические характеристики узлов 1 и 2 распределенной БД (на момент тестирования):
- процессор Intel Xeon 3.00 GHz;
- оперативная память 4.00 Gb;
- ОС Microsoft Windows Server 2003 R2 Standard Edition Service Pack 2;
- версия СУБД и БД Oracle - 10.2.0.3.
Рабочее место администратора БД (на момент
тестирования):
- процессор Intel Xeon 1.70 GHz;
- оперативная память 4.00 Gb;
- сетевой адаптер Ethernet, 100 Мбит/сек.;
- доступный объем дисковой памяти более 100 Гб;
- дисплей с разрешением 1024x768 точек (цветной);
- ОС Microsoft Windows XP Professional 2002 Service Pack 2;
- Internet Explorer 8.0;
- наличие локальной сети и доступа к серверу с БД;
- наличие Oracle OLEDB Provider версии установленного клиентского приложения СУБД Oracle;
- версия клиентского приложения Oracle -10.2.0.3.
Временные затраты на обработку конфликтных транзакций в Oracle Enterprise Manager оценивались посредством анализа trace-файлов БД, в которых фиксируется время выполнения всех транзакций и составляющих их запросов, в том числе вызовов функций системных пакетов. Это позволило оценить временные затраты на выполнение каждого действия в алгоритме разбора конфликтных транзакций, реализованного в OEM (рис. 1).
Таким образом, для разбора одного вызова необходимо затратить 16 сек., одной конфликтной транзакции - 320 сек. (5,33 мин.), 20 конфликтных транзакций - 6 400 сек. (1,78 час.).
После получения отчета о конфликтных транзакциях средствами OEM требуется выполнить синхронизацию данных между узлами распределенной БД иными средствами. Для этого необходимо последовательно
- загрузить ПО, позволяющее выполнить в течение 10 сек. sql-скрипты по синхронизации данных между узлами распределенной БД (к примеру, PL\SQL Developer);
- выполнить соединение с необходимой БД -5 сек.;
- сформировать и выполнить sql-скрипты по синхронизации данных - 5 мин.
В итоге на синхронизацию данных между различными узлами распределенной БД в данной си-
туации необходимо затратить 1 ч. 52 мин. После этого в OEM следует выполнить конфликтные транзакции повторно, что занимает 10 мин.
Проведенные испытания показали, что на разрешение 20 конфликтных транзакций, содержащих по 20 вызовов каждая, один из которых в каждой транзакции конфликтный, и синхронизацию данных между различными узлами распределенной БД необходимо затратить 2 ч. 2 мин. 30 сек.
Наиболее критичными факторами с точки зрения производительности являются следующие:
- время обработки действий администратора в OEM, формирования соответствующих SQL-запросов к интересующей БД, преобразования полученного результата из БД, а также предоставления обработанных данных непосредственно администратору определяется не только быстродействием платформы, но и эффективностью интерпретации байт-кода;
- в силу большого объема данных, полученных из БД, и ограниченности ресурсов рабочего места администратора их оперативная обработка в OEM посредством JVM и отображение результата в OEM иногда оказываются невозможными (приложение зависает). По причине постоянного роста промышленных БД подобные ситуации довольно часты, но крайне нежелательны, особенно при разборе конфликтных транзакций и синхронизации данных между различными узлами распределенной БД;
- получение старых, текущих и новых значений изменяемых объектов БД при разборе вызовов в конфликтных транзакциях происходит посредством выполнения соответствующих функций и процедур из системных dbms-пакетов:
dbms_defer_query. get_arg_form;
dbms_defer_query. get_datatype_arg;
dbms_defer_query.get_arg_type.
При большом количестве конфликтных транзакций с большим количеством вызовов в каждой из них серверу БД требуется больше времени на обработку данных, что не позволяет оперативно получить информацию, необходимую для анализа и принятия решения по разрешению конфликтных транзакций, тем самым синхронизировать данные между различными узлами распределенной БД.
Описанные выше проблемы, свойственные OEM, устраняются при использовании утилиты ErrManager, разработанной автором в среде Embarcadero Delphi. ErrManager получает необходимые данные из БД путем SQL-запросов. Время получения данных ограничено только загруженностью БД и связью между клиентской машиной и сервером БД, а разбор конфликтной транзакции осуществляется на стороне клиента с существенно меньшим, в отличие от OEM, использованием ресурсов сервера БД.
Временные затраты обработки конфликтных транзакций в ErrManager оценивались путем
С
Начало +
3
Поиск конфликтной транзакции в таблице system.def$_aqerror (1,5 сек.)
Разбор каждого вызова
(от 1 от 20) в транзакции + -
Определение типов аргументов вызова, набора символов для аргументов вызова, значения аргументов в вызове (1,5 сек. для 1 арг.)
Вызовы функций dbms_defer_query: get_arg_type() get_arg_form() get_datatype_arg()
RAISE NO_DATA_FOUND Вывод «-Binary Value-
j к
Вывод значения, существующего в БД до изменения пользователем (0,5 сек.)
*
Поиск измененного значения
^^ Значение
найдено
Разбор каждого аргумента в вызове (от 1 до 7)
Определение типа аргумента объекта и набора символов для аргумента объекта, значения аргумента объекта в вызове (1,5 сек. для 1 арг.)
Вызовы функций dbms_defer_query: get_arg_type() get_arg_form() get_datatype_arg()
RAISE NO_DATA_FOUND Вывод «-Binary Value-»
Вывод значения, существующего в БД до изменения пользователем (0,5 сек.)
Рис. 1. Блок-схема разбора вызовов в OEM с временной оценкой
включения в программный код приложения вызовов, фиксирующих текущее системное время, и выполнения на основе полученных временных меток расчетов, характеризующих время, затраченное на отдельные операции (рис. 2).
Таким образом, разбор одного вызова занимает 0,025 сек., одной конфликтной транзакции -0,5 сек. и, наконец, 20 конфликтных транзакций -10 сек. При разрешении конфликтных транзакций средствами ПО ErrManager нет необходимости использовать иные продукты для синхронизации данных между различными узлами распределенной БД. При разборе конфликтных транзакций синхронизация может быть выполнена либо авто-
матически, либо вручную, путем генерирования программными средствами ПО ErrManager sql-скрипта и дальнейшего его выполнения. Автоматическая синхронизация данных занимает порядка 2 сек. При ручной синхронизации данных посредством генерации и выполнения sql-скриптов это время увеличивается до 10 сек. Временные оценки приведены для случая синхронизации данных по всем 20 конфликтным транзакциям.
В итоге при использовании приложения Егг-Manager на разрешение 20 конфликтных транзакций, содержащих по 20 вызовов каждая, один из которых в каждой транзакции конфликтный, и синхронизацию данных между различными уз-
Рис. 2. Блок-схема разбора вызовов в ErrManager с временной оценкой
лами распределенной БД необходимо затратить 12 сек. при автоматической синхронизации и 20 сек. при ручной.
Функции, реализованные в утилите ЕггМапа-ger, позволяют:
- получать информацию о конфликтной транзакции и отображать информацию о состоянии данных в БД-источнике перед внесением изменения, данные, измененные пользователем, и текущие данные на БД-приемнике;
- преобразовывать изменения в SQL-запрос для повтора этих действий на приемнике;
- приводить запись на приемнике к такому же виду, в каком она была в источнике до внесения изменений, что позволяет разрешить конфликт путем простого повтора выполнения ошибочной транзакции;
- повторять выполнение конфликтных транзакций и удалять их группами;
- автоматически разрешать конфликтные транзакции указанным способом (из числа приведенных выше) и очищать очередь транзакций после выполненных действий;
- отфильтровывать очередь конфликтных транзакций с разных БД при отображении в рабочей области программы;
- автоматически выявлять конфликтный вызов в транзакции;
- отключать репликацию на другие узлы распределенной БД при синхронизации данных;
- автоматически преобразовывать SQL-запросы на вставку в запросы на изменение при уже существующей записи в БД-приемнике;
- автоматически получать SQL-скрипт разрешения конфликтной транзакции и выполнять его на БД-приемнике;
- формировать отчет в форме HTML по указанным конфликтным транзакциям как в форме OEM, так и в собственной форме;
- вести мониторинг наличия конфликтных транзакций на указанном узле распределенной БД.
В промышленных распределенных БД, как правило, количество конфликтных транзакций значительно выше. Иногда возникают транзакции с 1 000 и более вызовов, каждая из которых содержит не по одному конфликтному вызову. Такие транзакции также требуют оперативного разрешения и не терпят задержек, обусловленных применяемым ПО. Использование разработанного приложения ErrManager позволяет существенно повысить эффективность разрешения конфликтов репликации и сократить не только затраты на обслуживание промышленной БД, но и затраты, возникающие из-за простоев и отказов информационных систем предприятия.
Литература
1. СУБД (рынок России). URL: http://www.tadviser.ru/in-dex.php (дата обращения: 29.02.2012).
2. Oracle Replication. URL: http://www.oracle.com /glo-bal/ru/pdfs/tech /tg_oracle_replication.pdf (дата обращения: 29.02.2012).
3. Базилевский Е.В. Автоматизация деятельности администратора баз данных при работе с конфликтами репликаций в системах управления баз данных ORACLE // Наука и инновации XXI века: матер. Х юбил. окр. конф. молодых ученых (26-27 нояб. 2009 г., Сургут). Сургут: ИЦ СурГУ, 2010. Т. 1. С. 21-23.
