Некоторые аспекты обеспечения эффективности работы системы управления базами данных


Содержание

Некоторые аспекты обеспечения эффективности работы системы управления базами данных

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

Качество работы складывается как из аппаратного уровня, так и из программного уровня оснащения. Одним из способов обеспечения эффективности работы СУБД является оснащение ее профессиональной системой мониторинга.

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

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

Исследования проведенные над возможными структурами систем мониторинга инстанций СУБД определили на сегодняшний день представленную на рисунке 1 блок-схему.

Рассмотрим необходимые структурные компоненты и связи, приминительно к СУБД Oracle.

Дисковый массив (компонент физического уровня) Oracle:

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

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

архив логов (archive log) — точная копия файлов журналирования операций.

Фоновыепроцессы (background processes) Oracle:

драйвер записи данных в БД (Database writer) — запись измененных (грязных) блоков из блоков буферов БД на диск. Когда транзакция изменяет информацию в блоке данных, этот блок данных не обязан быть немедленно записан на диск. Значит можно записывать данные на диск способом более эффективным, чем запись всех изменений по отдельности. Обычно записываются данные тогда, когда они уже нужны для чтения. Записываются также те данные, которые были недавно использованы. Для систем с асинхронным вводом-выводом достаточно одного процесса. Для остальных можно значительно увеличить производительность, создав несколько процессов;

драйвер записи логов (redo log writer) — записывает данные из журнального буфера в журнал изменений;

драйвер архивирующего устройства (archiver) — копирует файлы журнала изменений при их заполнении. Он активен лишь в том случае, если СУБРД работает в режиме ARCHIVELOG.

Системная глобальная область (system global are или SGA) — это область разделяемой памяти, которую Oracle использует для хранения данных и управляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске инстанции Oracle и освобождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA. Составляющие SGA (каждый из которых создается в памяти при запуске инстанции):

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

буфер журнала изменений — хранит данные об изменениях БД. Буфер журнала изменений записывается в файл журнала изменений настолько быстро и эффективно насколько это возможно;

разделяемый пул — это область SGA, в которой хранятся такие структуры разделяемой памяти, как разделяемые SQL-области в библиотечном кэше и внутренняя информация словаря данных. Недостаточный объем разделяемого пула может привести к деградации производительности всей системы. Он состоит из библиотечного кэша и кэша словаря данных. Библиотечный кэш представляет собой область памяти, где сохраняются все операторы SQL и PL/SQL. Процессор БД понимает только команды SQL. Независимо от того, какие средства применяются для обеспечения взаимодействия пользователя с БД, лишь операторы SQL посылаются программному обеспечению для обработки.

Серверные процессы — это механизмы выполнения программного кода. Несколько процессов могут работать одновременно. СУБД работает с двумя видами процессов: пользовательские процессы и процессы Oracle.

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

диспетчеры (dispatcher) — процесс, ответственный за каждый протокол связи. Они организуют взаимодействие между пользовательскими и разделяемыми серверными процессами.

SQL*Net — это клиентские сетевые компоненты и административные утилиты.

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

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

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

Производительность всей системы в целом зависит от функционирования кэш-буфера БД, он состоит из блоков памяти того же размера, что и блоки Oracle. Все данные загружаются в кэш-буфер. В них же выполняется и любое обновление данных, поэтому очень важно правильно устанавливать размер буфера. Oracle переносит данные на диск (используется подкачку swap-данных) в соответствии с порядком их размещения в списке LRU (least recently used — наиболее давно использовавшиеся). Этот список отслеживает обращение к блокам данных и учитывает частоту обращения к ним. Когда выполняется обращение к блоку данных, хранящемуся в кэш-буфере, он помещается в тот конец списка — MRU (most recently used — недавно использованные). При этом, если серверу требуется место в кэш-буфере для загрузки нового блока с диска он обращается к списку LRU и решает какой из блоков перенести на диск, для того чтобы освободить место для нового блока. У блоков наиболее удаленных в списке от MRU самая большая вероятность удаления из кэш-буфера. Дольше всего остаются в кэш-буфере те блоки, обращение к которым производится наиболее часто. Анализ функционирования кэш-буфера выявил следующую блок-схему его работы.

Таблица X$BH содержит информацию о блоках в кэш-буфере. В ней можно увидеть, как «счетчик обращений» увеличивается при каждом обращении к блоку. Сначала находится блок. Используем блок таблицы DUAL — специальной таблицы, состоящей из одной строки и одного столбца (присутствует во всех БД Oracle). Найдем соответствующий номер файла и номер блока в файле:

select file_id, block_id

where segment_name = ‘DUAL’ and owner = ‘SYS’;

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

select tch from x$bh where file#=1 and dbablk=870;

Некоторые аспекты обеспечения эффективности работы системы управления базами данных — авторский материал

Категория: авторский материал
Рубрика: Информатика, программирование
Размер файла: 9 Kb
Количество загрузок:
Количество просмотров:
Описание работы: авторский материал на тему Некоторые аспекты обеспечения эффективности работы системы управления базами данных
Смотреть
Скачать

Некоторые аспекты обеспечения эффективности работы системы управления базами данных

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

Качество работы складывается как из аппаратного уровня, так и из программного уровня оснащения. Одним из способов обеспечения эффективности работы СУБД является оснащение ее профессиональной системой мониторинга.

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

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

Исследования проведенные над возможными структурами систем мониторинга инстанций СУБД определили на сегодняшний день представленную на рисунке 1 блок-схему.

Рассмотрим необходимые структурные компоненты и связи, приминительно к СУБД Oracle.

Дисковый массив (компонент физического уровня) Oracle:

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

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

архив логов (archive log) — точная копия файлов журналирования операций.

Фоновые процессы (background processes) Oracle:

драйвер записи данных в БД (Database writer) — запись измененных (грязных) блоков из блоков буферов БД на диск. Когда транзакция изменяет информацию в блоке данных, этот блок данных не обязан быть немедленно записан на диск. Значит можно записывать данные на диск способом более эффективным, чем запись всех изменений по отдельности. Обычно записываются данные тогда, когда они уже нужны для чтения. Записываются также те данные, которые были недавно использованы. Для систем с асинхронным вводом-выводом достаточно одного процесса. Для остальных можно значительно увеличить производительность, создав несколько процессов;

драйвер записи логов (redo log writer) — записывает данные из журнального буфера в журнал изменений;

драйвер архивирующего устройства (archiver) — копирует файлы журнала изменений при их заполнении. Он активен лишь в том случае, если СУБРД работает в режиме ARCHIVELOG.

Системная глобальная область (system global are или SGA) — это область разделяемой памяти, которую Oracle использует для хранения данных и управляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске инстанции Oracle и освобождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA. Составляющие SGA (каждый из которых создается в памяти при запуске инстанции):

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

буфер журнала изменений — хранит данные об изменениях БД. Буфер журнала изменений записывается в файл журнала изменений настолько быстро и эффективно насколько это возможно;

разделяемый пул — это область SGA, в которой хранятся такие структуры разделяемой памяти, как разделяемые SQL-области в библиотечном кэше и внутренняя информация словаря данных. Недостаточный объем разделяемого пула может привести к деградации производительности всей системы. Он состоит из библиотечного кэша и кэша словаря данных. Библиотечный кэш представляет собой область памяти, где сохраняются все операторы SQL и PL/SQL. Процессор БД понимает только команды SQL. Независимо от того, какие средства применяются для обеспечения взаимодействия пользователя с БД, лишь операторы SQL посылаются программному обеспечению для обработки.

Серверные процессы — это механизмы выполнения программного кода. Несколько процессов могут работать одновременно. СУБД работает с двумя видами процессов: пользовательские процессы и процессы Oracle.

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

диспетчеры (dispatcher) — процесс, ответственный за каждый протокол связи. Они организуют взаимодействие между пользовательскими и разделяемыми серверными процессами.

SQL*Net — это клиентские сетевые компоненты и административные утилиты.

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

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

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

Производительность всей системы в целом зависит от функционирования кэш-буфера БД, он состоит из блоков памяти того же размера, что и блоки Oracle. Все данные загружаются в кэш-буфер. В них же выполняется и любое обновление данных, поэтому очень важно правильно устанавливать размер буфера. Oracle переносит данные на диск (используется подкачку swap-данных) в соответствии с порядком их размещения в списке LRU (least recently used — наиболее давно использовавшиеся). Этот список отслеживает обращение к блокам данных и учитывает частоту обращения к ним. Когда выполняется обращение к блоку данных, хранящемуся в кэш-буфере, он помещается в тот конец списка — MRU (most recently used — недавно использованные). При этом, если серверу требуется место в кэш-буфере для загрузки нового блока с диска он обращается к списку LRU и решает какой из блоков перенести на диск, для того чтобы освободить место для нового блока. У блоков наиболее удаленных в списке от MRU самая большая вероятность удаления из кэш-буфера. Дольше всего остаются в кэш-буфере те блоки, обращение к которым производится наиболее часто. Анализ функционирования кэш-буфера выявил следующую блок-схему его работы.

