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

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

Обработка транзакций в OLTP-системах

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

Чтобы использование механизмов обработки транзакций позволило обеспечить целостность данных и изолированность пользователей, транзакция должна обладать четырьмя основными свойствами:

· атомарность (atomicity) - транзакция должна полностью выполняться или не выполняться как единая операция доступа к БД;

· согласованность (consistency) - выполнение ограничений целостности БД после окончания обработки транзакции;

· изолированность (isolation) - разделяемые данные транзакции не доступны другим транзакциям до окончания их изменения,

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

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

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

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

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

Восстановление данных требуется после аппаратных и программных сбоев. Обычно рассматриваются два возможных вида аппаратных сбоев:

· мягкие сбои - внезапная остановка работы компьютера (например, аварийное выключение питания);

· жесткие сбои - потеря информации на носителях внешней памяти.

· Примерами программных сбоев могут быть:

· аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя);

· аварийное завершение пользовательской программы, в результате которого некоторая транзакция остается незавершенной.

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

Журнал – это особая часть БД, недоступная пользователям СУБД, в которую поступают записи обо всех изменениях основной части БД. При этом придерживаются стратегии "упреждающей" записи в журнал.

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

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

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

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

Дата добавления: 2013-12-13