Технологии реплицирования данных

 

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Казанский национальный исследовательский технологический университет»

(ФГБОУ ВПО «КНИТУ»)

Тема проекта Технологии реплицирования данных

РЕФЕРАТ

Руководитель проекта___________________________(В.Я. Пономарев )

Казань 2014 г.

Содержание

Введение

1. Понятие о компьютерном математическом моделировании

1.1 Общие сведения о компьютерном математическом моделировании

.2 Классификация математических моделей

. Основная идея реплицирования

.1 Основополагающий принцип построения и функционирования распределенных систем

.1 Алгоритм «Клиент-сервер»

3. Частичная реплика

. Технологии объектного связывания данных

. Технологии удалённого доступа и системы БД, тиражирование и синхронизация в распределённых системах БД.

.1 Модель удаленного доступа к данным

.2 Модель сервера базы данных

.3 Модель сервера приложений

. Мониторы транзакций

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

7. Технологии тиражирования (реплицирования) данных

. Примеры применения в производстве

. Реплицирование данных предложенные в Access 7.0

Список используемой литературы

Введение

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

До недавнего времени хранение данных было лишь малой частью компьютерной инфраструктуры на предприятии. По мере роста объемов и ценности, увеличивалась и значимость данных, а их хранение стало одной из важнейших составляющих современного центра обработки данных. Если в 2000-2001 годах объемы вкладываемых в системы хранения средств примерно соответствовали объемам средств, тратившихся на сами серверы, то к 2003 году соотношение изменилось, и объем средств, вкладываемых в системы хранения данных существенно превысил аналогичный объем для серверов (примерно 25% против 75%). Правда, теперь к стоимости самого оборудования прибавляется стоимость средств для управления данными [1].

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

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

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

Цели: 1. Дать определение понятию «реплицирование данных»

. Определить технологии методы реплицирования данных

. Использование технологий реплицирования данных в производстве.

1.Понятие о компьютерном математическом моделировании

1.1Общие сведения о компьютерном математическом моделировании

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

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

Математическое моделирование - метод исследования процессов и явлений на их математических моделях.

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

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

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

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

1.2Классификация математических моделей

К классификации математических моделей можно подходить по-разному, положив в основу классификации различные принципы.

1)Классификация моделей по отраслям наук (математические модели в физике, биологии, социологии и т.д.);

2)Классификация моделей по применяемому математическому аппарату (модели, основанные на применении обыкновенных дифференциальных уравнений, дифференциальных уравнений в частных производных, стохастических методов, дискретных алгебраических преобразований и т.д.)[2];

)Классификация моделей с точки зрения целей моделирования.

§дескриптивные (описательные) модели;

§оптимизационные модели;

§многокритериальные модели;

§игровые модели;

§имитационные модели.

Пример.

1)Моделируя движение кометы, вторгшейся в Солнечную систему, мы описываем (предсказываем) траекторию ее полета, расстояние, на котором она пройдет от Земли и т.д., т.е. ставим чисто описательные цели. У нас нет никаких возможностей повлиять на движение кометы, что-то изменить.

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

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

3)Игровые модели могут иметь отношение не только к детским играм (в том числе и компьютерным), но и к вещам весьма серьезным.

4)Бывает, что модель в большой мере подражает реальному процессу, т.е. имитирует его.

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

Имитационное моделирование - исследование поведения сложной системы на ее модели[3].

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

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

2.Основная идея реплицирования

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

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

Основная идея реплицирования заключается в том, что пользователи работают автономно с одинаковыми (общими) данными, растиражированными по локальным базам данных, обеспечивая с учетом отсутствия необходимости передачи и обмена данными по сетимаксимальную для своих вычислительных установок производительность. Программное обеспечение СУБД для реализации такого подхода соответственно дополняется функциями тиражирования (реплицирования) баз данных,включая тиражирование как самих данных и их структуры, так и системного каталога с информацией о размещении реплик, иначе говоря, с информацией о конфигурировании построенной таким образом распределенной системы[4].

2.1 Основополагающий принцип построения и функционирования распределенных систем

компьютерный математический моделирование данные

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

обеспечение согласованного состояния во всех репликах количества и значений общих данных;

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

Обеспечение согласованного состояния общих данных, в свою очередь, основывается на реализации одного из двух принципов:

принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено);

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

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