Таблица X$BH содержит информацию о блоках в кэш-буфере. В ней можно увидеть, как «счетчик обращений» увеличивается при каждом обращении к блоку. Сначала находится блок. Используем блок таблицы DUAL — специальной таблицы, состоящей из одной строки и одного столбца (присутствует во всех БД Oracle). Найдем соответствующий номер файла и номер блока в файле:

select file_id, block_id

where segment_name = «DUAL» and owner = «SYS»;

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

select tch from x$bh where file#=1 and dbablk=870;

Некоторые аспекты обеспечения эффективности работы системы управления базами данных

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

Базы данных и системы управления базами данных
Устройства внешней памяти. Система управления базами данных. Создание, ведение и совместное использование баз данных многими пользователями. Понятие с.

Разработка, внедрение и адаптация программного обеспечения отраслевой направленности
Практические аспекты использования прикладного программного обеспечения при разработке базы данных «Аудиторный фонд ГБОУ СПО «Старооскольский педагоги.

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

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

Основные аспекты безопасности СУБД: что следует знать

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

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

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

История развития СУБД

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

Можно выделить следующие архитектурные подходы:

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

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

Nice, Санкт-Петербург, от 150 000 ₽

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

Современные проблемы обеспечения безопасности БД

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

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

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

Применение различных средств обеспечения информационной безо­пасности является для организации компромиссом в финансовом плане: внедрение более защищенных продуктов и подбор более квалифицированного персонала требуют больших затрат. Компоненты безопасности зачастую могут негативно влиять на производительность СУБД.

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

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

Особенности защиты БД

Хранилища данных включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).

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

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

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

Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, и наличие в нем тех или иных уязвимостей. Причем такие уязвимости, например, как инъекция, выполняются по-разному (sql-инъекция, java-инъек­ция) в зависимости от синтаксиса языка.

Требования к безопасности БД

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

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

  • Функционирование в доверенной среде.

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

  • Организация физической безопасности файлов данных.

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

  • Организация безопасной и актуальной настройки СУБД.

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

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

  • Безопасность пользовательского ПО.

Сюда можно отнести задачи построения безопасных интерфейсов и механизмов доступа к данным.

  • Безопасная организация и работа с данными.

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

Основные аспекты создания защищенных БД

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

  • Разработка комплексных методик обеспечения безопасности хранилищ данных на предприятии.

Создание комплексных методик позволит применять их при разработке и внедрении хранилищ данных и пользовательского ПО. Следование комплексной методике позволит избежать многих ошибок управления СУБД и защититься от наиболее распространенных на сегодняшний день уязвимостей.

  • Оценка и классификация угроз и уязвимостей СУБД.

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

  • Разработка стандартных механизмов обеспечения безопасности.

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

Об авторе

Максим Советкин окончил механико-математический факультет Белорусского государственного университета, работает в Itransition уже более семи лет. Сегодня он — ведущий системный инженер, отвечает за проектирование, развитие и поддержку корпоративной ИТ-инфраструктуры.

Некоторые аспекты обеспечения эффективности работы системы управления базами данных

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

Качество работы складывается как из аппаратного уровня, так и из программного уровня оснащения. Одним из способов обеспечения эффективности работы СУБД является оснащение ее профессиональной системой мониторинга.

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

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

Исследования проведенные над возможными структурами систем мониторинга инстанций СУБД определили на сегодняшний день представленную на рисунке 1 блок-схему.

Рассмотрим необходимые структурные компоненты и связи, приминительно к СУБД Oracle.

Дисковый массив (компонент физического уровня) Oracle:

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

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

архив логов (archive log) — точная копия файлов журналирования операций.

Фоновыепроцессы (background processes) Oracle:

драйвер записи данных в БД (Database writer) — запись измененных (грязных) блоков из блоков буферов БД на диск. Когда транзакция изменяет информацию в блоке данных, этот блок данных не обязан быть немедленно записан на диск. Значит можно записывать данные на диск способом более эффективным, чем запись всех изменений по отдельности. Обычно записываются данные тогда, когда они уже нужны для чтения. Записываются также те данные, которые были недавно использованы. Для систем с асинхронным вводом-выводом достаточно одного процесса. Для остальных можно значительно увеличить производительность, создав несколько процессов;

драйвер записи логов (redo log writer) — записывает данные из журнального буфера в журнал изменений;

драйвер архивирующего устройства (archiver) — копирует файлы журнала изменений при их заполнении. Он активен лишь в том случае, если СУБРД работает в режиме ARCHIVELOG.

Системная глобальная область (system global are или SGA) — это область разделяемой памяти, которую Oracle использует для хранения данных и управляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске инстанции Oracle и освобождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA. Составляющие SGA (каждый из которых создается в памяти при запуске инстанции):

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

буфер журнала изменений — хранит данные об изменениях БД. Буфер журнала изменений записывается в файл журнала изменений настолько быстро и эффективно насколько это возможно;

разделяемый пул — это область SGA, в которой хранятся такие структуры разделяемой памяти, как разделяемые SQL-области в библиотечном кэше и внутренняя информация словаря данных. Недостаточный объем разделяемого пула может привести к деградации производительности всей системы. Он состоит из библиотечного кэша и кэша словаря данных. Библиотечный кэш представляет собой область памяти, где сохраняются все операторы SQL и PL/SQL. Процессор БД понимает только команды SQL. Независимо от того, какие средства применяются для обеспечения взаимодействия пользователя с БД, лишь операторы SQL посылаются программному обеспечению для обработки.

Серверные процессы — это механизмы выполнения программного кода. Несколько процессов могут работать одновременно. СУБД работает с двумя видами процессов: пользовательские процессы и процессы Oracle.

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

диспетчеры (dispatcher) — процесс, ответственный за каждый протокол связи. Они организуют взаимодействие между пользовательскими и разделяемыми серверными процессами.

SQL*Net — это клиентские сетевые компоненты и административные утилиты.


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

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

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

Производительность всей системы в целом зависит от функционирования кэш-буфера БД, он состоит из блоков памяти того же размера, что и блоки Oracle. Все данные загружаются в кэш-буфер. В них же выполняется и любое обновление данных, поэтому очень важно правильно устанавливать размер буфера. Oracle переносит данные на диск (используется подкачку swap-данных) в соответствии с порядком их размещения в списке LRU (least recently used — наиболее давно использовавшиеся). Этот список отслеживает обращение к блокам данных и учитывает частоту обращения к ним. Когда выполняется обращение к блоку данных, хранящемуся в кэш-буфере, он помещается в тот конец списка — MRU (most recently used — недавно использованные). При этом, если серверу требуется место в кэш-буфере для загрузки нового блока с диска он обращается к списку LRU и решает какой из блоков перенести на диск, для того чтобы освободить место для нового блока. У блоков наиболее удаленных в списке от MRU самая большая вероятность удаления из кэш-буфера. Дольше всего остаются в кэш-буфере те блоки, обращение к которым производится наиболее часто. Анализ функционирования кэш-буфера выявил следующую блок-схему его работы.

Таблица X$BH содержит информацию о блоках в кэш-буфере. В ней можно увидеть, как «счетчик обращений» увеличивается при каждом обращении к блоку. Сначала находится блок. Используем блок таблицы DUAL — специальной таблицы, состоящей из одной строки и одного столбца (присутствует во всех БД Oracle). Найдем соответствующий номер файла и номер блока в файле:

Системы управления базами данных

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

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

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

Классификация СУБД.

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

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

— средства разработки программ работы с БД.

Полнофункциональные СУБД (ПФСУБД) представляют собой традиционные СУБД, которые сначала появились для больших машин, затем для мини-машин и для ПЭВМ. Из числа всех СУБД современные ПФСУБД являются наиболее многочисленными и мощными по своим возможностям. К ПФСУБД относятся, например, такие пакеты как: Clarion Database Developer, DataBase, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro и Paradox R: BASE.

