Анализ технологий репликации данных и методы повышения эффективности разрешения конфликтов репликации Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.042+004.658.6 ББК 32.973.26-018.2

Гришмановский П.В., Базилевский Е.В.

АНАЛИЗ ТЕХНОЛОГИЙ РЕПЛИКАЦИИ ДАННЫХ И МЕТОДЫ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ РАЗРЕШЕНИЯ КОНФЛИКТОВ

РЕПЛИКАЦИИ

GrishmanovskyP. V., BazilevskiyE. V.

THE ANALYSIS OF EXISTING TECHNOLOGIES OF DATA REPLICATION AND METHODS OF EFFICIENCY IMPROVING AT REPLICATION CONFLICTS’ RESOLVING SPHERE

Ключевые слова: база данных, репликация данных, конфликты репликации, Microsoft SQL Server, Sybase SQL Server System, Oracle.

Keywords: database, data replication, replication conflicts, Microsoft SQL Server, Sybase SQL Server System, Oracle

Аннотация

Различные фирмы и корпорации предлагают конечным пользователям и промышленным предприятиям СУБД различной функциональности. Давно признана перспективность распределенных баз данных, но соответствующие технологии либо слишком ограниченны, либо чересчур сложны. В данной статье представлен анализ и сравнение технологий репликации, применяемых в продуктах ведущих компаний, разрабатывающих СУБД, включая методы разрешения конфликтов репликации. Несмотря на наличие достаточно развитых средств репликации, их практическое применение не всегда удовлетворяет существующим потребностям предприятий. Это вынуждает искать альтернативные решения. Представленные в данной статье методы разрешения конфликтов репликации отличаются от предлагаемых производителем СУБД большей производительностью и эффективностью, а их внедрение дает предприятию экономическую выгоду.

Abstract

A lot of different companies and corporations offer DBMS with variable functionality to end-users and industries today. The prospects of distributed databases have long been recognized, but current technologies are either too limited or too complicated. Analysis and comparison of replication technologies, used in products of leading companies - DBMS developers, including methods of replication conflicts' resolving are presented in this article. Despite of the presence of a sufficiently advanced replication means, their practical usage does not always satisfy the existing needs of enterprises. This forces the search of alternative solutions. Methods of replication conflicts' resolving, presented in this article, have greater productivity and efficiency then suggested by database developers ones, and their implementation provides economic benefits to the enterprise.

Введение

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

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

Стоит отметить, что рынок систем управления базами данных остается прибыльным и весьма перспективным, так как невозможно предоставлять клиентам комплексные решения без использования СУБД. В результате, все крупные софтверные компании имеют интересы на рынке СУБД. Сегодня в этой области наиболее активными крупными игроками являются корпорации IBM, Microsoft, Oracle, а также Sybase, Cache и др. По данным за 2010 г. лидером стала Oracle, владеющая долей 69,9%, второе место занимает Microsoft (8,5%), а третье - корпорация IBM (7,2%). Четвертое место аналитики присудили фирме Sybase, доля рынка которой составляет 0,7% [5].

Актуальность задач репликации в распределённых базах данных

Наиболее распространенными сценариями репликации являются: простая

репликация с разрешением только для чтения реплик; репликация к мобильному клиенту и от него; разрешение множественных обновлений.

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

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

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

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

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

случае конфликта. Алгоритмы разрешения конфликтов репликации обычно основаны на одном из следующих методов:

- задание уникальных приоритетов серверов: серверы с более высоким

приоритетом «выигрывают» у серверов с более низким приоритетом;

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

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

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

- установить разные диапазоны генераторов ключей для каждого сервера;

- добавить идентификатор сервера в качестве составной части к первичному

ключу;

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

Следует отметить, что именно разрешение множественных обновлений, при всей сложности реализации, позволяет наиболее полно использовать потенциал распределённых баз данных.

Решения в области репликации данных от ведущих производителей СУБД