Реализация принципа непрерывного размножения обновлений заключается в том, что любая транзакция считается успешно завершенной, если она успешно завершена на всех репликах системы. На практике реализация этого принципа встречает существенные затруднения, связанные с тупиками, как и в технологиях синхронизационных захватов систем «Клиент-сервер». Предположим, что на одной вычислительной установке пользователь обновляет данные в своей реплике[2]. На время осуществления транзакции (транзакций) соответствующие записи в базе данных этой реплики ядром локальной СУБД заблокированы от изменения другими пользователями. Вместе с тем транзакция может быть зафиксирована и, следовательно, разблокированы соответствующие данные только тогда, когда данная транзакция послана и также завершена на других репликах системы. Предположим также, что в другой реплике системы, находящейся на другом компьютере сети, в это же время другой пользователь проводит свои обновления (транзакции) с теми же записями, которые, естественно, в этот момент также заблокированы от изменений для других пользователей[5]. Так образуется тупик. Одна транзакция не может быть зафиксирована в своей реплике, потому что заблокированы соответствующие записи в другой реплике. А разблокировка этих записей в другой реплике также невозможна до тех пор, пока не разблокируются соответствующие записи в первой реплике, т. е. когда завершится транзакция в первой реплике. Создается тупиковая ситуация.

.2 Алгоритм «Клиент-сервер»

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

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

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

Решение второй проблемы согласованности данных, а именно - согласованности структуры данных, осуществляется через частичное отступление, как и в системах «Клиент-сервер», от принципа отсутствия центральной установки и основывается на технике «главной» реплики.

Суть этой техники заключается в том, что одна из реплик базы данных системы объявляется главной. При этомизменять структуру базы данных можно только в главной реплике. Эти изменения структуры данных тиражируются на основе принципа отложенных обновлений, т. е. через специальную синхронизацию реплик. Частичность отступления от принципа отсутствия центральной установки заключается в том, что в отличие от чисто централизованных систем, выход из строя главной реплики не влечет сразу гибель всей распределенной системы, так как остальные реплики продолжают функционировать автономно. Более того, на практике СУБД, поддерживающие технологию реплицирования, позволяют пользователю с определенными полномочиями (администратору системы) преобразовать любую реплику в главную и тем самым полностью восстановить работоспособность всей системы[7].

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

Важным, сточки зрения гибкости и эффективности функционирования распределенных информационных систем, построенных на технологиях реплицирования, является возможность создания так называемых частичных реплик и включения в реплики как реплицируемых, так и нереплицируемых объектов[8].

3.Частичная реплика

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

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

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

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

Тем не менее развитие и все более широкое распространение распределенных информационных систем, определяемое самой распределенной природой информационных потоков и технологий, является основной перспективой развития автоматизированных информационных систем[9].

4.Технологии объектного связывания данных

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

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

Решение этой задачи основывается на поддержке современными «настольными» СУБД (MS Access, MS FoxPro, dBase и др.) технологии «объектов доступа к данным» - DАО[10].

При этом следует отметить, что под объектом понимается интеграция данных и методов, их обработки в одно целое (объект), на чем основываются объектно-ориентированное программирование и современные объектно-ориентированные операционные среды. Другими словами, СУБД, поддерживающие DАО, получают возможность внедрять и оперировать в локальных базах объектами доступа к данным, физически находящимся в других файлах, возможно на других вычислительных установках и под управлением других СУБД.

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

Непосредственно для доступа к данным на основе протокола ODBC используются специальные программные компоненты, называемые драйверами ODBC (инициализируемые на тех установках, где находятся данные).

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

Рис. 1 - Принцип доступа к внешним данным па основе ODBC

Прежде всего, современные настольные СУБД обеспечивают возможность прямого доступа к объектам (таблицам, запросам, формам) внешних баз данных «своих» форматов. Иначе говоря, в открытую в текущем сеансе работы базу данных пользователь имеет возможность вставить специальные ссылки-объекты и оперировать с данными из другой (внешней, т. е. не открываемой специально в данном сеансе) базы данных.

Объекты из внешней базы данных, вставленные в текущую базу данных, называются связанными и, как правило, имеют специальные обозначения для отличия от внутренних объектов. При этом следует подчеркнуть, что сами данные физически в файл (файлы) текущей базы данных не помещаются, а остаются в файлах своих баз данных. В системный каталог текущей базы данных помещаются все необходимые для доступа сведения о связанных объектах - внутреннее имя и внешнее, т. е. истинное имя объекта во внешней базе данных, полный путь к файлу внешней базы и т. П[11].

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

Технически оперирование связанными объектами из внешних баз данных «своего» формата мало отличается от оперирования с данными из текущей базы данных.

Ядро СУБД при обращении к данным связанного объекта по системному каталогу текущей базы данных находит сведения о месте нахождения и других параметрах соответствующего файла (файлов) внешней базы данных и прозрачно (т. е. невидимо для пользователя) открывает этот файл (файлы). Далее обычным порядком организует в оперативной памяти буферизацию страниц внешнего файла данных для непосредственно доступа и манипулирования данными.

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

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

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