Обычно ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. п. Для создания запросов и отчетов не обязательно программирование, а удобно пользоваться языком QBE (Query By Example — формулировки запросов по образцу, см. подраздел 3.8). Многие ПФСУБД включают средства программирования для профессиональных разработчиков.

Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД или CASE-подсистемы. Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные СУБД имеют факультативные модули.

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

Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress).

В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т. д. При этом элементы пары «клиент — сервер» могут принадлежать одному или разным производителям программного обеспечения.

В случае, когда клиентская и серверная части выполнены одной фирмой, естественно ожидать, что распределение функций между ними выполнено рационально. В остальных случаях обычно преследуется цель обеспечения доступа к данным «любой ценой». Примером такого соединения является случай, когда одна из полнофункциональных СУБД играет роль сервера, а вторая СУБД (другого производителя) — роль клиента. Так, для сервера БД SQL Server (Microsoft) в роли клиентских (фронтальных) программ могут выступать многие СУБД, такие как: dBASE IV, Biyth Software, Paradox, DataEase, Focus, 1-2-3, MDBS III, Revelation и другие.

Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ:

— серверов БД и их отдельных компонентов;

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

К средствам разработки пользовательских приложений относятся системы программирования, например Clipper, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок (в том числе систем типа клиент-сервер). В числе наиболее распространенных можно назвать следующие инструментальные системы: Delphi и Power Builder (Borland), Visual Basic (Microsoft), SILVERRUN (Computer Advisers Inc.), S-Designor (SDP и Powersoft) и ERwin (LogicWorks).

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

По характеру использования СУБД делят на персональные и многопользовательские.
Персональные СУ БД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др

Илон Маск рекомендует:  Просмотр ZIP-архива

Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.

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

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

Для работы с хранящейся в базе данных информацией СУБД предоставляет программам и пользователям следующие два типа языков :

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

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

Названные языки в различных СУБД могут иметь отличия. Наибольшее распространение получили два стандартизованных языка: QBE (Query By Example) — язык запросов по образцу и SQL (Structured Query Language) — структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов — описания и манипулирования данными.

Перечисленные выше функции СУБД, в свою очередь, используют следующие основные функции более низкого уровня, которые назовем низкоуровневыми:

— управление данными во внешней памяти;

— управление буферами оперативной памяти;

— ведение журнала изменений в БД;

— обеспечение целостности и безопасности БД. Дадим краткую характеристику необходимости и особенностям реализации перечисленных функций в современных СУБД.

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

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

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

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

Говорят, что транзакции присущи три основных свойства:

— атомарность (выполняются все входящие в транзакцию операции или ни одна);

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

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

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

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

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

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

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

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

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

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

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

База данных (БД) – совокупность специально организованных и логически упорядоченных данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

Прежде всего рассмотрим три главных элемента пользовательского интерфейса MS Access 2010 (МА 2010).

  • Лента. Область вверху окна приложения, которая содержит группы команд.
  • Представление Backstage. Перечень команд на вкладке Файл, которая помещается на ленте.
  • Область навигации. Область в левой части окна МА 2010, созданная для работы с объектами базы данных. Область навигации заменила собой окно базы данных в Access 2007.

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

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

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

Режим Backstage является новинкой, созданной в МА 2010. Этот режим включает команды и сведения, которые можно применить ко всей базе данных, например Сжать и восстановить, и команды, которые в более ранних версиях МА находились в меню Файл, например Печать.

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

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

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

Рис. 3.24. Представление Backstage

Backstage предназначен для создания и открытия баз данных, публикации их в Интернете на сервере SharePoint Server и выполнения многих других задач, в том числе обслуживания файлов и баз данных.

Создание пустой базы данных. Для того чтобы создать новую базу данных, нужно сделать следующее.

  • 1. Активировать МА при помощи меню Пуск или с использованием ярлыка. Запустится представление Backstage.
  • 2. Запустить одну из приведенных ниже процедур.
  • а) Создание веб-базы данных:
    • – в группе Доступные шаблоны выбрать пункт Пустая веб-база данных;
    • – справа в разделе Пустая веб-база данных в поле Имя файла набрать наименование файла базы данных или воспользоваться наименованием по умолчанию;
    • – щелкнуть кнопку Создать.

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

  • б) Создание базы данных на компьютере:
    • – в группе Доступные шаблоны нажать пункт Пустая база данных;
    • – справа в разделе Пустая база данных в поле Имя файла набрать наименование файла базы данных или воспользоваться наименованием по умолчанию;
    • – нажать кнопку Создать.

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

МЛ 2010 включает перечень шаблонов, к тому же существует возможность загрузки дополнительных шаблонов с веб-сайта Office.com. Шаблон МА является готовой базой данных с таблицами, разработанными на профессиональном уровне, а также содержащей формы и отчеты. Шаблоны дают возможность сократить время прохождения начальных этапов создания базы данных.

Создание базы данных из образца шаблона. Для осуществления этого необходимо сделать следующее.

  • 1. Активировать МА 2010 при помощи меню Пуск или воспользовавшись ярлыком. Запустится представление Backstage.
  • 2. Нажать пункт Образец шаблона и просмотреть перечень доступных шаблонов.
  • 3. Выбрать нужный шаблон.
  • 4. Справа в окне «Имя файла» набрать наименование файла или воспользоваться наименованием по умолчанию.
  • 5. Щелкнуть кнопку Создать.

Приложение МА 2010 на основе выбранного шаблона создаст новую базу данных и откроет ее.

Существует возможность загрузить дополнительные шаблоны МА 2010 с веб-сайта Office.com через представление Backstage.

Создание базы данных из шаблона Office.com. Для осуществления этого действия нужно сделать следующее.

  • 1. Активировать МА 2010 при помощи меню Пуск или с использованием ярлыка. Запустится представление Backstage.
  • 2. На панели Шаблоны Office.com отметить категорию и необходимый шаблон. Нужный шаблон можно найти также с помощью окна поиска.
  • 3. В поле Имя файла набрать наименование файла или использовать наименование по умолчанию.
  • 4. Щелкнуть кнопку Загрузить.

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

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

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

  • 1. Активировать МА 2010.
  • 2. В представлении Backstage нажать пункт Недавние и выбрать базу данных, которую требуется открыть. Приложение МА откроет базу данных.

Открытие базы данных из представления Backstage. Для осуществления этого действия нужно сделать следующее.

  • 1. Активировать М А 2010.
  • 2. На вкладке Файл щелкнуть кнопку Открыть. В диалоговом окне Открытие отметить файл и щелкнуть кнопку Открыть. Откроется база данных.

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

Когда база данных открывается, лента отображается вверху главного окна МА 2010. В этот момент она включает команды активной вкладки команд (рис. 3.25).

Рис. 3.25. Лента МА 2010

Лента включает перечень вкладок с командами. В МА 2010 главные вкладки команд – Файл, Главная, Создание, Внешние данные и Работа с базами данных. Любая вкладка включает группу взаимосвязанных команд, которые, в свою очередь, открывают другие новые компоненты интерфейса, например коллекцию – совершенно новый элемент управления, который позволяет наглядно выбирать варианты управления.

Команды ленты должны соответствовать объекту, который в настоящее время активен. Например, если открыть таблицу в режиме таблицы и щелкнуть по кнопке Форма на вкладке Создание в группе Формы, приложение МА 2010 создаст форму на основе активной таблицы. Таким образом, наименование активной таблицы будет указано в свойстве формы RecordSource (источник записей). Необходимо учитывать, что определенные вкладки ленты отображаются исключительно в соответствующем контексте. Например, вкладка Конструктор отображается исключительно в момент открытия объекта в режиме конструктора.

Работа с лентой может быть удобна при использовании некоторых комбинаций клавиш. При этом все комбинации клавиш из предшествующей версии МА действуют по-прежнему. Однако вместо клавиш активации меню, которые применялись в предыдущих версиях МА, действует система доступа к элементам управления с клавиатуры. Эта система использует специальные индикаторы с одной или несколькими буквами, появляющиеся на ленте при нажатии клавиши ALT. Данные индикаторы указывают на клавиши, которые соответствуют элементам управления.

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

Выбор вкладки с командами. Чтобы осуществить это действие, необходимо выполнить следующее.

  • 1. Активировать МА 2010.
  • 2. Выбрать требуемую вкладку.
  • 1. Активировать МА 2010.
  • 2. Нажать и отпустить клавишу ALT. После этого отобразятся подсказки по доступу с клавиатуры.
  • 3. Щелкнуть клавишу или клавиши, которые указаны в подсказке возле требуемой вкладки.

