|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 20.12.02 | |
| СТАТЬЯ |
20.12.02
|
Владимир
Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface
Ltd.
Вопрос "Что должен делать администратор в своей повседневной практике?" неизбежно встает перед АБД или его начальником. Здесь делается попытка на него ответить, но без претензий на общность. Многие администраторы СУБД 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) Для этого нужно:
(3)
Несколько реже можно предложить выполнение следующих действий:
Пояснения:
(1) Идея здесь проста. Будет правильно, если для своих рабочих баз вы сформулируете политику формирования имен, атрибутов хранения (storage), первичных ключей и прочего для объектов, создаваемых в БД. Так, в соответствии с этой политикой вы бы могли обязать, к примеру, все таблицы иметь суррогатные (искусственные) ключи (и, соответственно, правила формирования значений ключей); справочным таблицам могли бы вменить параметр блока PCTFREE = 0; индексы могли бы обязать храниться в отдельных ТП и так далее. Это организационные правила, напрямую не контролируемые СУБД, и поэтому их нарушения, возникающие по мере создания и изменения объектов, нужно выявлять самостоятельно.
(2)
(3)
(4) Эти файлы позволяют проследить клиентские соединения с СУБД. Если вы не задавали иного в файле SQLNET.ORA, то места их нахождения - в каталогах %ORACLE_HOME%\network\log и %ORACLE_HOME%\network\trace. К сожалению, файлы могут быть очень объемны и неудобны для чтения, но зато они весьма подробны.
В типичном случае реже всего можно выполнять следующие регулярные действия:
Пояснения:
(1) Даже если СУБД в составе ИС пришла хорошо настроенной, со временем могут измениться наполнение БД и условия эксплуатации. Для лучшей работы БД может потребоваться откорректировать основные параметры SGA: размеры буфера данных, буфера журнала БД и shared pool, а также других. Поводом для корректировки могут служить наблюдения за задержками работы системы, сделанные самостоятельно обращением к словарю-справочнику, после прогона процедуры STATSPACK.SNAP или по графикам Enterprise Manager.
(2) Примерно то же со вводом/выводом. Например, увеличение со временем интенсивности изменений в БД может сделать разумным перенос файлов с сегментами отката на другие диски.
(3) Основанием для принятия таких решений могут послужить наблюдения за использованием СУБД процессора, оперативной памяти и сетевых соединений, сделанные как средствами Oracle, так и ОС.
Приведенные выше списки, конечно, условны. Конкретный регламент работ диктуется конкретными условиями и требованиями к эксплуатации конкретной установки. Список других задач, которые, по мнению разработчиков Oracle могут быть включены в ваш рабочий график, можно найти в книге Administrator's Guide документации по системе. Аналогичный список, представляющий точку зрения практикующих администраторов можно разыскать в интернете - правда, не сведенный, к сожалению, воедино, или получить от консультанта.
Кроме того, здесь не учтены эпизодические (а не регламентные) работы, которые приходится проделывать администратору по мере возникающей необходимости. Важнейший класс таких работ - восстановление утерянных данных. Восстановление данных - тема отдельного большого разговора. С другой стороны, резервирование данных в списки выше тоже не вошло, потому что обычно выполняется автоматически поставленной ИС, если, конечно же, прикладной разработчик оказался достаточно грамотным, чтобы об этом позаботиться.
И третье. Конкретный перечень задач связан еще и с версией используемой СУБД. Так, в версии 9 с администратора снято 95% прежних забот по поддержке сегментов отката. Локально управляемые табличные пространства упрощают поддержку табличных пространств, и так далее. Но ввиду того, что доля версии 9 на практике сейчас не превышает 15%, такие устаревающие задачи в списках все же приведены.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||