Малков О.Б., Гегечкори Е.Т. Базы данных

Подождите немного. Документ загружается.

В СУБД, основанных на архитектуре «клиент–сервер», наиболее

распространен подход, реализующий соблюдение протокола двухфазного

блокирования объектов БД. Перед выполнением любой операции над

объектом БД от имени транзакции запрашивается захват объекта в

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

на две фазы:

 фаза роста – накопление захватов (установление блокировок);

 фаза фиксации или отката – освобождение захватов (снятие

блокировок).

Реализуемость транзакций гарантируется, если блокировки, относящиеся

к одновременно выполняемым транзакциям, удовлетворяют правилу: «Ни

одна блокировка от имени какой-либо транзакции не должна

устанавливаться, пока не будет снята ранее установленная блокировка».

В реляционных БД объектами для захвата могут быть:

 файл – физический (с точки зрения БД) объект, область хранения

нескольких отношений и индексов;

 таблица – логический объект, соответствующий множеству записей

данного отношения;

 страница данных – физический объект, хранящий записи одного или

нескольких отношений, индексную или служебную информацию;

 запись – элементарный физический объект БД.

Блокировка на уровне поля не реализована, поскольку приводит к

перегрузке менеджера блокировок и к падению производительности системы.

Выбор вида блокировки и объекта зависит от того, какая операция

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

обработки. Например, если осуществляется массовая корректировка файла,

то лучше открыть его в эксклюзивном режиме, чем последовательно

блокировать каждую запись.

Очевидно, что чем крупнее объект захвата, тем меньше захватов будет

поддерживаться в системе и на это будут тратиться меньшие накладные

расходы. Если выбрать в качестве уровня объектов для захватов файл или

отношение, то будет решена даже проблема фантомных вставок.

Однако при использовании для захватов крупных объектов возрастает

вероятность конфликтов транзакций и уменьшается возможность их

параллельного выполнения. При укрупнении объекта захвата мы умышленно

огрубляем ситуацию и видим конфликты в тех ситуациях, когда на самом

деле конфликтов нет.

Некоторые системы предусматривают динамическую схему блокировки,

заключающуюся в том, что сначала транзакция блокирует большой объект,

например страницу. Если проявляется другая транзакция, претендующая на

какую-то запись внутри этой страницы, то первая транзакция автоматически

уменьшает зону блокировки до уровня записи.

5.5. Представления, хранимые процедуры, триггеры

Представление (View) – это виртуальная таблица, содержащая

результаты выполнения запроса (оператора SELECT) к одной или

нескольким таблицам. Для конечного пользователя представление выглядит

как обычная таблица, над которой можно выполнять операторы SELECT,

INSERT, UPDATE и DELETE.

Выбор типа представления полностью зависит от задач приложения.

Выделяют следующие типы представлений:

 подмножество полей таблицы состоит из одного или более полей

таблицы. Используется для упрощения представления данных и обеспечения

безопасности;

 подмножество записей таблицы включает определенное количество

записей таблицы и также применяется для обеспечения безопасности;

 соединение двух и более таблиц создается соединением нескольких

таблиц и используется для упрощения сложных операций соединения;

 агрегирование информации создается группированием данных и

также применяется для упрощения сложных операций.

Представления позволяют логически объединять данные нескольких

таблиц в более крупную виртуальную таблицу. Представления могут иметь

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

представления выполняется согласно уровню безопасности пользователя.

Таким образом, представление можно применять для сокрытия данных от

определенной группы пользователей.

Для создания представлений используется мастер или команда CREATE

VIEW.

Хранимая процедура (stored procedure) – это набор операторов T-SQL,

скомпилированных в единый план выполнения. Этот план сохраняется в

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

каждом вызове. Хранимая процедура может принимать входные параметры,

возвращать данные и коды завершения.

Существует два типа хранимых процедур:

 системные, применяемые для управления сервером и отображения

информации о БД и пользователях;

 пользовательские, создаваемые пользователями для прикладных

задач.

Применение хранимых процедур улучшает производительность и

позволяет централизованно контролировать выполнение задачи, что

гарантирует соблюдение бизнес-правил.

Для создания хранимых процедур используется мастер или команда

CREATE PROCEDURE.

Триггер (trigger) – это особый тип хранимой процедуры, которая

автоматически выполняется при изменении таблицы с помощью операторов

UPDATE, INSERT или DELETE. Триггеры содержат операторы T-SQL, но в

отличие от процедур запускаются не индивидуально, а автоматически при

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

и соблюдение бизнес-правил.