Существует несколько вариантов исполнения команд. Самый простой из них – это использование комбинаций клавиш, которые связаны с командами. Комбинациями клавиш из предшествующей версии МА можно воспользоваться и в МА 2010.

  • 1) активировать МА 2010;
  • 2) выбрать вкладку с требуемой командой;
  • 3) нажать элемент управления, который соответствует команде. Если комбинация клавиш для данной команды уже известна из предшествующей версии МА, нажмите ее;
  • 1) нажать и отпустить клавишу ALT. Отобразятся подсказки по доступу с клавиатуры;
  • 2) щелкнуть клавишу или клавиши, которые указаны в подсказке, связанной с требуемой командой.

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

Вкладки и команды Access 2010

Выбор другого представления

Копирование и вставка данных из буфера обмена

Задание свойств текущего шрифта

Установка текущего выравнивания шрифта

Применение форматирования к полю MEMO

Работа с записями (обновление, создание, сохранение, удаление, итоги, орфография, дополнительно)

Сортировка и фильтрация записей

Создание пустой таблицы

Создание таблицы на основе шаблона

Создание списка на сайте SharePoint, а также связанной с этим списком таблицы в текущей базе данных

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

Создание формы на основе активной таблицы или запроса

Создание сводной таблицы или диаграммы

Создание отчета на основе активной таблицы или запроса

Создание запроса, макроса, модуля или модуля класса

Импорт или связывание внешних данных

Сбор и обновление данных по электронной почте

Создание сохраненных операций импорта и экспорта

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

Работа с базами данных

Перенос некоторых или всех частей базы данных на новый или существующий сайт SharePoint

Запуск редактора Visual Basic или выполнение макроса

Создание и просмотр отношений между таблицами


Показ или скрытие зависимостей объектов

Запуск архивариуса или анализ производительности

Перемещение данных в Microsoft SQL Server или базу данных Access (только таблицы)

Управление надстройками Access

Создание или изменение модуля VBA

Контекстные вкладки команд. Кроме обычных вкладок команд в МА 2010 появились также контекстные вкладки (рис. 3.26). В соответствии с контекстом (т.е. с тем, каким объектом пользователь занят в данный момент и какие именно действия он исполняет) рядом с обычными вкладками команд могут отображаться контекстные вкладки.

Рис. 3.26. Контекстные вкладки команд

Для активации контекстной вкладки с командами нужно сделать следующее:

• нажать контекстную вкладку;

  • • нажать и отпустить клавишу ALT. Отобразятся подсказки по доступу с клавиатуры;
  • • щелкнуть клавишу или клавиши, которые указаны в подсказке около контекстной вкладки.

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

Коллекции. Кроме всего прочего на ленте находится элемент управления, который получил название Коллекция. Этот элемент был создан для привлечения внимания к требуемым результатам. Коллекция – это элемент управления, который не только показывает команды, но еще и отображает результат исполнения этих команд (рис. 3.27). Главная цель создания этого элемента состоит в том, чтобы дать пользователю возможность найти и выбрать необходимые действия в МА 2010 по виду, сосредоточившись на результате, а не на самих командах.

Рис. 3.27. Коллекции МА 2010

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

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

Скрытие и восстановление ленты. Для осуществления этого действия нужно выполнить следующее.

  • 1. Дважды щелкнуть выделенную вкладку команд.
  • 2. Чтобы восстановить ленту, опять дважды щелкнуть текущую вкладку команд.

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

Настройка панели быстрого доступа. Для осуществления этого действия нужно выполнить следующее.

  • 1. Нажать стрелку отображения списка в правой части панели.
  • 2. В разделе Настройка панели быстрого доступа отметить команду, которую нужно добавить.

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

  • 3. В диалоговом окне Параметры Access выбрать команду или команды, которые необходимо добавить, и щелкнуть кнопку Добавить.
  • 4. Чтобы удалить команду, необходимо выделить ее в перечне команд, который находится справа, и щелкнуть кнопку Удалить. Кроме того, существует возможность просто дважды щелкнуть команду в перечне.
  • 5. Когда действия по удалению команды завершены, щелкнуть кнопку ОК.

Область навигации. Когда открываются уже существующие или вновь созданные базы данных, наименования объектов базы данных отображаются в области навигации (рис. 3.28). К объектам базы данных можно отнести таблицы, формы, отчеты, страницы, макросы и модули. Область навигации по сути выполняет функции окна базы данных, которое присутствовало в предыдущих версиях МА, т.е. если в предыдущих версиях программы для запуска и выполнения задач служило окно базы данных, то в МА 2010 для этого используется область навигации. Например, для добавления строки в таблицу в режиме таблицы необходимо открыть таблицу из области навигации. В веб-браузерах область навигации обычно недоступна. Для того чтобы воспользоваться ей в веб-базе данных, сначала необходимо открыть базу данных в Access.

Рис. 3.28. Область навигации

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

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

• дважды нажать объект в области навигации;

• отметить объект в области навигации и щелкнуть клавишу ВВОД;

• в области навигации отметить объект ПКМ и выбрать в контекстном меню команду Открыть.

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

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

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

Отображение и скрытие области навигации. Для осуществления этого действия нужно выполнить следующее:

• щелкнуть кнопку в правом верхнем углу области навигации или клавишу F11.

Для отмены отображения области навигации по умолчанию

нужно выполнить следующее:

  • – на вкладке Файл выбрать пункт Параметры. Отобразиться диалоговое окно Параметры Access;
  • – в левой области отметить пункт Текущая база данных; в разделе Переходы убрать флажок Область переходов и щелкнуть кнопку ОК.

Вкладки документов. Начиная с Access 2007, для отражения объектов базы данных в программе появилась возможность пользоваться вкладками документов, а не перекрывающимися окнами (рис. 3.29). Это более удобный инструмент. Отображение и скрытие вкладок документов можно настроить при помощи параметров МА 2010. Если пользователь изменяет эти параметры, нужно закрыть и снова открыть базу данных, тогда изменения войдут в силу.

Рис. 3.29. Вкладки документов

Отображение и скрытие вкладок документов. Для осуществления этого действия нужно выполнить следующее.

  • 1. На вкладке Файл щелкнуть кнопку Параметры. Отобразится диалоговое окно Параметры Access.
  • 2. В левой области отметить элемент Текущая база данных.
  • 3. В разделе Параметры приложения в группе Параметры окна документа установить переключатель в положение Вкладки.
  • 4. Установить или убрать флажок Вкладки документов. Если флажка нет, вкладки документов отключены.
  • 5. Щелкнуть кнопку ОК.

Параметр Вкладки документов является индивидуальным, т.е. его нужно изменять отдельно для каждой базы данных. Если пользователь изменяет параметр Вкладки документов, то нужно закрыть и снова открыть базу данных, тогда изменения вступят в силу. Базы данных, созданные с помощью МА 2007 или МА 2010, показывают вкладки документов по умолчанию. В базах данных, созданных в предшествующих версиях МА, по умолчанию используются перекрывающиеся окна.

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

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

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

Отображение и скрытие строки состояния. Для осуществления этого действия нужно выполнить следующее.

  • 1. На вкладке Файл найти пункт Параметры. Отобразится диалоговое окно Параметры Access.
  • 2. Слева отметить пункт Текущая база данных.
  • 3. В разделе Параметры приложений поставить или убрать флажок Строка состояния. Если флажка нет, то строка состояния не отображается.
  • 4. Щелкнуть кнопку ОК.

Мини-панель инструментов. Для форматирования текста в версиях МА, которые были выпущены до МА 2007, обычно использовались меню или панель инструментов Форматирование. В МА 2010 форматировать текст стало удобнее, так как была создана мини-панель инструментов (рис. 3.30). Если выделить текст с целью форматирования, над ним автоматически появится минипанель инструментов. При движении указателя мыши по направлению к мини-панели она становится более четкой, и тогда ее можно применить для изменения начертания, размера и цвета шрифта и т.д. Когда курсор мыши удаляется, мини-панель инструментов постепенно исчезает, т.е. если в мини-панели инструментов нет необходимости, она исчезает.

Рис. 3.30. Мини-панель инструментов

Форматирование текста с помощью мини-панели инструментов.

  • 1. Отметить текст, который предназначен для форматирования. Над отмеченным текстом отобразится прозрачная мини-панель инструментов.
  • 2. Воспользоваться мини-панелью инструментов для форматирования.

Получение справочных сведений. Если необходимо прояснить какие-то вопросы, нужно вызвать справку, нажав клавишу F1 или щелкнув вопросительный знак в правой части ленты (рис. 3.31).

