(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

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

Владимир Пржиялковский

Оглавление

Введение

Вопрос "Что должен делать администратор в своей повседневной практике?" неизбежно встает перед АБД или его начальником. Здесь делается попытка на него ответить, но без претензий на общность. Многие администраторы СУБД 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%, такие устаревающие задачи в списках все же приведены.

Ссылки по теме


 Распечатать »
 Правила публикации »
  Обсудить материал в конференции Oracle »
Написать редактору 
 Рекомендовать » Дата публикации: 20.12.2002 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Oracle Database Personal Edition Named User Plus License
Oracle Database Standard Edition 2 Processor License
Oracle Database Standard Edition 2 Named User Plus License
Oracle Database Personal Edition Named User Plus Software Update License & Support
Toad Data Modeler Per Seat License/Maint
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Вопросы и ответы по MS SQL Server
Мастерская программиста
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Сайт инструмент (1)
Я бывший программист пользовался 1 сайтом проверенным он мне действительно помог я блогодоря...
 
Где взять лицензионный ключ для AllFusion Process Modeler (BPwin) 7? (5)
Выручайте!!! где найти ключ, ужасно срочно нужна программа. заранее спасибо!
 
работа на дому! (5)
Доброго времени суток дорогие друзья. Многоуровневый маркетинг окончательно признан...
 
Регистрация на Oracle.com (4)
Сразу прошу прощения за тупой вопрос, но вчера зарегался на oracle.com (чтоб 9i слить себе...
 
Ищу кодера (2)
Добрый день! Ищу кодера который сможет сделать копии сайтов. Сколько будет стоить скопировать...
 
 
 



    
rambler's top100 Rambler's Top100