Аналогичным образом обеспечивается доступ к данным, находящимся в базах данных наиболее распространенных форматов других СУБД, таких, например, как базы данных СУБД FoxPro, dBASE[8].

При этом доступ может обеспечиваться как непосредственно ядром СУБД, так и специальными дополнительными драйверами ISAM (Indexed Sequential Access Method), входящими, как правило, в состав комплекта СУБД.

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

Определенной проблемой технологий объектного связывания является появление «брешей» в системах защиты данных и разграничения доступа. Вызовы драйверов ODBC для осуществления процедур доступа к данным помимо пути, имени файлов и требуемых объектов (таблиц), если соответствующие базы защищены, содержат в открытом виде пароли доступа, в результате чего может быть проанализирована и раскрыта система разграничения доступа и защиты данных[12].

5. Технологии удалённого доступа и системы БД, тиражирование и синхронизация в распределённых системах БД

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

технологии «Клиент-сервер»;

технологии реплицирования (тиражирования);

технологии объектного связывания.

Распределенные информационные системы, как правило, построены на основе сочетания всех трех технологий.

Технологии и модели «Клиент-сервер».

В основе клиент-серверных технологий лежат две основные идеи:

общие для всех пользователей данные на одном или нескольких серверах;

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

Под сервером в широком смысле понимается любая система, процесс, компьютер, владеющие каким-либо вычислительным ресурсом (памятью, временем, производительностью процессора и т.д.).

Клиентом называется также любая система, процесс, компьютер, пользователь, запрашивающие у сервера какой-либо ресурс, пользующиеся каким-либо ресурсом или обслуживаемые сервером иным способом[13].

В структуре СУБД выделяют три компонента:

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

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

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

Исходя из особенностей реализации и распределения в системе этих компонентов, различают четыре модели технологий «Клиент-сервер»:

модель файлового сервера (FS);

модель удаленного доступа к данным (RDA);

модель сервера базы данных (DBS);

модель сервера приложений (AS).

Модель файлового сервера.

Один из компьютеров сети определяется файловым сервером (общим хранилищем данных), а все основные компоненты СУБД размещаются на клиентских установках. При обращении к данным ядро СУБД обращается с запросами на ввод-вывод данных к файловой системе. В оперативную память клиентской установки на время сеанса работы полностью или частично копируется файл базы данных. Достоинствамодели: простота и отсутствие высоких требований к производительности сервера. Недостатки: высокий сетевой трафик, отсутствие специальных механизмов СУБД по обеспечению безопасности данных.

5.1 Модель удаленного доступа к данным

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

Достоинства. В результате реализации такого подхода резко уменьшается загрузка сети. RDA-модель позволяет также унифицировать интерфейс взаимодействия прикладных компонентов СУБД с общими данными. Такое взаимодействие стандартизовано в рамках языка SQL специальным протоколом ODBC, играющим важную роль в обеспечении независимости от типа СУБД на клиентских установках. Это позволяет интегрировать уже существующие локальные БД в создаваемые распределенные информационные системы независимо от типов СУБД клиентов и сервера. Недостатки. Высокие требования к клиентским вычислительным установкам, так как на них выполняются прикладные программы обработки данных. Значительный трафик сети, поскольку с сервера направляются клиентам наборы данных, которые могут иметь существенный объем[14].

5.2 Модель сервера базы данных

На клиентских установках в DBS-модели размещается только интерфейсный компонент, а все остальные компоненты СУБД размещаются на сервере. От клиентов на сервер направляются только вызовы необходимых процедур, запросов и других функций по обработке данных. Все операции по обработке данных выполняются на сервере, а пользователю направляются лишь результаты обработки (а не наборы данных, как в RDA-модели).

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

5.3 Модель сервера приложений

Чтобы разнести требования к вычислительным ресурсам сервера в отношении быстродействия и памяти по разным вычислительным установкам, используется модель сервера приложений. Суть данной модели состоит в переносе прикладного компонента СУБД на специализированный в отношении повышенных по быстродействию ресурсов дополнительный сервер системы - сервер приложений. На клиентских установках располагается интерфейсная часть СУБД, откуда вызовы функций обработки данных направляются на сервер приложений. За выполнением низкоуровневых операций по доступу к данным сервер приложений обращается к SQL-серверу, направляя ему вызовы SQL-процедур и получая от него наборы данных. Таким образом, сервер приложений управляет формированием транзакций, которые выполняетSQL-сервер. Поэтому прикладной компонент СУБД, расположенный на сервере приложений, называют монитором транзакций. AS-модель, сохраняя достоинства DBS-модели, позволяет более оптимально построить вычислительную схему информационной системы, однако при этом увеличивается трафик сети.

