Печать
Категория: Администрирование
Просмотров: 21694

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

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

Вариант от Oracle

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

Установка и обновление программного обеспечения Oracle и прикладных средств.

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

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

Распределение внешней памяти системы и планирование дальнейших потребностей в ней

В этой обязанности администратор Oracle должен представлять, как и для чего Oracle использует внешнюю (дисковую) память. Быть знакомым с файловыми системами платформ, на которых она расположена. Иметь понятие об устройствах ASM (Automatic Storage Management или Автоматическое управление хранением файлов БД) и RAW устройствах (сырые). Знать, что такое RAID и разбираться в его конфигурировании. Уметь оптимально, с точки зрения производительности, размещать файлы Oracle во внешней памяти. Владеть навыками настройки ASM. Просчитывать потребности Oracle во внешней памяти на ближайшее будущее.

Если проще, то администратор должен подготовить и распределить место для базы данных Oracle в дисковом пространстве сервера. Причём сделать это так, что бы этого места с избытком хватило и на ближайшую перспективу. Здесь не обязательно знать досконально ASM, RAID или RAW устройства, главное иметь представление для чего они служат. Ведь некоторые из этих устройств можно никогда и не использовать в организации внешней памяти.

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

Создание первичных структур хранения базы данных (табличных пространств) по мере завершения разработок приложений

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

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

Создание первичных объектов (таблиц, представлений, индексов) по мере завершения разработок приложений

Администратор должен создавать первичные объекты Oracle.

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

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

Модификация структуры базы данных по требованию разработчиков приложений

Администратор должен модифицировать объекты базы данных Oracle по требованию разработчиков.

В процессе сопровождения или изменения приложения может возникнуть ситуация, когда необходимо внести изменения в некоторые объекты Oracle относящиеся к приложению. Этими объектами могут являться не только первичные объекты, созданные на этапе разработки приложения, но  и хранимые  PL/SQL объекты созданные позднее.

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

В качестве инструментов по модификации структуры базы данных могут выступать как сторонний инструментарий разработчика приложений (Oracle SQL Developer, SQL Navigator, PL/SQL Developer, DBAScript for Oracle), так и стандартные утилиты Oracle (SQLPlus, SQLPlus Worksheet , iSQLPlus). В любом случае работу лучше организовать, как простое выполнение SQL скриптов подготовленных разработчиками приложений, с дальнейшей перекомпиляцией зависимых инвалидных объектов.

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

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

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

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

Например:

Обеспечение соответствия лицензионному соглашению с корпорацией Oracle

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

Лицензия Oracle оформляется на конечное число пользователей или процессоров. Администратор должен следить за тем, чтобы при создании учётных записей или смене аппаратной конфигурации сервера базы данных, это число не было превышено. Так же некоторые опции Oracle являются платными, а некоторые возможности Oracle доступны только в других редакциях. Поэтому администратор должен следить за тем, чтобы редакция и используемые опции проинсталлированного программного обеспечения соответствовали лицензионному соглашению. В этом случае лучше сразу проинсталлировать Oracle в разрешённой редакции, при этом выключив нелицензионные опции. Это убережёт в дальнейшем  от ситуаций «Давайте вначале попробуем, а уже потом …». Обычно «потом» уже деньги никто платить не хочет, и лицензионное соглашение будет нарушено.

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

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

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

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

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

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

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

База данных – «живой организм». Утверждения «А у нас ничего не менялось» здесь не проходят. Меняются пользовательские и системные данные. Меняется статистика и планы запросов. Накапливаются ошибки. Изменяется используемая память и увеличивается в размерах  сама база. Всё это, в конце концов, может привести к ухудшению производительности системы. Заметить это ухудшение как можно раньше, это одна из главных задач администратора. Для этого требуется постоянно производить мониторинг системы по основным показателям производительности. Если эти значения изменились в худшую сторону, администратор должен принять меры к углублённому анализу и на его основе приступить к настройке базы данных. Но это то, что касается базы данных в целом.

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

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

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

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

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

Эта обязанность редка. Обычно все инструкции и другие документы уже давно составлены, так как они требуются, к примеру, в большинстве систем (например, систем менеджмента качества ИСО 9001).

Ведение архивных данных на магнитных лентах

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

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

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

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

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

Связь с корпорацией Oracle для получения технической помощи

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

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

Роли от Сэма Алапати

Обеспечение безопасности

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

Резервное копирование

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

Производительность

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

Структура

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

Внедрение

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

Мой вариант

Ниже представлены обязанности администратора баз данных Oracle, как это представляю я (в порядке убывания приоритетов).

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

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

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

Обеспечение безопасности

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

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

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

Установка патчей безопасности программного обеспечения Oracle.

Настройка и мониторинг аудита пользователей и объектов.

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

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

Осуществление мониторинга

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

Мониторинг сеансов пользователей. Отлавливание долго выполняющихся SQL запросов пользователей к базе данных.

Наблюдение за состоянием заданий Oracle.

Здесь я бы порекомендовал следующий порядок действий. Один раз в день (можно с  утра) производить просмотр трассировочных файлов. Сразу можно  увидеть, были ли ошибки в заданиях. Проверка статуса заданий (выполняется или нет, выключено). Проверка доступного  размера табличных пространств (если уже на грани). Дальше можно посмотреть сеансы пользователей. Если есть долго висящие активные, то смотреть их ожидания и SQL запросы. Не стоит забывать и про наличие очередей сеансов. Наблюдение за  сеансами можно производить в течение дня. Как только начинается рост колличества активных сеансов или растёт  продолжительность их работы, это сигнал падения производительности. Мониторинг можно осуществлять с помощью SQL запросов или графических инструментов (например ZhiDBA for Oracle).

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

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

Создание базы данных

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

Создание и сопровождение объектов

Создание объектов Oracle по просьбе разработчиков приложений. Настройка параметров хранения этих объектов. Размещение объектов в необходимых табличных пространствах. Перекомпиляция инвалидных хранимых PL/SQL объектов.