Рис. 3.31. Получение справочных сведений

Кроме того, справочные сведения находятся в представлении Backstage. На вкладке Файл необходимо щелкнуть кнопку Справка. Перечень источников справочных сведений отобразится в представлении Backstage.

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

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

Н.И. Вьюкова, В.А. Галатенко
АО «Инфосистемы Джет», тел. (095) 972 -1182

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

Для СУБД важны все три основных аспекта информационной безопасности — конфиденциальность, целостность и доступность [6]. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в «Критериях оценки надежных компьютерных систем». В принципе некоторые СУБД, например INGRES, предлагают дополнения, характерные для класса B1, однако практическое применение подобных дополнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные версии отстают по содержательным возможностям от обычных «собратьев», так что поборники секретности по сути обречены на использование морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения.

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

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

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

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

Предполагается, что читатель знаком с основными понятиями СУБД. Их превосходное изложение можно найти в [1]. Там же подробно рассматриваются средства поддержания целостности данных: транзакции, правила, события. По этой причине мы затронем лишь некоторые аспекты контроля целостности.

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

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

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

Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.

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

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

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

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

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

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

Управление доступом в СУБД INGRES


Основные понятия

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

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

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

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

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

Нетрудно усмотреть аналогию между ролью и таким средством ОС UNIX, как программы с битом переустановки действующего идентификатора пользователя. В обоих случаях пользователь на время получает привилегии, которыми он, вообще говоря, не обладает, но эти привилегии используются строго контролируемым образом. Роли позволяют реализовать «содержательные» привилегии, то есть привилегии, характер которых определяется не реляционной моделью или реализацией сервера баз данных, а функциональными возможностями прикладной системы.

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

Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC — удобный способ задать подразумеваемые права доступа.

Основные категории пользователей СУБД INGRES

Пользователей СУБД INGRES можно разбить на три категории:

  • администратор сервера баз данных . Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи;
  • администраторы базы данных . К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за ее сохранение и восстановление. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию creatdb;
  • прочие (конечные) пользователи . Они оперируют данными, хранящимися в базах, в рамках выделенных им привилегий.

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

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

Можно провести аналогию между пользователем ingres и администраторами баз данных, с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.), с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно также информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.

Виды привилегий в СУБД INGRES

Привилегии в СУБД INGRES можно подразделить на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия. Привилегии доступа, в соответствии с названием, определяют права доступа субъектов к определенным объектам.

Привилегии безопасности

Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять:

  • security — право управлять безопасностью СУБД и отслеживать действия пользователей. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права на доступ к базам данным другим пользователям, управлять записью регистрационной информации, отслеживать запросы других пользователей и, наконец, запускать INGRES-команды от имени других пользователей. Привилегия security необходима администратору сервера баз данных, а также лицу, персонально отвечающему за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциально слабых мест в защите сервера баз данных;
  • createdb — право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных;
  • operator — право на выполнение действий, которые традиционно относят к компетенции оператора. Имеются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо администраторов сервера и баз данных этой привилегией целесообразно наделить также администратора операционной системы;
  • maintain_locations — право на управление расположением баз данных на дисках. Этой привилегией должны обладать администраторы сервера баз данных и операционной системы;
  • trace — право на изменение состояния флагов отладочной трассировки INGRES. Данная привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.

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

Для пользователя можно определить подразумеваемую группу:

Последующее изменение привилегий безопасности для пользователя bill можно выполнять посредством оператора ALTER USER. Оператор DROP USER позволяет удалить пользователя. Примеры:

Привилегии доступа

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

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

Для изменения состава группы служит оператор ALTER GROUP:

Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы:

При создании ролей можно указать ассоциируемый с ними пароль, например:

Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE — для удаления ролей.

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

Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:

  • таблицы и представления;
  • процедуры;
  • базы данных;
  • сервер баз данных;
  • события.

Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем виде оператор GRANT имеет следующий формат:

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

SELECT — право на выборку данных;

INSERT — право на добавление данных;

DELETE — право на удаление данных;

UPDATE — право на обновление данных (можно указать определенные столбцы, разрешенные для обновления);

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

По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям — их необходимо передать с помощью операторов GRANT. Приведем несколько примеров:

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

Приведем пример предоставления права выполнения процедуры integ_check всем пользователям:

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

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

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

Параметр оператора GRANT

Предполагаемое максимальное число
операций ввода/вывода на запрос [NO]QUERY_IO_LIMIT [n] NOQUERY_IO_LIMIT
(нет ограничений) Предполагаемое максимальное число
строк, возвращаемых запросом [NO]QUERY_ROW_LIMIT [n] NOQUERY_ROW_LIMIT
(нет ограничений) Ограничение на использование
ресурсов процессора [NO]QUERY_CPU_LIMIT [n] [NO]QUERY_CPU_LIMIT
(нет ограничений) Ограничение на число
запрашиваемых страниц [NO]QUERY_PAGE_LIMIT [n] NOQUERY_PAGE_LIMIT
(нет ограничений) Управление доступом к базе данных [NO]ACCESS ACCESS для общих баз данных;
NOACCESS для личных Управление созданием таблиц [NO]CREATE_TABLE CREATE_TABLE Управление созданием процедур [NO]CREATE_PROCEDURE CREATE_PROCEDURE Управление использованием опции u
(подключение от имени другого
пользователя) [NO]DB_ADMIN DB_ADMIN для администратора
базы данных и администратора
сервера баз данных; NODB_ADMIN
для остальных пользователей

Таблица 1 .
Права доступа к базам данных и их подразумеваемые значения

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

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

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

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

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

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

Механизм событий подробно рассмотрен в [1]. Здесь мы отметим лишь, что по отношению к событиям имеются две привилегии — RAISE и REGISTER. Первая позволяет возбуждать события, вторая — регистрироваться для их получения.

Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД. Имеется в виду конструкция

Подобный оператор GRANT передает не только указанные в нем привилегии, но и права на их дальнейшую передачу. Так, оператор

дает возможность пользователю bill осуществлять выборку из таблицы employee и передавать это право другим субъектам. Очевидно, что использование конструкции WITH GRANT OPTION ведет к децентрализации контроля над привилегиями и содержит потенциальную угрозу безопасности данных.

Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит оператор REVOKE. Синтаксически он аналогичен GRANT с заменой слова TO на FROM. Например, следующий оператор

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

Получение информации о привилегиях

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

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

Таблицы iiusergroup, iirole и iidbprivileges базы данных iidbdb содержат, соответственно, список групп и их состав, перечень ролей вместе с зашифрованными паролями и сведения о привилегиях доступа к базам данных. Так, таблица iiusergroup состоит из трех столбцов:

  • groupid — имя группы;
  • groupmem — имя члена группы;
  • reserve — резервный столбец.


Средствами SQL из этих таблиц можно извлечь необходимую информацию.

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

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

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

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

Субъекты, осуществляющие доступ к представлению empview, могут пытаться запросить сведения об отделах, отличных от shoe, например:

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

Иерархия прав доступа

Оператор GRANT и другие средства управления доступом СУБД INGRES позволяют реализовать следующие виды ограничения доступа:

  • операционные ограничения (за счет прав доступа SELECT, INSERT, UPDATE, DELETE, применимых ко всем или только некоторым столбцам таблицы);
  • ограничения по значениям (за счет механизма представлений);
  • ограничения на ресурсы (за счет привилегий доступа к базам данных).

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

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

Иерархия авторизации выглядит для СУБД INGRES следующим образом:

  • роль (высший приоритет);
  • пользователь;
  • группа;
  • PUBLIC (низший приоритет).

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

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

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

Обычно используемая роль и группа задаются, соответственно, как аргументы опций -R и -G в командной строке запуска приложения. Пример:

Если опция -G отсутствует, применяется подразумеваемая группа пользователя, если таковая имеется. Наконец, если в командной строке sql задана опция -uпользователь, то в число проверяемых входят также привилегии указанного пользователя.

Соотношение прав доступа СУБД и операционной системы

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

Чтобы средствами ОС нельзя было скомпрометировать базу данных и сопутствующую информацию, например журналы транзакций, необходимо установить максимально жесткий режим доступа к соответствующим файлам и томам. Для UNIX-систем целесообразно предоставить право непосредственного доступа только пользователям root, ingres и, быть может, администраторам баз данных. Все прочие субъекты должны осуществлять доступ к базам с помощью программ со взведенным битом переустановки действующего идентификатора пользователя.

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

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

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

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

Метки безопасности и принудительный контроль доступа

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