RDA- и DBS-модели называют двухзвенными (двухуровневыми), AS-модель - трехзвенной (трехуровневой).

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

6. Мониторы транзакций

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

Механизм обработки транзакций играет важную роль в обеспечении ограничений целостности БД. Ограничения целостности непосредственно проверяются по завершению очередной транзакции. Если условия ограничений целостности данных не выполняются, то происходит «откат» транзакции, в противном случае транзакция фиксируется.

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

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

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

В случае, когда одна транзакция читает какой либо объект БД, а другая транзакция в это же время его изменяет и успешно фиксируется, возникают неповторяющиеся чтения, то есть при повторном чтении объекта незавершенной транзакцией она «видит» его в другом состоянии (чтение не повторяется). По этой причине устанавливается запрет на изменение объекта любой другой транзакцией, пока не завершена первая транзакция на чтение.

6.1 Механизм изоляции транзакций и преодоления ситуаций несогласованной обработки данных основывается на технике сериализации транзакций

Сериализацией транзакций называется их выполнение по некоторому сериальному плану.

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

Методы сериализации транзакций:

синхронизационные захваты (блокировки) объектов БД;

временные метки объектов БД.

Выделяют два основных режима синхронизационных захватов - совместный (захват по чтению) и монопольный (захват по записи) режимы. При совместном режиме осуществляется разделяемый захват, требующий только операций чтения. При монопольном режиме осуществляется неразделяемый захват, требующий операций обновления данных. Наиболее распространенным вариантом реализации синхронизационных захватов является двухфазный протокол блокировок 2PL, в соответствии с которым выполнение транзакции происходит в два этапа. На первом этапе перед выполнением любой операции транзакция запрашивает и накапливает захваты необходимых объектов в соответствующем режиме. После получения и накопления необходимых захватов выполняется вторая фаза - фиксация изменений или откат по соображениям целостности данных, а также последующее освобождение захватов. При построении сериальных планов допускается совмещение только захватов по чтению. Более эффективные планы сериализации транзакций позволяет строить применение «гранулирования» синхронизационных блокировок. В этом случае «гранулируются» объекты захвата (файлы, таблицы, страницы файла, записи), что позволяет расширить номенклатуру синхронизационных режимов захватов (напр., совместный режим захвата файла с возможностью монопольного захвата отдельных его объектов - таблиц, страниц, записей). Недостаток синхронизационных захватов - возможность возникновения тупиков. Распознавание (автоматическое обнаружение) тупиков основывается на построении и анализе графа ожидания транзакций, состоящего из вершин-транзакций и вершин-объектов захвата. Требуемым захватам соответствуют дуги, исходящие из вершин-транзакций к вершинам-объектам; противоположное направление дуг соответствует полученным захватам. Циклы (петли) на графе соответствуют тупиковым ситуациям. Для обнаружения циклов применяется алгоритм редукции графа, который требует постоянного обновления графа ожидания транзакций, что снижает эффективность обработки данных. Для разрешения (разрушения) тупиков используются различные алгоритмы разрушения тупиков. Такие алгоритмы основываются на выборе транзакции-жертвы, которая временно откатывается для предоставления возможности завершения операций другим транзакциям. В качестве такой транзакции выбирается транзакция с наименьшим приоритетом, либо та транзакция, которая требует меньше всего затрат на выполнение.

Другой, более простой, метод сериализации транзакций - метод временных меток, в соответствии с которым каждой транзакции приписывается временная метка, соответствующая моменту начала выполнения транзакции. При выполнении операции над объектом транзакция «помечает» его своей меткой и типом операции (чтение или изменение). Если при этом другой транзакции требуется операция над уже помеченным объектом, то выполняется ряд действий по разрешению возникшей ситуации. Применение метода временных меток вызывает более частые откаты назад транзакций, чем при синхронизационных блокировках. Однако достоинством метода временных меток является отсутствие тупиков, а, следовательно, и отсутствие накладных расходов на их распознавание и разрушение[16].

. Технологии тиражирования (реплицирования) данных

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

Реплика - тиражируемая копия данных, предназначенных для общего пользования.

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

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

принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено). Данный принцип реализуется при построении систем реального времени. Реализация этого принципа заключается в том, что любая транзакция считается успешно завершенной, если она успешно завершена во всех репликах. На практике реализации данного принципа препятствует возникновение тупиков. Для обнаружения и распознавания тупиков в реплицированных системах применяются те же алгоритмы, что и в мониторах транзакций централизованных систем типа «клиент-сервер».

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

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

