|
Правила.
Правила позволяют вызывать выполнение заданных действий
при определенных изменениях базы данных. Обычно действие - это вызов
146
процедуры. Правила ассоциируются с таблицами и срабатывают при
изменении этих таблиц.
В отличие от ограничений, которые являются лишь средством контроля
относительно простых условий, правила позволяют проверять и
поддерживать сколь угодно сложные соотношения между элементами
данных в базе. Как и в случае ограничений, проверка правил отключается
при массовых операциях копирования. Администратор базы данных может
также явным образом отменить проверку правил, воспользовавшись
оператором
SET NORULES;
Оператор
SET RULES;
позволит затем восстановить работу механизма правил. По умолчанию
этот механизм включен.
Для удаления правил служит оператор
DROP RULE правило;
СУБД обеспечивает автоматическое удаление правил в тех случаях,
когда удаляется соответствующая таблица. Тем самым поддерживается
целостность системы таблиц и правил.
В контексте информационной безопасности важно отметить, что
создать правило, ассоциируемое с таблицей, может владелец этой таблицы,
имеющий право на выполнение соответствующей процедуры. Пользователь,
действия которого вызывают срабатывание правила, должен обладать лишь
необходимыми правами доступа к таблице. Тем самым правила неявно
расширяют привилегии пользователей. Подобные расширения нуждаются в
строгом административном контроле, поскольку даже незначительное
изменение правила или ассоциированной процедуры может кардинально
повлиять на защищенность данных. Ошибка же в сложной системе правил
вообще чревата непредсказуемыми последствиями.
147
Средства поддержания высокой готовности.
В коммерческих
приложениях высокая готовность аппаратно-программных комплексов
является важнейшим фактором. Применительно к СУБД средства
поддержания высокой готовности должны обеспечивать нейтрализацию
аппаратных отказов, особенно касающихся дисков, а также восстановление
после ошибок обслуживающего персонала или прикладных программ.
Подобные средства должны с самого начала закладываться в
архитектуру комплекса. Например, необходимо использовать тот или иной
вид избыточных дисковых массивов. Конечно, это сделает аппаратно-
программное решение более дорогим, но зато убережет от возможных
убытков во время эксплуатации.
Кластерная организация сервера баз данных.
Обычно кластер
содержит также несколько дисковых подсистем, совместно используемых
узлами-компьютерами, и избыточные связи между компонентами. С внешней
точки зрения кластер выглядит как единое целое, а наличие нескольких узлов
способствует повышению производительности и устойчивости к отказам.
Тиражирование данных.
В контексте информационной безопасности
тиражирование можно рассматривать как средство повышения доступности
данных. Стала легендой история про бакалейщика из Сан-Франциско,
который после разрушительного землетрясения восстановил свою базу
данных за 16 минут, перекачав из другого города предварительно
протиражированную информацию.
Развитые возможности тиражирования предоставляет СУБД INGRES.
В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая
в полном отображении данных с основного сервера на вторичные.
В конфигурации серверов Informix OnLine-DS с тиражированием
выделяется один основной и ряд вторичных серверов. На основном сервере
выполняется и чтение, и обновление данных, а все изменения передаются на
вторичные серверы, доступные только на чтение (рис. 5.1). В случае отказа
основного сервера вторичный автоматически или вручную переводится в
148
режим доступа на чтение и запись (рис. 5.2). Прозрачное перенаправление
клиентов при отказе основного сервера не поддерживается, но оно может
быть реализовано в рамках приложений.
После восстановления основного сервера возможен сценарий, при
котором этот сервер становится вторичным, а бывшему вторичному, который
уже функционирует в режиме чтения-записи, придается статус основного;
клиенты, которые подключены к нему, продолжают работу. Таким образом,
обеспечивается непрерывная доступность данных.
Тиражирование осуществляется путем передачи информации из
журнала транзакций (логического журнала) в буфер тиражирования
основного сервера, откуда она пересылается в буфер тиражирования
вторичного сервера. Такая пересылка может происходить либо в
синхронном, либо в асинхронном режиме. Синхронный режим гарантирует
полную согласованность баз данных - ни одна транзакция, зафиксированная
на основном сервере, не останется незафиксированной на вторичном, даже в
случае сбоя основного сервера. Асинхронный режим не обеспечивает
абсолютной согласованности, но улучшает рабочие характеристики системы.
Побочный положительный эффект тиражирования - возможность
вынести преимущественно на вторичный сервер ресурсоемкие приложения
поддержки принятия решений. В этом случае они могут выполняться с
максимальным использованием средств параллельной обработки, не
подавляя приложений оперативной обработки транзакций, сосредоточенных
на основном сервере. Это также можно рассматривать как фактор повышения
доступности данных.
Защита коммуникаций между сервером и клиентами.
Проблема
защиты коммуникаций между сервером и клиентами не является
специфичной для СУБД, она присуща всем распределенным системам.
Вполне естественно, что и решения здесь ищутся общие, такие, например,
как в распределенной вычислительной среде (Distributed Computing
Environment, DCE) концерна OSF. Разработчикам СУБД остается
149
«погрузить» свои программные продукты в эту среду, что и сделала
компания Informix, реализовав Informix- DCE/Net.
Тиражирование
Основной
сервер
Вторичный
сервер
Рис. 5.1. Тиражирование. Основной сервер доступен на чтение и запись,
вторичный - только на чтение
Do'stlaringiz bilan baham: | 