В «Критериях оценки надежных компьютерных систем» применительно к системам уровня безопасности B описан механизм меток безопасности, реализованный в версии INGRES/ Enhanced Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл только в сочетании с операционной системой и другими программными компонентами того же уровня безопасности. Тем не менее рассмотрение реализации меточной безопасности в СУБД INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении данных по уровням секретности и категориям доступа, может оказаться полезным при проектировании системы привилегий многочисленных пользователей по отношению к большим массивам данных.

В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец, содержащий метки безопасности строк таблицы. Метка безопасности состоит из трех компонентов:

· уровень секретности . Смысл этого компонента зависит от приложения. В частности, возможен традиционный спектр уровней от «совершенно секретно» до «несекретно»;

· категории . Понятие категории позволяет разделить данные на «отсеки» и тем самым повысить надежность системы безопасности. В коммерческих приложениях категориями могут служить «финансы», «кадры», «материальные ценности» и т.п. Ниже назначение категорий разъясняется более подробно;

· области . Является дополнительным средством деления информации на отсеки. На практике компонент «область» может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.

Каждый пользователь СУБД INGRES/ Enhanced Security характеризуется степенью благонадежности, которая также определяется меткой безопасности, присвоенной данному пользователю. Пользователь может получить доступ к данным, если степень его благонадежности удовлетворяет требованиям соответствующей метки безопасности. Более точно:

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

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

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

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

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

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

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

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

Представляется естественным, что СУБД INGRES/Enhanced Security допускает не только скрытое, но и явное включение меток безопасности в реляционные таблицы. Появился новый тип данных, security label, поддерживающий соответствующие операции сравнения.

INGRES/Enhanced Security — первая СУБД, получившая сертификат, эквивалентный аттестации на класс безопасности B1. Вероятно, метки безопасности постепенно войдут в стандартный репертуар систем управления базами данных.

Поддержание целостности данных в СУБД INGRES

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

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

С точки зрения пользователя СУБД, основными средствами поддержания целостности данных являются ограничения и правила.

Ограничения

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

Здесь требуется, чтобы имя было непустым (обязательно задавалось), а значение возраста было больше 17. Так называемые ссылочные ограничения, использованные в определении столбца id, будут рассмотрены ниже.

Табличные ограничения относятся к группе столбцов и могут задаваться как при создании таблицы, так и позже, посредством оператора ALTER TABLE. Приведем пример табличного ограничения, заданного в операторе CREATE TABLE:

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

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

Приведем пример ссылочного ограничения:

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

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

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

Если требуется удалить ограничение dept_unique, можно воспользоваться следующим оператором:

Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений.

Получить информацию об ограничениях, наложенных на таблицы, можно с помощью оператора

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

Правила

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

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

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

Обратим внимание на несколько обстоятельств. Во-первых, процедура delete_children, выполняемая в результате срабатывания правила cascade_delete, вызывает рекурсивное обращение к этому правилу и, следовательно, к самой себе. Во-вторых, таблица person также является в некотором смысле рекурсивной, поскольку столбец parent представляет собой ссылку на столбец name. Целостность по этой ссылке и поддерживается правилом cascade_delete. В третьих, поскольку правило срабатывает в момент изменения таблицы, ему должны быть доступны оба состояния — старое (до изменения) и новое. Обычно они обозначаются именами OLD и NEW.

Рассмотрим еще один пример, показывающий, как средствами SQL можно контролировать уровень доступа к данным. Здесь предполагается, что в столбце sec_label хранятся текстовые обозначения уровня секретности строк. Строки, помеченные как «top secret», может удалять и изменять только пользователь с именем topgun.

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

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

Оператор SET RULES позволит затем восстановить работу механизма правил. По умолчанию этот механизм включен.

Для удаления правил служит оператор

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

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

Регистрация действий пользователей в СУБД Informix

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

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

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

Регистрируемые события

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

Мнемоника

ACTB
ALTB
CLDB
CRAM
CRDB
CRIX
CRSP
CRTB
CRTR
CRVW
DLRW
DNDM
DPAM
DRDB
DRIX
DRLG
DRSP
DRTB
DRTR
DRVW
EXSP
GRDB
GRTB
INRW
LGDB
OPDB
RDRW
RNTC
RVDB
RVTB
STCN
STSN
UPAM
UPDM
UPRW
Доступ к таблице
Изменение таблицы
Закрытие базы данных
Создание маски регистраруемых событий
Создание базы данных
Создание индекса
Создание хранимой процедуры
Создание таблицы
Создание триггера
Создание представления
Удаление строки
Выключение режима зеркалирования дисков
Удаление маски регистраруемых событий
Удаление базы данных
Удаление индекса
Удаление журнала транзакций
Удаление хранимой процедуры
Удаление таблицы
Удаление триггера
Удаление представления
Выполнение хранимой процедуры
Передача привелегий доступа к базе данных
Передача привелегий доступа к таблице
Вставка строки
Изменение режима ведения журнала базы данных
Открытие базы данных
Чтение строки
Переименование таблицы/столбца
Лишение привелегий доступа к базе данных
Лишение привелегий доступа к таблице
Установка ограничения
Начало нового сеанса работы
Изменение маски регистрируемых событий
Включение режима зеркалирования дисков
Изменение строки

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

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

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

  • передача привилегий доступа к базе данных (GRDB);
  • лишение привилегий доступа к базе данных (RVDB);
  • передача привилегий доступа к таблице (GRTB);
  • лишение привилегий доступа к таблице (RVTB);
  • открытие базы данных (OPDB).

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

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

Управление набором регистрируемых событий

Для управления набором регистрируемых событий в СУБД Informix используются маски событий. Три стандартные маски с именами _default, _require и _exclude формируют стандартное регистрационное окружение. Кроме того, для отдельных пользователей могут быть заданы персональные маски с именами, совпадающими с входными именами этих пользователей.

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

  1. Берется маска _default или маска пользователя, если таковая имеется.
  2. В число регистрируемых дополнительно включаются события, заданные маской _require.
  3. Из числа регистрируемых исключаются события, заданные маской _exclude, при условии, что они не были упомянуты в маске _require.

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

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

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

Анализ регистрационной информации

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

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

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

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

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

Средства поддержания высокой готовности

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

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

Сохранение и восстановление баз данных

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

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

Основные понятия

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

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

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

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

Сохранение выполняется на один или несколько логических томов. Логический том — это или ленточный том, или каталог на диске.

Тома объединяются в наборы. Каждый том должен входить в набор. В операциях сохранения задается именно набор томов, куда направляется копия. Оператор (если он отслеживает процесс сохранения) может в ответ на запросы выбирать конкретные тома по своему усмотрению.

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

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

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

Обзор возможностей системы ON-Archive

Система ON-Archive предоставляет следующие основные возможности:

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

Система ON-Archive может работать в трех режимах:

  • под управлением оператора. В этом режиме оператор выдает команды на сохранение и восстановление, а система ON-Archive просит его установить те или другие тома и выдает на консоль сообщения об ошибках;
  • в автоматическом режиме. В этом случае обработкой запросов занимается специальная программа, так называемый виртуальный оператор. Предполагается, что все тома, необходимые для сохранения или восстановления, уже установлены. Если при сохранении оказывается, что это не так, виртуальный оператор направляет информацию на транзитные тома, с которых, как предполагается, данные будут переписаны на постоянные носители. В случае возникновения ошибочных ситуаций виртуальный оператор отправляет администратору электронное письмо;
  • в аварийном режиме. Работа в подобном режиме необходима в случае разрушения таблиц, в которых ON-Archive хранит свою информацию. Естественно, работа в аварийном режиме требует от оператора (администратора) большого числа ручных операций.

Основные компоненты системы ON-Archive

Система ON-Archive включает в себя ряд специализированных утилит, а также таблицы, хранящиеся в базе данных sysmaster.

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

Команда


ARCHIVE
BACKUP
COPY
DEFINE
EXECUTE
LIST
MODIFY
RETRIEVE
Генерация запроса на создание архива
Генерация запроса на резервное копирование журналов транзакций
Копирование данных с одного набора томов на другой
Определение наборов (томов, баз данных) и их компонентов
Выполнение запросов, сгенерированных ранее
Получение информации из таблиц ON-Archive
Внесение изменений в таблицы ON-Archive
Генерация запроса на восстановление данных

С целью оптимизации система ON-Archive поддерживает архивы трех уровней. На уровне 0 создается полная копия базы данных. В архив уровня 1 попадают лишь данные, модифицированные после предыдущего полного архивирования. Наконец, архив уровня 2 состоит из информации, изменившейся с момента архивирования на уровне 1. Подобная система позволяет сократить время архивирования и тем самым фактически повышает надежность работы системы ON-Archive.

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

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

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

