Вы находитесь на страницах старой версии сайта.
Переходите на новую версию Interface.Ru

СТАТЬЯ
20.12.02


Рабочий график рядового администратора

Владимир Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface Ltd.

Введение

Вопрос "Что должен делать администратор в своей повседневной практике?" неизбежно встает перед АБД или его начальником. Здесь делается попытка на него ответить, но без претензий на общность. Многие администраторы СУБД Oracle - люди весьма знающие и сами поучат автора этих строк тому, что и как положено делать в их системе. Эта статья не для них. Она для тех, кто получил Oracle в составе прикладной информационной системы и должен ее поддерживать, не имея большого предшествующего опыта работы с этой СУБД. Доля таких людей у нас в стране уже сейчас велика и, по моим наблюдениям, продолжает расти. Книжки и курсы обучения для них необходимы, но обилие понятий в Oracle нередко способно породить лишь обреченность: "Все это очень интересно/сложно, но что именно мне все-таки следует делать сегодня, завтра и через неделю?"

Рабочий график администратора

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

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

Ежедневные задачи

  1. Проверка активности СУБД
  2. Просмотр регистрационных файлов СУБД
  3. Выявление нежелательных тенденций роста объектов в БД

Пояснения:

(1) Может быть, самая грубая вещь, с которой начать - это проверить, активны ли ваши подведомственные базы данных (если их несколько). Проще всего это сделать в Unix, запросив командой ps состояние одного из обязательных фоновых процессов. Например, процесса PMON. Более универсальным является подключение с помощью SQL*Plus к каждой из СУБД, что должны иметься, от имени SYS и выдача чего-то вроде SELECT status FROM v$instance. Правильный ответ - 'OPEN'. Такую проверку удобно автоматизировать средствами ОС или Oracle Enterprise Manager. (В командном файле для Windows после обращения к SQL*Plus можно сделать проверку if {%ERRORLEVEL%} == {0} (…)).

(2) Для этого нужно:

(3)

Еженедельные задачи

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

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

Пояснения:

(1) Идея здесь проста. Будет правильно, если для своих рабочих баз вы сформулируете политику формирования имен, атрибутов хранения (storage), первичных ключей и прочего для объектов, создаваемых в БД. Так, в соответствии с этой политикой вы бы могли обязать, к примеру, все таблицы иметь суррогатные (искусственные) ключи (и, соответственно, правила формирования значений ключей); справочным таблицам могли бы вменить параметр блока PCTFREE = 0; индексы могли бы обязать храниться в отдельных ТП и так далее. Это организационные правила, напрямую не контролируемые СУБД, и поэтому их нарушения, возникающие по мере создания и изменения объектов, нужно выявлять самостоятельно.

(2)

(3)

(4) Эти файлы позволяют проследить клиентские соединения с СУБД. Если вы не задавали иного в файле SQLNET.ORA, то места их нахождения - в каталогах %ORACLE_HOME%\network\log и %ORACLE_HOME%\network\trace. К сожалению, файлы могут быть очень объемны и неудобны для чтения, но зато они весьма подробны.

Ежемесячные задачи

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

  1. Рассмотреть возможность подстройки SGA
  2. Попытаться найти и устранить проблемы ввода/вывода
  3. Определить неблагоприятные тенденции производительности СУБД и предложить решения

Пояснения:

(1) Даже если СУБД в составе ИС пришла хорошо настроенной, со временем могут измениться наполнение БД и условия эксплуатации. Для лучшей работы БД может потребоваться откорректировать основные параметры SGA: размеры буфера данных, буфера журнала БД и shared pool, а также других. Поводом для корректировки могут служить наблюдения за задержками работы системы, сделанные самостоятельно обращением к словарю-справочнику, после прогона процедуры STATSPACK.SNAP или по графикам Enterprise Manager.

(2) Примерно то же со вводом/выводом. Например, увеличение со временем интенсивности изменений в БД может сделать разумным перенос файлов с сегментами отката на другие диски.

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

Насколько полны эти списки?

Приведенные выше списки, конечно, условны. Конкретный регламент работ диктуется конкретными условиями и требованиями к эксплуатации конкретной установки. Список других задач, которые, по мнению разработчиков Oracle могут быть включены в ваш рабочий график, можно найти в книге Administrator's Guide документации по системе. Аналогичный список, представляющий точку зрения практикующих администраторов можно разыскать в интернете - правда, не сведенный, к сожалению, воедино, или получить от консультанта.

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

И третье. Конкретный перечень задач связан еще и с версией используемой СУБД. Так, в версии 9 с администратора снято 95% прежних забот по поддержке сегментов отката. Локально управляемые табличные пространства упрощают поддержку табличных пространств, и так далее. Но ввиду того, что доля версии 9 на практике сейчас не превышает 15%, такие устаревающие задачи в списках все же приведены.

Дополнительная информация

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме Oracle

Рекомендовать страницу

INTERFACE Ltd.
Телефон/Факс: +7 (495) 925-0049
Отправить E-Mail
http://www.interface.ru
Rambler's Top100
Ваши замечания и предложения отправляйте редактору
По техническим вопросам обращайтесь к вебмастеру
Дата публикации: 20.12.02