Взято отсюда:
Введение
Вопрос "Что должен делать администратор в своей повседневной практике?" неизбежно встает перед АБД или его начальником. Здесь делается попытка на него ответить, но без претензий на общность. Многие администраторы СУБД 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) Для этого нужно:
* Подключиться по очереди ко всем машинам, на которых работают ваши СУБД.
* На каждой проверить последние файлы в каталогах 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 не дожидаясь потока сообщений об ошибках при вставке строк в таблицу.
Еженедельные задачи
Несколько реже можно предложить выполнение следующих действий:
1. Выявление объектов БД, нарушающих принятые соглашения хранения
2. Выявление некорректных с точки зрения СУБД или неработоспособных объектов БД
3. Выявление реальных и возможных нарушений прав доступа
4. Просмотр сигнальной информации в журнальных файлах 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. К сожалению, файлы могут быть очень объемны и неудобны для чтения, но зато они весьма подробны.
Ежемесячные задачи
В типичном случае реже всего можно выполнять следующие регулярные действия:
1. Рассмотреть возможность подстройки SGA
2. Попытаться найти и устранить проблемы ввода/вывода
3. Определить неблагоприятные тенденции производительности СУБД и предложить решения
Пояснения:
(1) Даже если СУБД в составе ИС пришла хорошо настроенной, со временем могут измениться наполнение БД и условия эксплуатации. Для лучшей работы БД может потребоваться откорректировать основные параметры SGA: размеры буфера данных, буфера журнала БД и shared pool, а также других. Поводом для корректировки могут служить наблюдения за задержками работы системы, сделанные самостоятельно обращением к словарю-справочнику, после прогона процедуры STATSPACK.SNAP или по графикам Enterprise Manager.
(2) Примерно то же со вводом/выводом. Например, увеличение со временем интенсивности изменений в БД может сделать разумным перенос файлов с сегментами отката на другие диски.
(3) Основанием для принятия таких решений могут послужить наблюдения за использованием СУБД процессора, оперативной памяти и сетевых соединений, сделанные как средствами Oracle, так и ОС.
Насколько полны эти списки?
Приведенные выше списки, конечно, условны. Конкретный регламент работ диктуется конкретными условиями и требованиями к эксплуатации конкретной установки. Список других задач, которые, по мнению разработчиков Oracle могут быть включены в ваш рабочий график, можно найти в книге Administrator's Guide документации по системе. Аналогичный список, представляющий точку зрения практикующих администраторов можно разыскать в интернете - правда, не сведенный, к сожалению, воедино, или получить от консультанта.
Кроме того, здесь не учтены эпизодические (а не регламентные) работы, которые приходится проделывать администратору по мере возникающей необходимости. Важнейший класс таких работ - восстановление утерянных данных. Восстановление данных - тема отдельного большого разговора. С другой стороны, резервирование данных в списки выше тоже не вошло, потому что обычно выполняется автоматически поставленной ИС, если, конечно же, прикладной разработчик оказался достаточно грамотным, чтобы об этом позаботиться.
И третье. Конкретный перечень задач связан еще и с версией используемой СУБД. Так, в версии 9 с администратора снято 95% прежних забот по поддержке сегментов отката. Локально управляемые табличные пространства упрощают поддержку табличных пространств, и так далее. Но ввиду того, что доля версии 9 на практике сейчас не превышает 15%, такие устаревающие задачи в списках все же приведены.