Утилита ondatartr позволяет пользователям root и informix восстанавливать не только базы данных, но и саму конфигурацию системы ON-Archive после особенно тяжелых повреждений. Тем самым ondatartr поддерживает работу в аварийном режиме. Общение с утилитой ondatartr происходит на командном языке, аналогичном языку onarchive.

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

Таблицы системы ON-Archive хранят:

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

Управление доступом к сохраненной информации

В конфигурационном файле системы ON-Archive задаются уровни привилегий, на которых она функционирует. Таких уровней три:

  • OPERATOR — на данном уровне операции сохранения и восстановления могут выполнять только пользователи root и informix;
  • GROUP — здесь право пользования системой ON-Archive получают все члены группы super_archive. Правда, они подвергаются контролю прав доступа.
  • OWNER — дает право на сохранение и восстановление всем пользователям, однако они подвергаются проверке прав доступа и могут контролировать только собственные запросы.

Конфигурация может включать в себя любую комбинацию этих трех уровней.

При определении наборов томов задается класс доступа к ним. Если набор объявлен как системный (SYSTEM), к томам, входящим в него, может обращаться любой пользователь. С личными (USER) наборами могут оперировать только те, кто перечислен в списке управления доступом, следующим за спецификатором USER. Если нужно, чтобы к личному набору имели доступ члены группы super_archive, их нужно включить в этот список. Пользователи root и informix могут оперировать со всеми наборами.

С томом или набором томов можно ассоциировать права доступа — на чтение, запись и удаление (последнее право позволяет удалить определение тома или набора из таблиц системы ON-Archive). Чтобы права принимались во внимание, набор должен быть системным или же пользователь должен входить в список управления доступом.


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

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

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

Кластерная организация сервера баз данных

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

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

В настоящем разделе будет рассмотрена разработка компании Sun Microsystems — SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера). Эту архитектуру на начало 1995 года поддерживал лишь сервер компании Oracle, однако ожидается, что компании Sybase и Informix также воспользуются преимуществами кластерной организации.

Аппаратная организация SPARCcluster PDB Server

В минимальной конфигурации SPARCcluster PDB Server состоит из двух узлов SPARCserver 1000, двух дисковых подсистем SPARCstorage Array и консоли кластера (SPARCclassic). Узлы-компьютеры соединяются между собой посредством быстрого Ethernet (100 Мбит/с), дисковые подсистемы подключаются через оптоволоконные каналы. В более мощной конфигурации вместо SPARCserver 1000 может использоваться SPARCcenter 2000, а число дисковых подсистем способно достигать 32 (до 1 Тбайта дискового пространства). Каждый узел кластера — это многопроцессорный компьютер, к которому, помимо прочих, подключены накопители на DAT-лентах (или автозагрузчики кассет с такими лентами). Все связи с компьютерами и дисковыми подсистемами продублированы.

Следующий рисунок поясняет аппаратную организацию SPARCcluster PDB Server.

Рисунок 1.
Аппаратная организация SPARCcluster PDB Server (на рисунке не показаны связи кластера с внешнем миром.)

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

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

Программная организация SPARCcluster PDB Server

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

Рисунок 2.
Программная организация SPARCcluster PDB Server (узлы кластера работают под управлением ОС Solaris версии 2.4 или выше)

Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server.

Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки, установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с параллельной работой узлов кластера и параллельным доступом к нескольким дисковым подсистемам.

Распределенность менеджера блокировок означает, что на каждом узле кластера работает свой экземпляр FT-DLM и что FT-DLM умеет динамически реконфигурировать себя (как при выходе узлов из строя, так и при добавлении новых узлов). В результате выход из строя одного узла не означает краха всего сервера баз данных — сервер жив, пока работает хотя бы один менеджер блокировок.

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

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

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

Нейтрализация отказа узла

Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из отказов — отказа узла. Программное обеспечение предпринимает при этом следующие действия:

  1. Подсистема обнаружения отказов выявляет вышедший из строя узел.
  2. Создается новая конфигурация кластера, без отказавшего узла. Этот процесс занимает 1-2 минуты, в течение которых обработка транзакций приостанавливается.
  3. Менеджер блокировок производит восстановление:
    • a) Подтвержденные транзакции от отказавшего узла (транзакции, об успешном завершении которых другие узлы кластера не успели узнать) накатываются вперед и деблокируются;
    • б) Неподтвержденные транзакции от отказавшего узла откатываются и также деблокируются.
  4. В этот период транзакции обрабатываются исправными узлами, но, вероятно, несколько медленнее, чем обычно.
  5. Монитор транзакций повторно направляет в кластер неподтвержденные транзакции.
  6. Вышедший из строя узел ремонтируется и вновь запускается.
  7. Создается новая конфигурация кластера, включающая в себя отремонтированный узел.

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

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

Informix OnLine-XPS — среда высокой доступности данных

Сервер Informix OnLine Extended Parallel Server (OnLine-XPS) предназначен для слабосвязанных (кластерных) систем и систем с массовым параллелизмом (MPP).

Подобно аппаратным платформам, на которые он рассчитан, Informix OnLine-XPS построен на принципах неразделения ресурсов (независимости узлов). Каждый из узлов кластера или MPP-системы выполняет свой экземпляр программного обеспечения СУБД, которое включает сервисы протоколирования, восстановления, управления блокировками и буферами. Узел, на котором выполняются эти сервисы, называется ко-сервером.

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

Рисунок 3.
Архитектура сервера Informix OnLine-XPS

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

  • аварийное переключение ко-серверов;
  • зеркалирование дисковых областей;
  • тиражирование данных;
  • игнорирование недоступных данных.

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

Аварийное переключение ко-серверов выполняется следующим образом. Каждый ко-сервер владеет некоторым набором дисков, на которых располагаются фрагменты базы данных. Диски, как правило, являются двухпортовыми, и каждый из них физически соединен еще с некоторым ко-сервером Informix OnLine-XPS. Если в результате аппаратного или программного сбоя узел выходит из строя, его диски автоматически передаются во владение альтернативным ко-серверам и доступность данных сохраняется. Рассмотрим, например, конфигурацию на рис. 4. Ко-сервер 2 владеет дисками данных 3 и 4. Диск 3 подключен к альтернативному ко-серверу 1, а диск 4 — к ко-серверу 3.

Рисунок 4.
Аврийное переключение узлов

Когда обнаруживается отказ узла, Informix OnLine-XPS автоматически выполняет восстановление путем аварийного переключения. Диски, журнал транзакций, рабочую загрузку отказавшего узла берут на себя остальные ко-серверы.

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

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

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

Рисунок 5.
Тиражирование данных с основного узла на вторичный.

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

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

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

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

Развитые возможности тиражирования предоставляет СУБД INGRES. Им посвящена статья [2]. Здесь мы рассмотрим возможности другого популярного сервера СУБД — Informix OnLine Dynamic Server (OnLine-DS) 7.1. В отличие от предыдущего раздела, речь пойдет об обычных (а не кластерных) конфигурациях.

В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном отображении данных с основного сервера на вторичные.

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

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

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

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

Угрозы, специфичные для СУБД

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

Мы рассмотрим несколько угроз, возникающих при использовании злоумышленником средств языка SQL.

Получение информации путем логических выводов

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

Следуя [3], рассмотрим больничную базу данных, состоящую из двух таблиц. В первой хранится информация о пациентах (анкетные данные, диагноз, назначения и т.п.), во второй — сведения о докторах (расписание мероприятий, перечень пациентов и т.д.). Если пользователь имеет право доступа только к таблице докторов, он тем не менее может получить косвенную информацию о диагнозах пациентов, поскольку, как правило, врачи специализируются на лечении определенных болезней.

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

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

Основным средством борьбы с подобными угрозами, помимо тщательно проектирования модели данных, является механизм размножения строк. Суть его в том, что в состав первичного ключа, явно или неявно, включается метка безопасности, за счет чего появляется возможность хранить в таблице несколько экземпляров строк с одинаковыми значениями «содержательных» ключевых полей. Наиболее естественно размножение строк реализуется в СУБД, поддерживающих метки безопасности (например, в INGRES/Enhanced Security), однако и стандартными SQL-средствами можно получить удовлетворительное решение.

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

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

Иванов
Петров
Сидоров
СПИД
Сифилис
Стреляная рана