Триггер создается на одной таблице (таблица триггера) в текущей БД,

хотя может использовать данные других таблиц и объекты других БД.

Триггеры нельзя создавать на представлениях, временных и системных

таблицах.

В программе-триггере нельзя использовать операторы создания,

реструктуризации, удаления объектов, реконфигурации и восстановления.

Триггеры возвращают результаты своей работы в приложение, подобно

хранимым процедурам.

Возможно создание нескольких триггеров на таблице и рекурсивный

вызов триггера. Допускаются вложенные триггеры, которые срабатывают в

результате выполнения других триггеров.

Для создания триггера используется мастер или команда CREATE

TRIGGER.

5.6. Тиражирование данных

Тиражирование (репликация) – технология, предусматривающая

поддержку копий всей БД или ее фрагментов в нескольких узлах сети. Копия

БД называется репликой. Копии БД обычно приближены к местам

использования информации.

Синхронизация – процесс обновления реплик, при котором происходит

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

Обмен данными между репликами может быть как односторонним, так и

двусторонним.

Терминология и подходы к реализации репликации отличаются от

системы к системе. В некоторых системах используются метафоры из

издательской деятельности (издатель, публикация, подписчик). Совокупность

данных, которые могут подвергаться тиражированию, называется

публикацией.

Использование технологии тиражирования имеет следующие

преимущества:

 сокращение сетевого трафика при выполнении запросов;

 повышение доступности данных (доступ к локальной копии БД

обеспечивается, даже если доступ к центральному серверу невозможен);

 повышение производительности (данные приближены к месту их

использования, не нужно ждать доступности всех частей распределенной

БД);

 повышение автономности рабочих мест пользователей;

 повышение надежности системы (наличие множества копий

повышает вероятность восстановления системы в критических ситуациях).

Дублирование данных при использовании тиражирования влечет за

собой:

 дополнительный расход памяти;

 возможность возникновения конфликтов при корректировке;

 наличие временного лага между фиксацией события в БД и до-

ступностью этой информации для всех пользователей сети;

 повышенные требования к рабочим станциям;

 необходимость тщательного продумывания схемы тиражирования.

Требования к механизму тиражирования зависят от задач, которые

решает вся система. Существует много схем обновления копий в

распределенной БД. По моменту внесения изменений в реплики различают:

 синхронное тиражирование;

 асинхронное тиражирование.

При асинхронном тиражировании обновление всех копий БД может

проводиться неодновременно. При этом возможна некоторая

рассинхронизация состояния локальных БД во времени. При этом удается

обойти проблему ограниченной пропускной способности и недостаточной

надежности сети. Если один сервер, требующий обновления данных, выходит

из строя, то система продолжает работать с остальными. Обновление данных

на сбойном сервере произойдет автоматически после восстановления его

работоспособности.

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

работе в глобальной сети. При использовании телефонных линий механизм

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

оборудование одновременно в работоспособном состоянии почти никогда не

находится.

Асинхронное тиражирование может быть:

 периодическим;

 апериодическим.

Периодическое тиражирование выполняется через заданные интервалы

времени. Время тиражирования выбирается исходя из частоты и

интенсивности изменений, допустимого времени рассинхронизации

состояний источника и приемника, объема передаваемых данных,

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

тиражирования определяется каким-либо событием и может быть

реализован с помощью хранимых процедур или триггеров.

Синхронное тиражирование предполагает завершение транзакции

только после успешной модификации всех копий. Используется механизм

двухфазной фиксации (2РС): основная система связывается с подчиненными

копиями БД и одновременно вносит в них изменения, блокируя

соответствующие записи. Если хотя бы одна копия недоступна, изменения не

выполняются. Механизм двухфазовой фиксации предъявляет высокие

требования к системе и снижает степень автономности узлов, поэтому в

технологии тиражирования используется редко.

Наиболее жестким является критерий полной эквивалентности копий,

требующий, чтобы по завершении транзакции все копии логического

элемента данных были идентичны. Такая технология синхронизации

противоречит одной из основных целей тиражирования (повышение

производительности за счет большей автономности частей системы) и

используется редко.

Типичным протоколом тиражирования по критерию полной

эквивалентности копий является Read-Once/Write-All (ROWA) – одно чтение

(какой-либо одной копии), запись во все физические копии. Протокол ROWA

прост, но требует доступности всех копий элемента данных для завершения

транзакции. Сбой на одном из узлов приведет к дублированию транзакции.

Реплики в БД с тиражированием могут быть:

 равноправными;

 неравноправными (одна из реплик считается основной).

