Программные продукты и системы

Одним из лидеров в разработке корпоративных СУБД является компания «Oracle», предоставляющая наиболее гибкое и законченное решение для создания распределенных БД, обеспечивающих различные механизмы репликации данных между узлами, включая множественные обновления [1]. СУБД Oracle также включает механизмы обнаружения и устранения конфликтов репликации. Однако для управления процессом репликации и разрешения конфликтных транзакций администратору предлагается продукт Oracle Enterprise Manager (OEM), который не позволяет использовать все возможности СУБД Oracle, а принципы его реализации делают работу неэффективной и неустойчивой, что приводит к нарушению производственного процесса и дополнительным затратам из-за длительной блокировки объектов БД [2].

Недостатки OEM обусловили необходимость поиска альтернативных средств для разрешения конфликтов репликации и разработки автором специального программного продукта ErrManager [3]. Актуальной задачей является оценка адекватности полученного решения и его эффективности по сравнению с OEM посредством выполнения тестовых заданий для обоих программных продуктов.

Для определения временных затрат обработки конфликтных транзакций в Oracle Enterprise Ma- nager и 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;

–      дисплей с разрешением 1024´768 точек (цветной);

–      наличие локальной сети и доступа к серверу с БД.

Кроме того, для 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 Гб;

–      дисплей с разрешением 1024´768 точек (цветной);

–      ОС 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 оценивались путем включения в программный код приложения вызовов, фиксирующих текущее системное время, и выполнения на основе полученных временных меток расчетов, характеризующих время, затраченное на отдельные операции (рис. 2).

Таким образом, разбор одного вызова занимает 0,025 сек., одной конфликтной транзакции – 0,5 сек. и, наконец, 20 конфликтных транзакций – 10 сек. При разрешении конфликтных транзакций средствами ПО ErrManager нет необходимости использовать иные продукты для синхронизации данных между различными узлами распределенной БД. При разборе конфликтных транзакций синхронизация может быть выполнена либо автоматически, либо вручную, путем генерирования программными средствами ПО ErrManager sql-скрипта и дальнейшего его выполнения. Автоматическая синхронизация данных занимает порядка 2 сек. При ручной синхронизации данных посредством генерации и выполнения sql-скриптов это время увеличивается до 10 сек. Временные оценки приведены для случая синхронизации данных по всем 20 конфликтным транзакциям.

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

Функции, реализованные в утилите ErrMana­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 // Наука и инновации ХХI века: матер. Х юбил. окр. конф. молодых ученых (26–27 нояб. 2009 г., Сургут). Сургут: ИЦ СурГУ, 2010. Т. 1. С. 21–23.