В СУБД Microsoft SQLServer используется механизм публикации и подписки. После того, как данные одной из баз данных (публикатора) сделаны доступными всем, другая база данных (подписчик) получает реплицированные данные (публикации) при их изменении. Узел, который выполняет передачу данных от публикатора к подписчику, называется распространителем. Таким образом, в архитектуру должны быть включены реплицируемые данные (публикации), база данных-источник (публикатор), распространитель и база данных-приемник (подписчик), а также определен способ работы с данными подписчика (чтение или обновление) и то, как часто требуется репликация.

С использованием развитого инструментария Microsoft SQL Enterprise Manager реплицированная база данных создается достаточно просто, но эту базу данных может быть очень трудно поддерживать. Каждый сервер может быть одновременно публикатором, подписчиком и распространителем, одна и та же таблица может одновременно содержать как реплицированные, так и исходные данные. Это может приводить к сложным взаимным зависимостям и, как показывает опыт, к неустойчивой работе вследствие архитектурных просчетов администратора при проектировании и настройке базы данных.

Для управления репликацией используется компонент Microsoft SQL Executive Task Manager. Задачи, отвечающие за репликацию, запускаются и планируются на сервере распространения и выполняют репликацию, читая журналы публикатора, передавая их каждому подписчику и реализуя все изменения, произведенные публикатором, путем генерации соответствующих команд SQL. При наличии нескольких публикаторов и подписчиков синхронизировать эти задачи достаточно трудно.

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

и содержит в виде одной таблицы консолидированные данные со всех серверов рабочих групп.

Для второго сценария (мобильные данные) Microsoft имеет незаконченное решение. В качестве мобильной базы данных можно использовать ядро Jet (посредством Visual Basic forApplications или выполнением запросов из Access), но через ODBCвозможна лишь ограниченная репликация на Jet. В SQL Server и Jet используются разные версии SQL, и у Jet меньше возможностей, так что мобильные приложения должны отличаться от стационарных, и если однонаправленная репликация небольших объемов данных не вызывает особых затруднений, то более сложная распределенная база данных требует включать в мобильные приложения специально написанные подпрограммы репликации.

Третий сценарий может быть реализован следующим образом. SQL Server допускает наличие нескольких подписчиков к одной таблице, а одна и та же таблица может быть использована как подписанная и как опубликованная. Единственным механизмом разрешения конфликтов являются триггеры на целевой таблице. Механизм очень прост, но недостаточно безопасен, является жестким и усложняет сопровождение базы данных[2].

В СУБД Sybase SQL Server System для управления репликацией используется продукт Replication Server - отдельный набор процессов с собственным командным языком, поддерживающий также обращения к нему через интерпретатор ISQL. Как и в Microsoft SQLServer, используется схема публикации и подписки, но Sybase реализовала репликацию раньше, чем Microsoft и Oracle. Кроме того, возможна репликация не только данных, но и хранимых процедур, что даёт потенциальный выигрыш в производительности, поскольку одна хранимая процедура может выполняться на нескольких узлах, не требуя передачи между ними больших объёмов данных.

Механизм, реализованный в Replication Server, использует процессы операционной системы, а в дополнение к процессу Replication Server для каждого публикатора требуется Replication Agent, который читает журнал файлов и передает соответствующие записи об изменении данных в Replication Server, транслирующий их подписчикам. Replication Agent основан на использовании Open Connectivity, что позволяет использовать базы данных, управляемые не Sybase SQL Server. Replication Server поддерживает множественные обновления, предоставляя полный контроль над разрешением конфликтов: можно выбрать встроенный алгоритм или реализовать свой собственный [4].

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

Компания Sybase является единственной, предлагающей законченное решение для построения мобильных приложений - SQL Anywhere (ранее система Watcom), которое полностью совместимо с SQL Server, включая Transact SQL. Это позволяет запускать на мобильных компьютерах приложения без изменений. Для поддержки репликации данных используется SQL Remote, но этот продукт не настолько полон и гибок как Replication Server и обеспечивает только базовый уровень репликации для поддержки мобильных приложений.

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

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