Наряду с техникой главной реплики существует возможность создания частичных реплик. Частичной репликой называется база данных, содержащая ограниченное подмножество записей главной (полной) реплики. Распространенным способом создания частичных реплик является использование фильтров, устанавливаемых для таблиц главной реплики. Такой подход позволяет решать некоторые проблемы по разграничению доступа к данным, повысить производительность обработки данных и снизить затраты на синхронизацию реплик за счет ограничения количества передаваемых по сети изменений данных[10].

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

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

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

8. Примеры применения в производстве

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

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

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

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

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

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

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

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

Тем не менее, развитие и все более широкое распространение распределенных информационных систем, определяемое самой распределенной природой информационных потоков и технологий, является основной перспективой развития автоматизированных информационных систем.

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

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

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

Решение второй проблемы согласованности данных, а именно - согласованности структуры данных, осуществляется через частичное отступление, как и в системах «Клиент-сервер», от принципа отсутствия центральной установки и основывается на технике «главной» реплики.

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

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

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

Автономные приложения. Работают на одном компьютере[17].

. Реплицирование данных предложенные в Access 7.0

Возможности реплицирования данных и объектов являются нововведением для продуктов, представленных на рынке настольных баз данных. На сегодняшний день ни одна другая настольная СУБД такими возможностями не обладает. Для реплицирования созданных в Access баз данных используется средство «Портфель» (Briefcase) ОС Windows 95, что не может служить ограничением для применения СУБД, способной работать лишь в среде Windows 95.

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

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

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

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

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

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

. Реплицирование позволяет распространить изменения в базовом проекте (например, новые формы и отчеты) на все его копии.

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

Каждая из копий базы данных может быть перенесена на другой компьютер, где независимо от других копий в нее можно вносить необходимые изменения. Чтобы привести две копии в соответствие между собой, перенесите их на один компьютер и одну из копий разместите в папке «Портфель». Двойным щелчком откройте папку и выберите нужную копию. Затем воспользуйтесь опцией «Обновить выделенные объекты» (Update Selection) меню «Портфель» (Briefcase). Опция «Обновить все» (Update All) того же меню позволит обновить все базы данных, копии которых размещены в папке «Портфель»[5].

Список используемой литературы

1. Бобровский С.Д., учебный курс; СПб: Питер - Москва, 2003. - 736 c.

. Вивек, Шарма; Раджив, Шарма Разработка Web-серверов для электронной коммерции. Комплексный подход; М.: Издательский дом Вильямс - Москва, 2001. - 400 c.

. Гилман, Л.; Роуз, А. Курс АПЛ: диалоговый подход; Мир - Москва, 1979. - 526 c.

. Грунд, Ф. Программирование на языке ФОРТРАН IV; М.: Мир - Москва, 1976. - 183 c.

. Гукин, Дэн C для "чайников"; М.: Вильямс - Москва, 2006. - 352 c.

. Драммонд, М. Методы оценки и измерений дискретных вычислительных систем; М.: Мир - Москва, 1977. - 384 c.

. Дронов, В. JavaScript в Web-дизайне; СПб: БХВ - Москва, 2001. - 880 c.

. Дьяконов, В.П. Справочник по алгоритмам и программам на языке бейсик для персональных ЭВМ; М: Наука - Москва, 1987. -240 c.

. Жешке, Рекс Толковый словарь стандарта языка Си; СПб: Питер - Москва, 1994. - 221c.

. Калашников О. Ассемблер? Это просто! Учимся программировать (+ CD-ROM); СПб: БХВ - Москва, 2006. - 384 c.

. Калверт, Ч. Базы данных в Delphi 4; Киев: ДиаСофт - Москва, 1999.-464 c.

. Касперски, К.; Рокко, Е. Искусство дизассемблирования; BHV - Москва, 2008. - 896 c.

. Касьянов, В.Н.Оптимизирующие преобразования программ; Наука - ,1988.-336с.

. Кнут, Д. Искусство программирования для ЭВМ; М.: Мир - Москва, 1976. - 569 c.

. Кувыкин, В.А.; Коваль, И.Г.; Кувыкина, М.И. и др. Прикладное программирование в системе КАМА; М.: Финансы и статистика, 1983. - 271 c.

. Культин, Никита Основы программирования в Delphi 7; СПб: БХВ - Москва, 2003. - 608 c.

. Кьоу, Дж.; Джеанини, М. Объектно-ориентированное программирование. Просто и понятно; СПб: Питер - Москва, 2005. - 238 c.

МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Казанский национальный

Больше работ по теме: