Ноябрь/Декабрь 2003
Об Oracle легко и доступно
© Владимир
Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface
Ltd.
Рабочий график рядового администратора
Источник: сайт компании Interface
Ltd., 20.12.2002,
http://www.interface.ru/oracle/graf.htm
СОДЕРЖАНИЕ
Введение
Вопрос "Что должен делать администратор в своей повседневной практике?"
неизбежно встает перед АБД или его начальником. Здесь делается попытка на него
ответить, но без претензий на общность. Многие администраторы СУБД
Oracle - люди весьма знающие и сами поучат автора этих строк тому, что и
как положено делать в их системе. Эта статья не для них. Она для тех, кто получил
Oracle в составе прикладной информационной системы и должен ее поддерживать,
не имея большого предшествующего опыта работы с этой СУБД. Доля таких людей
у нас в стране уже сейчас велика и, по моим наблюдениям, продолжает расти. Книжки
и курсы обучения для них необходимы, но обилие понятий в Oracle нередко способно
породить лишь обреченность: "Все это очень интересно/сложно, но что именно
мне все-таки следует делать сегодня, завтра и через неделю?"
Рабочий график администратора
Итак, администратор получил задание поддерживать БД в составе новой ИС, но,
имея еще и другие обязанности, не хочет или не может забредать в дебри Oracle
чересчур далеко. На каких первоочередных задачах он мог бы сосредоточиться?
Имеет смысл разбить их на группы в соответствии с частотой выполнения. Для
определенности такое разбиение ниже будет условно подразумевать ежедневные,
еженедельные и ежемесячные задачи. Идея та же, что в техобслуживании автомобиля:
там тоже есть процедуры, которые нужно делать часто, а есть - которые редко.
Ежедневные задачи
- Проверка активности СУБД
- Просмотр регистрационных файлов СУБД
- Выявление нежелательных тенденций роста объектов в БД
Пояснения:
(1) Может быть, самая грубая вещь, с которой начать - это проверить, активны
ли ваши подведомственные базы данных (если их несколько). Проще всего это сделать
в Unix, запросив командой ps состояние одного из обязательных фоновых процессов.
Например, процесса PMON. Более универсальным является подключение с помощью
SQL*Plus к каждой из СУБД, что должны иметься, от имени SYS и выдача чего-то
вроде SELECT status FROM v$instance. Правильный ответ - 'OPEN'. Такую проверку
удобно автоматизировать средствами ОС или Oracle Enterprise Manager. (В командном
файле для Windows после обращения к SQL*Plus можно сделать проверку if {%ERRORLEVEL%}
== {0} (…)).
(2) Для этого нужно:
- Подключиться по очереди ко всем машинам, на которых работают ваши СУБД.
- На каждой проверить последние файлы в каталогах bdump сброса журнальной
(регистрационной) информации фоновых процессов СУБД (не путать с журнальными
файлами БД, где регистрируются изменения в базе). Часто это будет каталог
вроде c:\oracle\admin\SID\bdump (SID - имя_экземпляра_СУБД), но если точно
- это каталог, указанный в INIT-параметре background_dump_dest. В первую очередь
нужно просмотреть "хвосты" файлов с именами alert_SID.log или SIDalrt.log
(в разных ОС названия могут варьироваться). Там могут возникнуть сообщения
об ошибках с префиксом ORA. Разумное организационное решение: тексты этих
ошибок можно перенести в специально созданный для этого файл, в котором администратор
протоколировал бы сведения о возникающих с БД проблемах и собственные действия
по восстановлению данных.
- Проверить успешность выполнения резервирования БД, если такое выполнение
такого резервирования поставлено на регулярную основу (а это должно быть так!)
например, прошел ли благополучно сброс архивов на магнитную ленту.
(3)
- Убедиться в достаточности свободного места в табличных пространствах (ТП).
Если объем данных в ТП растет предсказуемо и ТП близко к исчерпанию, могут
понадобиться действия по переносу файлов ТП на другой диск или по добавлению
в состав ТП нового файла.
- Проверить состояние сегментов отката (rollback segments). (Главным образом
это забота администратора версий 8 и 7, так как в версии 9 СУБД работа с сегментами
отката выглядит с точки зрения потребителя существенно проще, чем раньше).
Обычное состояние сегментов отката - ONLINE. Это состояние, размеры и прочую
статистику сегментов можно почерпнуть из таблиц словаря-справочника; в версиях
8 и 7 это DBA_ROLLBACK_SEGS и V$ROLLSTAT.
- Выявить сегменты, чей рост грозит в будущем неприятностями. В идеале лучше
всего наладить автоматический сбор данных о ежедневном росте всех таблиц и
их индексов, росте числе экстентов и их заполненности. Обнаруживаемые нездоровые
тенденции могут потребовать упреждающих действий по реорганизации хранения,
например увеличения параметра MAXEXTENTS не дожидаясь потока сообщений об
ошибках при вставке строк в таблицу.
Еженедельные задачи
Несколько реже можно предложить выполнение следующих действий:
- Выявление объектов БД, нарушающих принятые соглашения хранения
- Выявление некорректных с точки зрения СУБД или неработоспособных объектов
БД
- Выявление реальных и возможных нарушений прав доступа
- Просмотр сигнальной информации в журнальных файлах Oracle Net
Пояснения:
(1) Идея здесь проста. Будет правильно, если для своих рабочих баз вы сформулируете
политику формирования имен, атрибутов хранения (storage), первичных ключей и
прочего для объектов, создаваемых в БД. Так, в соответствии с этой политикой
вы бы могли обязать, к примеру, все таблицы иметь суррогатные (искусственные)
ключи (и, соответственно, правила формирования значений ключей); справочным
таблицам могли бы вменить параметр блока PCTFREE = 0; индексы могли бы обязать
храниться в отдельных ТП и так далее. Это организационные правила, напрямую
не контролируемые СУБД, и поэтому их нарушения, возникающие по мере создания
и изменения объектов, нужно выявлять самостоятельно.
(2)
- При интенсивном использовании БД в хранимых объектах могут изредка возникать
внутренние разрушения структуры. Лучше не дожидаться, пока эти внутренние
разрушения проявятся при работе прикладной системы и обнаруживать их заранее.
Например, для таблицы можно использовать команду ANALYZE TABLE emp VALIDATE
STRUCTURE. Испорченный индекс можно восстановить командой ALTER INDEX REBUILD
ONLINE.
- Другие объекты могут быть не испорченными, но оказаться в нерабочем состоянии
(например, после импорта). Это может касаться хранимых подпрограмм, триггеров
и выводимых таблиц. Посмотреть их фактическое состояние можно в таблицах словаря-справочника,
например в поле USER_OBJECTS.STATUS (должно быть 'VALID').
(3)
- Если в БД включен аудит, нужно выявить попытки перейти за рамки дозволенного
по данным аудита. Если для компенсации отсутствующих в системных средствах
аудита в Oracle возможностей (например, аудита изменения отдельных строк таблицы)
у вас используется сбор информации в собственные журнальные таблицы (с помощью
триггеров) нужно просмотреть их. Начиная с версии 9 стал реально работоспособен
LogMiner, дающий возможность наблюдать все действия в БД по изменению данных,
но нужно помнить, что без включенного в СУБД режима архивации его ценность
невелика.
- Если у БД несколько "хозяев", не мешает устроить проверку простых
паролей, например system/manager или ctxsys/ctxsys.
- С той же целью полезно устроить очередную ревизию наличия у пользователей
потенциально опасных прав (типа SELECT ANY TABLE) и ролей (типа EXP_FULL_DATABASE).
(4) Эти файлы позволяют проследить клиентские соединения с СУБД. Если вы не
задавали иного в файле SQLNET.ORA, то места их нахождения - в каталогах %ORACLE_HOME%\network\log
и %ORACLE_HOME%\network\trace. К сожалению, файлы могут быть очень объемны и
неудобны для чтения, но зато они весьма подробны.
Ежемесячные задачи
В типичном случае реже всего можно выполнять следующие регулярные действия:
- Рассмотреть возможность подстройки SGA
- Попытаться найти и устранить проблемы ввода/вывода
- Определить неблагоприятные тенденции производительности СУБД и предложить
решения
Пояснения:
(1) Даже если СУБД в составе ИС пришла хорошо настроенной, со временем могут
измениться наполнение БД и условия эксплуатации. Для лучшей работы БД может
потребоваться откорректировать основные параметры SGA: размеры буфера данных,
буфера журнала БД и shared pool, а также других. Поводом для корректировки могут
служить наблюдения за задержками работы системы, сделанные самостоятельно обращением
к словарю-справочнику, после прогона процедуры STATSPACK.SNAP или по графикам
Enterprise Manager.
(2) Примерно то же со вводом/выводом. Например, увеличение со временем интенсивности
изменений в БД может сделать разумным перенос файлов с сегментами отката на
другие диски.
(3) Основанием для принятия таких решений могут послужить наблюдения за использованием
СУБД процессора, оперативной памяти и сетевых соединений, сделанные как средствами
Oracle, так и ОС.
Насколько полны эти списки?
Приведенные выше списки, конечно, условны. Конкретный регламент работ диктуется
конкретными условиями и требованиями к эксплуатации конкретной установки. Список
других задач, которые, по мнению разработчиков Oracle могут быть включены в
ваш рабочий график, можно найти в книге Administrator's Guide документации по
системе. Аналогичный список, представляющий точку зрения практикующих администраторов
можно разыскать в интернете - правда, не сведенный, к сожалению, воедино, или
получить от консультанта.
Кроме того, здесь не учтены эпизодические (а не регламентные) работы, которые
приходится проделывать администратору по мере возникающей необходимости. Важнейший
класс таких работ - восстановление утерянных данных. Восстановление данных -
тема отдельного большого разговора. С другой стороны, резервирование данных
в списки выше тоже не вошло, потому что обычно выполняется автоматически поставленной
ИС, если, конечно же, прикладной разработчик оказался достаточно грамотным,
чтобы об этом позаботиться.
И третье. Конкретный перечень задач связан еще и с версией используемой СУБД.
Так, в версии 9 с администратора снято 95% прежних забот по поддержке сегментов
отката. Локально управляемые табличные пространства упрощают поддержку табличных
пространств, и так далее. Но ввиду того, что доля версии 9 на практике сейчас
не превышает 15%, такие устаревающие задачи в списках все же приведены.
|