В основе механизма репликации компании Oracle изначально лежали мгновенные снимки, которые теперь представляют собой развитый механизм. Мгновенный снимок может быть «быстрым» (реплицируются только журнализованные изменения) или «полным» (копируется вся таблица), может быть только читаемым или обновляемым. Последний вариант позволяет вносить в удаленном узле временные изменения, которые действуют до проверки в центральном узле. Однако, использование мгновенных снимков ограничено количеством возможных попыток передачи, после чего требуется вмешательство администратора, а также тем, что быстрый снимок должен базироваться на одной таблице и требует определения журнала мгновенного снимка на стороне сервера и мгновенного снимка на стороне целевого компьютера. Существуют также ограничения на количество одновременно обрабатываемых мгновенных снимков.

В Enterprise Server доступна новейшая технология репликации компании Oracle. Механизм развитой репликации основан на использовании хранимых процедур системного уровня (выполняемых как «задания»), триггеров, запросов и связей с базами данных. Это позволяет точно определить, что нужно реплицировать (полные таблицы или только изменения) и реализовать свой собственный алгоритм разрешения конфликтов. Репликация может быть синхронной и асинхронной, причем этот режим можно менять. Механизм встроен в сервер баз данных и управляется интерпретатором SQL или инструментами администратора, поскольку все команды - это операторы SQL и вызовы хранимых процедур. Однако лучшим средством управления развитой репликацией является компонент Oracle Enterprise Manager, позволяющий создавать группы репликации, что делает большую сложную базу данных гораздо более управляемой [3].

При использовании в Oracleмультимастер репликации появляется возможность для обнаружения и разрешения трех типов конфликтов: конфликтов изменения, конфликтов уникальности и конфликтов удаления.

Конфликт изменения (Update Conflicts) возникает, когда репликация измененной записи конфликтует с другим изменением той же записи из-за ее обновления на двух узлах в примерно одинаковое время. Конфликтов изменения полностью избежать нельзя, но их можно минимизировать в той или иной степени. Oracle позволяет использовать один из методов разрешения конфликтов изменения: additive and average (добавление разницы и замена на среднее значение), minimum and maximum (замена на минимальное или максимальное значение), earliest and latest timestamp (приоритет первого или последнего изменения), overwrite and discard (перезапись или отмена записи), priority groups and site priority (приоритет группы или приоритет сайта), однако вOracleEnterpriseManager можно использовать только стандартный метод LatestTimestamp (приоритет по последнему времени изменения). Время изменения определяется по указанному полю, значение в которое заносится триггером перед добавлением или изменением записи в таблице.

Конфликт уникальности (Uniqueness Conflicts) возникает, когда репликация записи пытается нарушить сущностную целостность (ограничение primary key или unique) -каждая из двух конкурирующих транзакций добавляет запись в таблицу-реплику с одинаковым значением первичного ключа. Возможность возникновения конфликтов уникальности предупредить достаточно легко, например, путем генерации на каждом узле последовательностей, имеющих, не пересекающиеся диапазоны значений. Возможный вариант - генерация чисел, частью которых является номер сайта (первичный ключ в каждой таблице будет составным). В OracleEnterpriseManager используется генерация первичных ключей таблиц для каждого узла в разных диапазонах.

Конфликт удаления (Delete Conflicts) возникает, когда одна транзакция удаляет запись, которую другая транзакция изменяет. Для их устранения предлагается при удалении записи не удалять ее физически, а только помечать как удаленную. Таким образом, конфликты удаления преобразовываются в конфликты изменения и разрешаются

одним из стандартных способов или способом, предусмотренным разработчиком базы данных. Конфликты удаления могут разрешаться различными методами:

- административными - изменения в справочники вносит только администратор системы по заявкам других пользователей;

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

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

Механизм разрешения конфликтов репликации в базах данных Oracle

Механизм разрешения конфликтов репликации, реализованный в предлагаемом администратору продукте OracleEnterpriseManager (OEM), базируется на использовании пакета dbms_defer_query. Объекты пакета позволяют извлечь из системной таблицы system.def$_aqerror данные, которые в неё помещает СУБД Oracle при возникновении конфликтной транзакции. Основными полями, необходимыми для разбора конфликтных транзакций являются:

- ENQ_TID - порядковый номер конфликтной транзакции;

