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

Размещено на http://www.allbest.ru/

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

1.1 Администратор базы данных (DBA)

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

Администрирование базы данных - это функция управления базой данных (БД). Лицо ответственное за администрирование БД называется “Администратор базы данных” (АБД) или “Database Administrator” (DBA).

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

Таким образом, сформировалось определение БД как общего информационного ресурса предприятия, которое должно находиться всегда в работоспособном состоянии. И как для каждого общего ресурса значительной важности, БД стала требовать отдельного управления. Во многих случаях это было необходимо для обеспечения её повседневной эксплуатации, её развития в соответствии с растущими потребностями предприятия. К тому же БД и технология её разработки постоянно совершенствовались и уже требовались специальные знания высокого уровня для довольно сложного объекта, которым стала база данных. Отсюда функция управления базой данных и получила название “Администрирование базы данных”, а лицо ею управляющее стали называть “Администратор баз данных”.

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

АБД имеет код специальности по общероссийскому классификатору профессий рабочих, должностей служащих и тарифных разрядов (ОКПДТР) -- 40064 и код 2139 по Общероссийскому классификатору занятий (ОКЗ). Код 2139 ОКЗ расшифровывается следующим образом: 2 - СПЕЦИАЛИСТЫ ВЫСШЕГО УРОВНЯ КВАЛИФИКАЦИИ, 21 - Специалисты в области естественных* и инженерных наук, 213 - Специалисты по компьютерам, 2139 - Специалисты по компьютерам, не вошедшие в другие группы.

История

Классические подходы к наполнению содержанием понятия "АБД" стали формироваться после издания рабочего отчета группы по базам данных Американского Национального Института Стандартов ANSI/X3/SPARC в 1975 года. В этом отчете была описана трехуровневая архитектура СУБД, в которой выделялся уровень внешних схем данных, уровень концептуальной схемы данных и уровень схемы физического хранения данных. В соответствии с этой архитектурой определялись три роли АБД: администратор концептуальной схемы, администратор внешних схем и администратор хранения данных. Эти роли в случае очень маленькой системы мог играть один человек, в большой системе для выполнения каждой роли могла назначаться группа людей. Каждой роли соответствовал набор функций, а все эти функции вместе составляли функции АБД.

В 1980 - 1981 г. в американской литературе стало принятым включать в функции АБД:

организационное и техническое планирование БД,

проектирование БД,

обеспечение поддержки разработок прикладных программ,

управление эксплуатацией БД.

В нашей стране в это же время первое определение АБД в ГОСТ-ах задало слишком узкий состав функций АБД:

подготовка вычислительного комплекса к установке СУБД, участие в установке и приемке СУБД и самой БД с комплексом прикладных программ,

управление эксплуатацией БД,

подготовка словарей и другой НСИ - нормативно-справочной информации - к моменту начала испытания БД.

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

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

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

Задачи АБД могут незначительно отличаться в зависимости от вида применяемой СУБД, но в основные задачи входит:

Проектирование базы данных.

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

Обеспечение и контроль доступа к базе данных.

Обеспечение безопасности в базе данных.

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

Обеспечение целостности баз данных.

Обеспечение перехода на новую версию СУБД.

Основные типы администраторов БД

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

Системный администратор.

Архитектор БД.

Аналитик БД.

Разработчик моделей данных.

Администратор приложении.

Проблемно-ориентированный администратор БД.

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

Администратор хранилища данных.

администрирование потребность проектирование

1.2 Защита баз данных

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

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

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

Пользователей СУБД можно разделить на три группы:

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

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

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

В современных СУБД достаточно развиты средства дискреционной защиты.

Дискреционное управление доступам (discretionary access control) -- разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.

Дискреционная защита является многоуровневой логической защитой.

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

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

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

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

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

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

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

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

1.3 Оптимизация базы данных

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

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

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

- Грамотное проектирование базы.

- Сборка мусора, возникающего при работе СУБД.

2 Наличие быстрых путей доступа к данным -- индексов.

3 Возможность использования оптимизатором этих быстрых путей.

4 Обход известных проблем.

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

Излишек индексов, впрочем, тоже чреват проблемами:

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

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

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

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

Можно определить следующие этапы оптимизации работы БД:

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

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

Выбор параметров хранения вновь создаваемых объектов базы данных; настройка и оптимизации БД, предоставление ответов на вопросы типа «как» и «что если».

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

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

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

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

Размещено на Allbest.ru