При наличии неравноправных реплик изменения можно вносить только в

основную реплику. Другие реплики доступны пользователям только по

чтению. Такая схема называется тиражированием из основного узла. При

этом данные асинхронно копируются из основной в иные реплики. При такой

схеме предъявляются повышенные требования к сохранности основной

реплики и надежности функционирования основного узла, поэтому иногда

модель дополняют горячим резервированием основного узла. Основной узел

тиражирует изменения на подчиненные узды и на узел с резервной копией.

Если основной узел выходит из строя, то владельцем данных становится

резервный.

Тиражирование слиянием предполагает выполнение операций на

удаленном компьютере, который может быть отключен от сети. Автономная

СУБД записывает операции с данными и их очередность. Автономный

компьютер связывается с издателем (сервером, на котором корректируется

тиражируемая БД) и пересылает последовательность операций, проведенных

в удаленной БД. Тиражирование слиянием обеспечивает максимальную

автономность удаленной БД.

Инициаторами обновления реплик могут быть:

 рабочие станции (обновление по запросу, выполняемое по

определенному графику или вручную);

 сервер (принудительная рассылка тиража, осуществляемая в момент

появления изменений или по графику).

Обновление содержания реплик может быть обеспечено также:

 копированием моментального снимка БД;

 копированием и выполнением очереди подтвержденных транзакций;

 копированием изменений из журнала БД.

Моментальный снимок БД (snapshot) отражает состояние БД или ее

фрагмента на момент получения снимка. При копировании моментального

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

В процессе тиражирования транзакций от издателя к подписчикам

передаются не данные, а операции над ними. Само обновление происходит

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

автономной БД уже хранится копия основной БД. При использовании этой

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

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

использовать, когда объем БД велик, а операций над ними выполняется

немного. В случае обновления на подписчике тиражирование инициируется

издателем. Как только издатель подтверждает транзакцию, он сообщает

дистрибьютеру о том, что данные изменены.

5.7. Резервное копирование и восстановление

Резервное копирование и восстановление можно выполнить с помощью

утилит (например, Enterprise Manager в MS SQL Server), мастера или команд

T-SQL. Для размещения архивных копий должно быть создано логическое

устройство (которое может быть отдельным физическим устройством).

Резервное копирование выполняется для каждой БД индивидуально и

может производиться несколькими способами.

Полное резервное копирование обеспечивает архивирование всех данных

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

способ наиболее часто используется для архивирования БД небольшого

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

копирование групп файлов.

Выборочное (дифференциальное) резервное копирование обеспечивает

архивирование только тех данных базы, которые были изменены с момента

последнего архивирования.

Резервное копирование журнала транзакций обеспечивает

архивирование и усечение журнала.

В случае резервного копирования файлов и групп файлов их можно

копировать вместе или по отдельности. Полностью восстановить БД с

помощью резервной копии файлов и группы файлов сложнее, чем с помощью

обычной резервной копии. Для восстановления таблиц и индексов, которые

охватывают несколько групп файлов, нужно, чтобы эти файлы и группы

файлов были скопированы вместе с охватывающими их объектами.

Восстановление БД после сбоев обеспечивается с помощью журнала

транзакций. Основным принципом согласованной политики записи

изменений в журнал и в БД является то, что запись об изменении объекта БД

должна попадать во внешнюю память журнала раньше, чем измененный

объект оказывается во внешней памяти БД. Протокол журнализации (и

управления буферизацией) называется WAL (Write Ahead Log – «пиши

сначала в журнал»).

Каждая успешно завершившаяся транзакция должна быть зафиксирована

во внешней памяти. Минимальным требованием, гарантирующим

возможность восстановления последнего согласованного состояния БД,

является сохранение во внешней памяти журнала всех записей об изменении

БД этой транзакцией. При этом последней записью в журнале от имени

данной транзакции является специальная запись о конце транзакции.

Иногда для восстановления БД после сбоя журнала изменений

недостаточно. Основой восстановления в этом случае являются журнал и

архивная копия БД. Восстановление начинается с обратного копирования БД

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

повторно выполняются все операции. Для транзакций, не закончившихся к

моменту сбоя, выполняется откат.

К ведению журнала предъявляются особые требования по части

надежности, однако реально возможна и его утрата. Тогда единственным

способом восстановления БД является возврат к архивной копии. Самый

простой способ производства архивных копий БД – архивировать БД при

переполнении журнала. В этом случае образование новых транзакций

временно блокируется. Когда БД придет в согласованное состояние, можно

выполнять ее архивацию, после чего начинать заполнять журнал заново.