- STEP_NO - номер вызова в транзакции;

- USER_DATA - массив байт (используется тип BLOB), в котором определены тип аргумента, над которым пользователем были произведены изменения, размер аргумента в байтах и собственно исходное и модифицированное значения аргумента.

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

Для разбора вызовов в конфликтных транзакциях OracleEnterpriseManager использует пакет dbms_defer_query, который, кроме прочих, содержит следующие функции:

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

- функция get_arg_type определяет тип аргумента в вызове;

- функция get_datatype_arg определяет значение аргумента в вызове в соответствии его типом, который может являться одним следующих: NUMBER, VARCHAR2, CHAR, DATE, RAW, ROWID, BLOB, CLOB, NCLOB, NCHAR, NVARCHAR2, TIMESTAMP.

Текущее значение изменяемого аргумента определяется посредством SQL-запроса к базе данных по каждому аргументу в вызове конфликтной транзакции.

При возникновении конфликтной транзакции СУБД Oracle помещает в системную таблицу system.def$_aqerror информацию о содержании конфликта. Затем, OracleEnterpriseManager обеспечивает поиск конфликтной транзакции и следующий алгоритм её обработки:

- для каждого вызова конфликтной транзакции определяются типы и используемые наборы символов аргументов вызова при помощи функций

- для каждого из аргументов вызова определяется значение при помощи функции get_datatype_arg;

- при помощи SQL-запроса определяется текущее значение аргумента;

- аналогично обрабатываются аргументы каждого объекта в вызове при помощи функций get_arg_type, get_arg_form и get_datatype_arg;

- найденные значения аргументов вызовов и объектов конфликтной транзакции выводятся для принятия администратором решения о необходимых действиях по её разрешению.

Языком разработки OEM является Java. В отличие от многих языков программирования, Java - это еще и программная платформа, включающая большой объём кода мощной библиотеки и среду для выполнения программ (Java Virtual Machine), которая обеспечивает безопасность, независимость от операционной системы и автоматическую «сборку мусора», а также независимость от архитектуры компьютера, что является несомненным достоинством. Однако, независимость от архитектуры компьютера является в то же время и слабой стороной Java, приводящей к снижению производительности программ, разработанных на этой платформе. Тот факт, что OEM разработан на Java, является одним из факторов, снижающих производительность этого ПО - его слабой стороной является время реакции интерфейса на действия администратора, время формирования соответствующих SQL-запросов, время преобразования полученного результата из БД и предоставления обработанных данных непосредственно администратору. Кроме того, в силу большого объема данных, полученных из БД, и ограниченности ресурсов рабочего места администратора, их оперативная обработка в OEM посредством JVM и отображение результата в OEM иногда оказываются невозможными (приложение «зависает»). По причине постоянного роста промышленных БД, подобные ситуации довольно часты, но являются крайне нежелательными, особенно при разборе конфликтных транзакций и синхронизации данных между различными узлами распределённой БД, так как приводят к блокировке объектов базы данных и невозможности полноценного функционирования информационных систем предприятия.

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

Альтернативные методы разрешения конфликтов репликации

Анализ выше описанного алгоритма разбора вызовов в конфликтных транзакциях показывает, что время разбора можно значительно сократить за счёт разбора массива байт поля USER_DATA из таблицы system.def$_aqerror путём считывания и преобразования без использования вызовов системного пакета dbms_defer_query. Такой подход реализован в разработанном приложении ErrManager и является более эффективным по сравнению с OracleEnterpriseManager, так как требует использования существенно меньших ресурсов сервера базы данных. Локальный разбор конфликтных вызовов требует значительно меньше времени по сравнению с многочисленными вызовами функций системного пакета, что обеспечивает оперативность разрешения конфликтных транзакций и сокращает время блокировки объектов базы данных. Кроме этого, разработанное приложение ErrManager обеспечивает большую функциональность, по сравнению с OEM.