Таблица 4.
Данные с высоким уровнем секретности.

Иванов
Ивлев
Ярцев
Суворов
Пневмония
Рак легких
Ожог второй степени
Микроинфаркт

Таблица 5.
Данные с низким уровнем секретности.

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

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

Иванов
Ивлев
Петров
Сидоров
Ярцев
Суворов СПИД
Рак легких
Сифилис
Стреляная рана
Ожог второй степени
Микроинфаркт

Таблица 6.
Данные, доступные пользователю с высоким уровнем секретности (обратим внимание, что строка «Иванов Пневмания» здесь отсутствует.).

Размножение строк, обеспечивающее необходимую дисциплину доступа, стандартными средствами SQL можно реализовать следующим образом:

Всем пользователям предоставляется доступ только к представлению PatientInfo. Пользователи с низким уровнем благонадежности увидят только информацию, выдаваемую первой конструкцией WHERE, поскольку для них поле SecurityLevel имеет значение «LOW» :

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

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

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

Агрегирование данных

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

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

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

Покушения на высокую готовность (доступность)

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

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

Защита коммуникаций между сервером и клиентами

Проблема защиты коммуникаций между сервером и клиентами не является специфичной для СУБД, она присуща всем распределенным системам. Вполне естественно, что и решения здесь ищутся общие, такие, например, как в распределенной вычислительной среде (Distributed Computing Environment, DCE) концерна OSF. Разработчикам СУБД остается «погрузить» свои программные продукты в эту среду, что и сделала компания Informix, реализовав Informix-DCE/Net [4].

Informix-DCE/Net открывает доступ к сервисам DCE для всех инструментальных средств Informix, а также любых приложений или инструментальных комплексов от независимых поставщиков, которые используют интерфейс ODBC (рис. 8).

Рис.8. Конфигурация прикладной или инструментальной среды клиент-сервер, использующий Informix-DCE/Net.

Ключевым компонентом в реализации взаимодействий клиент-сервер в среде DCE является сервис безопасности. Основные функции, предоставляемые этим сервисом, — аутентификация, реализуемая средствами Kerberos, авторизация (проверка полномочий) и шифрование.

Informix-DCE/Net использует все средства обеспечения безопасности, имеющиеся в DCE. Например, для каждого приложения клиент-сервер администратор может задать один из пяти уровней защиты:

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

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

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

Заключение

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

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

  1. Ошибки и упущения обслуживающего персонала и пользователей.
  2. Действия нечестных работников.
  3. Огонь.
  4. Действия обиженных работников.
  5. Вода.
  6. Действия посторонних лиц.

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

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

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

Защита от посторонних пользователей может строиться на основе использования сервера аутентификации (такого, например, как Kerberos) и брандмауэра (например, Firewall-1).

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

Литература


  1. Ладыженский Г.М. Системы управления базами данных — коротко о главном. — Jet Info, 1995, ## 3-5.
  2. Ладыженский Г.М. Тиражирование данных в СУБД INGRES. — Jet Info, 1994.
  3. Polk T.W., Bassham L.E. Security Issues in the Database Language SQL. — NIST Special Publication 800-8.
  4. G. Chung. Informix-DCE/NET Technical White Paper. — Informix Systems Journal, Vol. 1, Number 3, July-August 1995.
  5. Manola F.A. A Personal View on DBMS Security. — in DATABASE SECURITY: Status and Prospects. C.E. Landwehr (Editor). Elsevier science Publishers B.V. (North Holland). IFIP, 1988, p. 23-34.
  6. Castano S., Fugini M., Martella G., Samarati P. Database Security. — Addison-Wesley, 1995.

Поделитесь материалом с коллегами и друзьями

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

Базы данных

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

Реляционная модель данных

Реляционная модель данных (РМД) —логическаямодель данных, прикладнаятеорияпостроениябаз данных, которая является приложением к задачам обработки данных таких разделовматематикикактеории множествилогика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

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

Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

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

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

Реляционная база данных

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

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

Система управления базами данных

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

— определение данных (описание структуры баз данных);

Некоторые аспекты обеспечения эффективности работы системы управления базами данных

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

Качество работы складывается как из аппаратного уровня, так и из программного уровня оснащения. Одним из способов обеспечения эффективности работы СУБД является оснащение ее профессиональной системой мониторинга.

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

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

Исследования проведенные над возможными структурами систем мониторинга инстанций СУБД определили на сегодняшний день представленную на рисунке 1 блок-схему.

Рассмотрим необходимые структурные компоненты и связи, приминительно к СУБД Oracle.

Дисковый массив (компонент физического уровня) Oracle:

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

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

архив логов (archive log) — точная копия файлов журналирования операций.

Фоновыепроцессы (background processes) Oracle:

драйвер записи данных в БД (Database writer) — запись измененных (грязных) блоков из блоков буферов БД на диск. Когда транзакция изменяет информацию в блоке данных, этот блок данных не обязан быть немедленно записан на диск. Значит можно записывать данные на диск способом более эффективным, чем запись всех изменений по отдельности. Обычно записываются данные тогда, когда они уже нужны для чтения. Записываются также те данные, которые были недавно использованы. Для систем с асинхронным вводом-выводом достаточно одного процесса. Для остальных можно значительно увеличить производительность, создав несколько процессов;

драйвер записи логов (redo log writer) — записывает данные из журнального буфера в журнал изменений;

драйвер архивирующего устройства (archiver) — копирует файлы журнала изменений при их заполнении. Он активен лишь в том случае, если СУБРД работает в режиме ARCHIVELOG.

Системная глобальная область (system global are или SGA) — это область разделяемой памяти, которую Oracle использует для хранения данных и управляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске инстанции Oracle и освобождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA. Составляющие SGA (каждый из которых создается в памяти при запуске инстанции):

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

буфер журнала изменений — хранит данные об изменениях БД. Буфер журнала изменений записывается в файл журнала изменений настолько быстро и эффективно насколько это возможно;

разделяемый пул — это область SGA, в которой хранятся такие структуры разделяемой памяти, как разделяемые SQL-области в библиотечном кэше и внутренняя информация словаря данных. Недостаточный объем разделяемого пула может привести к деградации производительности всей системы. Он состоит из библиотечного кэша и кэша словаря данных. Библиотечный кэш представляет собой область памяти, где сохраняются все операторы SQL и PL/SQL. Процессор БД понимает только команды SQL. Независимо от того, какие средства применяются для обеспечения взаимодействия пользователя с БД, лишь операторы SQL посылаются программному обеспечению для обработки.

Серверные процессы — это механизмы выполнения программного кода. Несколько процессов могут работать одновременно. СУБД работает с двумя видами процессов: пользовательские процессы и процессы Oracle.

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

диспетчеры (dispatcher) — процесс, ответственный за каждый протокол связи. Они организуют взаимодействие между пользовательскими и разделяемыми серверными процессами.

SQL*Net — это клиентские сетевые компоненты и административные утилиты.

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

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

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

Производительность всей системы в целом зависит от функционирования кэш-буфера БД, он состоит из блоков памяти того же размера, что и блоки Oracle. Все данные загружаются в кэш-буфер. В них же выполняется и любое обновление данных, поэтому очень важно правильно устанавливать размер буфера. Oracle переносит данные на диск (используется подкачку swap-данных) в соответствии с порядком их размещения в списке LRU (least recently used — наиболее давно использовавшиеся). Этот список отслеживает обращение к блокам данных и учитывает частоту обращения к ним. Когда выполняется обращение к блоку данных, хранящемуся в кэш-буфере, он помещается в тот конец списка — MRU (most recently used — недавно использованные). При этом, если серверу требуется место в кэш-буфере для загрузки нового блока с диска он обращается к списку LRU и решает какой из блоков перенести на диск, для того чтобы освободить место для нового блока. У блоков наиболее удаленных в списке от MRU самая большая вероятность удаления из кэш-буфера. Дольше всего остаются в кэш-буфере те блоки, обращение к которым производится наиболее часто. Анализ функционирования кэш-буфера выявил следующую блок-схему его работы.

Таблица X$BH содержит информацию о блоках в кэш-буфере. В ней можно увидеть, как «счетчик обращений» увеличивается при каждом обращении к блоку. Сначала находится блок. Используем блок таблицы DUAL — специальной таблицы, состоящей из одной строки и одного столбца (присутствует во всех БД Oracle). Найдем соответствующий номер файла и номер блока в файле:

Илон Маск рекомендует:  Кодирование спец.символов HTML в JavaScript. Эквавалент PHP-функции htmlEntities для JavaScript
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL