Администрирование базы данных

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

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

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

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

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

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

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

Глава 2 Администрирование базы данных

2.1 Управление данными в базах данных

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

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

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

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

Журнал – это так называемая особенная часть БД, недоступная для пользователя СУБД и поддерживаемая особо тщательно базой защиты (кстати можно поддерживать две копии журнала, располагаемые на разных физических дисках), в первую копию которую поступают записи обо всех изменениях основной части БД. А также во многих СУБД изменения баз данных журнализируются на разных уровнях: иногда запись в журнале имеет соответствие многих логических операции изменения БД (например, операции удаления строки из таблицы реляционной базы данных), а в некоторых случаях запись соответствует минимальной внутренней операции модификации страницы внешней памяти. В большинстве личных системах баз одновременно используются оба подхода. А также во всех случаях и при любых обстоятельствах придерживаются стратегии «предупреждающие » записи в журнале (так бы называемого протокола Write Ahead Log – WAL). Говоря своими словами, эта стратегия заключается в том, что запись об изменении любого объекта базы данных должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части базы данных. Так, как нам известно, что если в СУБД правильно соблюдается протокол WAL, то при помощи журнала можно решить даже очень сложные проблемы восстановления баз данных даже после глобального сбоя. К стати самая простая операция восстановления это провести индивидуальный откат изменений в базе данных. Проще говоря, для этого даже не понадобится общесистемный журнал изменений БД, для этого достаточно просто для каждой обработки данных поддерживать локальный журнал изменения операций базы данных, выполненных в этой транзакции, и производить откат транзакции, выполнением обратных данных операций, следуя от конца локального журнала. А в определенных СУБД так и делают, но хочу подметить, что в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для того все записи от одной транзакции и связывают обратным списком (от конца к началу). А также при произошедшим мягком сбое во внешней памяти основной части БД, могут находиться объекты измененные транзакции не закончившимися к моменту сбоя системы базы и могут отсутствовать объекты измененные транзакциями которые к этому моменту сбоя успешно завершились по причине использования буферов оперативной памяти. А содержимое которых при мягком сбое просто пропадает. При соблюдении протокола WAL во внешней памяти журнала всегда должны гарантированно находить записи, относящиеся к операциям изменения обоих видов объектов. Для восстановления баз данных после жесткого сбоя используют журналы, а также архивную копию БД. Говоря своими словами, архивная копия баз данных – это полная копия БД к моменту начала работы заполнения журнала (имеется много вариантов более легкого и гибкого объяснения смысла архивной копии). Конечно, для нормальной операции по восстановлению БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже пояснялось, к сохранности журнала во внешней памяти в СУБД требуются особо повышенные требования. И так операция по восстановлению БД состоит в том, что исходя из архивной копии по журналу, воспроизводится работа всех транзакций обработки данных, которые закончились к моменту сбоя. А также в принципе можно даже и воспроизвести работу незавершенных транзакций и продолжить их работу после восстановления базы данных. Однако во многих реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

2.3 Управление безопасностью в СУБД

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

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

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