Повышение эффективности обусловлено лишь однократным обращением к системной таблице system.def$_aqerror и получения значения поля типа BLOB целиком в виде массива байт. Его декодирование и дальнейшая обработка осуществляется полностью на строне клиента без обращения к серверу базы данных, то есть используя только ресурсы рабочей станции администратора. При этом также не используется JVM. После обработки данных о конфликтной транзакции, их отображения и принятия решения администратором, выполняется SQL-скрипт для внесения соответствующих изменений.

Обоснование актуальности внедрения приложения ErrManager выполнено путем оценки экономической эффективности, которая определена следующим образом:

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

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

В качестве исходных данных для расчетов использованы следующие: в среднем 1 день работы администратора БД стоит 6 101 р. Соответственно, затраты на одну операцию равны времени на операцию (в днях), умноженной на 6 101 р.

Оценка временных характеристик выполнена посредством следующего эксперимента. На двух узлах распределённой БД, между которыми настроено реплицирование данных, одновременно сформировано 20 транзакций по 20 вызовов в каждой. Один из вызовов в каждой транзакции - конфликтный. Операции произведены над объектом БД «таблица», имеющей 7 полей. На разрешение описанных конфликтных транзакций и синхронизацию данных между различными узлами распределённой БД необходимо затратить 1 ч. 51 мин. 33 сек. при использовании ОЕМ - продукта корпорации Огасіе. При использовании разработанного ПО ErrManager время, затраченное на решение аналогичной задачи сокращается до 12 секунд в случае автоматической синхронизации данных и 20 секунд в случае ручной синхронизации. Для дальнейшего расчёта экономического эффекта примем среднее время, равное 16 секундам.

Анализ журналов базы данных предприятия показал, что в течение дня в среднем возникают 4 аналогичные ситуации, соответственно для их решения средствами ОЕМ требуется 7 ч. 24 мин., а средствами ErrManager - 1 мин. 4 сек. Таким образом, для оплаты одного дня работы администратора необходимо:

- при использовании ОЕМ - 5 643,42 р.;

- при использовании ErrManager - 813,47 р.

На разработку ПО ErrManager потребовалось 60 рабочих дней специалиста с тем же размером оплаты труда. Весь период разработки делится на следующие этапы (сроки ориентировочные):

- исследование предметной области (15 дней);

- разработка и программная реализация алгоритма разрешения конфликтных транзакций (20 дней);

- разработка интерфейса ПО ErrManager (15 дней);

- тестирование (эксперимент, опытная эксплуатация) ПО ErrManager (10 дней).

Таким образом, затраты на разработку составили 366 060 р. В результате получены

следующие оценки экономического эффекта от внедрения ПО ErrManager: в первый год -1 396 871,75 р., в последующие годы - 1 762 931,75 р.

Заключение

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Гаршин И.К. Практика работы с Oracle: генерация, администрирование, репликация. - М.: Издательство «ПОЛТЕКС», 2000, - 250 с.: ил.

2. Microsofr SQL Server 2008 [Электронный ресурс] / SQL Server 2008 - Режим доступа :http://technet.microsoft.com/ru-ru/library/bb418470 (SQL.10).aspx - Загл. с экрана (дата обращения: 29.02.2012).

3. Oracle [Электронный ресурс] /Oracle Replication :http://www.oracle.com/ global/ru/ pdfs/tech/tg_oracle_replication.pdf - Загл. с экрана (дата обращения: 29.02.2012).

4. SyBaseanSapCompany [Электронный ресурс] / ReplicationServer - Режим доступа :http://www.sybase.ru/products/replication_server - Загл. с экрана (дата обращения: 29.02.2012).

5. Tadvaiser [Электронный ресурс] / Статья: СУБД (рынок России) - Режим

доступа: http://www.tadviser.ru/index.php (http://www.tadviser.ru/index.php/%D0%A1

%D 1%82%D0%B0%D 1 %82%D 1%8C%D 1 %8F :%D0%A 1%D0%A3%D0%91 %D0%94_(%D 1%80%D 1 %8B%D0%BD%D0%BE%D0%BA_%D0%A0%D0%BE%D 1%81%D 1%81 %

D0%B8%D0 %B8)) - Загл. с экрана (дата обращения: 29.02.2012).