Можно выполнять архивацию БД реже, чем переполняется журнал. При

переполнении журнала и окончании начатых транзакций можно

архивировать сам журнал. Поскольку архивированный журнал требуется

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

архивации может быть сжата.

Процесс восстановления БД зависит от типа архива. При восстановлении

из дифференциального архива или из архива журнала транзакций

необходимо предварительно восстановить БД из последнего полного архива.

Для правильного восстановления БД на основе файлов или группы файлов

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

Существуют общие требования к системе восстановления данных в

СУБД.

1. Пользователь не должен осуществлять рестарт транзакций или

повторный ввод данных. Восстановление должно проходить на базе

транзакции с помощью отмены или изменения отдельных транзакций.

2. Быстрое восстановление данных обеспечивается генерацией данных,

используемых для восстановления.

3. При выполнении процедур автоматизированного восстановления

пользователь не должен анализировать состав данных и выбирать сами

процедуры.

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

 программы ведения системного журнала регистрируют операции

над БД;

 программы архивации используются для регулярного получения

копий БД для последующего ее восстановления;

 программы восстановления применяются для возврата БД или

некоторых ее частей в состояние, предшествующее возникновению отказа;

 программы отката ликвидируют последствия выполнения

определенной транзакции в БД;

 программы записи контрольных точек и повторного исполнения

позволяют ускорить восстановление.

Контрольная точка – это операция согласования состояния БД в

физических файлах с текущим состоянием кэша (системного буфера). С

целью улучшения производительности сохраняемые в БД данные сначала

помещаются в кэш, а потом система перезаписывает модифицированные

страницы на диск (отложенная запись), причем пользователь не может знать,

когда эта запись производится.

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

завершении работы сервера, а также в соответствии с установленным

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

операций:

 запись на диск всех страниц, измененных к началу контрольной

точки;

 запись в журнал транзакций списка незавершенных транзакций;

 запись в журнал транзакций всех измененных страниц;

 регистрация завершения контрольной точки в базе данных (а не в

журнале транзакций).

6. СРЕДСТВА ЗАЩИТЫ ДАННЫХ

При работе в многопользовательском режиме особую актуальность

приобретает защита данных от несанкционированного доступа. Существуют

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

безопасности.

Шифрование / дешифрование. Шифрование БД – это простейший способ

защиты, при котором файл БД видоизменяется и становится недоступным

для чтения с помощью стандартных служебных программ или текстовых

редакторов. Шифрование незащищенной БД неэффективно, поскольку

исходную БД можно открыть и получить полный доступ к ее объектам.

Шифрование применяется при электронной передаче БД или сохранении ее

на внешних носителях. Дешифрование БД – это операция, обратная

шифрованию.

Отображение и скрытие объектов. Другим способом защиты является

скрытие всей БД при просмотре каталогов средствами операционной

системы или скрытие отдельных объектов БД при работе с БД средствами

конкретной СУБД. Этот способ защиты не является достаточно надежным,

поскольку скрытые объекты относительно просто можно отобразить.

Использование параметров запуска. Способ позволяет задать стартовую

форму, которая автоматически открывается при открытии БД. При этом

можно скрыть окно БД и установить собственную кнопочную форму.

Пользователь может выполнять с БД действия, которые допускает

интерфейс.

Использование пароля. Простым способом защиты является установка

пароля для открытия БД. При каждом открытии БД будет появляться

диалоговое окно, в которое требуется ввести пароль. Может быть установлен

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

при котором пароль присваивается каждому пользователю. Для каждого

пользователя могут быть определены объекты, доступ к которым он

получает.

Запрещение репликации БД. Репликация позволяет пользователям

создавать копию общей БД, которая может быть использована для

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

Запрещение установки паролей и настройки параметров запуска

пользователями. СУБД должна иметь механизмы, не позволяющие любым

пользователям устанавливать пароль на БД, иначе ее невозможно будет

открыть. Желательно иметь механизм установки запрета на изменение

параметров запуска, определяющих настраиваемые меню, панели

инструментов и стартовую форму.

При работе в многопользовательской среде большое значение

приобретает понятие пользователь базы данных - владелец определенного

набора объектов БД.

Пользователи системы могут быть разделены на классы. В системе

любого размера всегда имеются суперпользователи – пользователи, которые

автоматически имеют большинство (или все) привилегий и могут передать

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

группы привилегий. Администратор базы данных (DBA) является термином,

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

привилегий, которыми он обладает.

Других пользователей создают Администраторы баз данных. Они же

дают им начальные привилегии. Создавать пользователей могут только