Владимир Пржиялковский,
преподаватель УКЦ Interface Ltd.

Изначально Oracle – командная система. Лучше всего она понимает и больше всего слушается обычной командной строки. Для просоленных юниксовых флибустьеров оракловских просторов большего, чем консольное окошко да горсть динамических таблиц словаря-справочника, почти ничего и не нужно; эта смесь способна творить чудеса. Однако для многих других – например, исследующих прибрежное пространство на яликах типа Windows – обращаться с этими средствами то ли непривычно, то ли недосуг, особенно при наличии прочих обязанностей, помимо администрирования. Таким “мореплавателям” обязательно нужно обратить внимание на комплекс средств для администрирования БД, имеющийся в последних версиях Oracle, то есть на Oracle Enterprise Manager, сокращенно OEM.

Почему OEM?

Начну с того, что вам не скажет ни один представитель Oracle в официальном выступлении или же документе: на рынке имеется с десяток систем третьих фирм, предлагающих системы, способные администрировать Oracle. Многие из них добротно сделаны и изящно выглядят. С другой стороны, кто видел – тот знает, а кто не видел – быстро обнаружит, что OEM временами оставляет впечатление тяжеловесного неуклюжего и неотесанного деревенского парня. Возникает вопрос: так зачем с ним связываться? Вот зачем.

Во-первых, будучи продуктом одного разработчика, он теснее связан с Oracle. Не секрет, что СУБД Oracle от версии к версии изменяется. Третьи фирмы не имеют возможности оперативно реагировать на появление новых свойств, в то время как разработчики OEM могут быть знакомы с появляющимися (изменяющимися) свойствами в полном объеме и заранее. В результате хорошие, на первый взгляд, продукты третьих фирм время от времени демонстрируют невозможность работать с теми или иными постоянно возникающими новшествами СУБД.

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

Где его взять?

Для версии 8.1.5 OEM поставлялся на отдельном компакт-диске. Ознакомительная версия OEM 2.1 доступна на www.oracle.com и у распространителей Oracle. В версии 8.1.6 с основного диска “ушла” на отдельный CD документация по Oracle, но на ее место перекочевали большинство модулей OEM. В версии сервера 8.1.7 эта же схема сохранилась, правда с поправкой, что поставляется уже версия OEM 2.2. Кроме того, для обеих последних версий (8.1.6 и 8.1.7) полный вариант OEM имеется на отдельном диске.

Таким образом, при установке версии сервера 8.1.6 или 8.1.7 OEM, почти в полном объеме, появится у вас автоматически или в результате явного указания устанавливаемой программной среды; в любом случае его можно устанавливать с отдельного диска или доустановить с базового дистрибутива.

Сказанное относится к поставкам для Windows и “легким” Unix (в том числе Linux). Для крупных Unix-поставок и прочих ОС расклад может быть иным. Следует заметить, что OEM написан на Java и способен работать под разными ОС. Кроме того, в нем есть некий аналог “клиента” и “сервера” (см. ниже) места расположения которых могут быть в разных ОС.

Как правильно работать с OEM

Как продукт с графичесикм интерфейсом, обладающий, к тому же, “тьюторами”, OEM вполне доступен для самостоятельного изучения. Но с ним связана одна трудность: он может работать как со 100%-й функциональностью, так и со значительно ограниченной. Переход к полнофункциональному варианту не совсем очевиден, и многие, наталкиваясь на препятствие, решают не тратить время на расследование, в результате удостаиваясь существенно обедненным вариантом DBA Studio – и только. Речь идет о просьбе указать “Management Server”, получив которую от OEM некоторые пользователи теряются, выбирают вариант “standalone” и … теряют для себя многие замечательные качества OEM, едва ли не сводя роль этого продукта фактически к навигатору: Без установленного Management Server в некоторые модули OEM вы попросту не сможете войти.

Между тем преодолеть этот барьер не так уж сложно, и рассказать, как это сделать – цель настоящей статьи.

Основные понятия

Чтобы понять, что нужно делать для “правильной” работы с OEM, необходимо вспомнить некоторые связанные с ним понятия.

Пусть имеется локальная сеть с несколькими узлами (компьютерами), на которых находятся БД под Oracle (их может быть по нескольку на одном узле). Мы хотим с помощью OEM администрировать все это хозяйство баз. Вот элементы, которые потребуются для полнофункционального использования Enterprise Manager:

Oracle Management Server – “сервер-распорядитель”. Это база данных, в которой хранится информация о наблюдаемых OEM серверах Oracle в локальной сети. Термин “база данных” употреблен здесь чисто содержательно; он не имеет отношения к предложению CREATE DATABASE… (к сожалению, в Oracle этот термин не доведен до логической ясности, и, к еще большему сожалению, он в этом отношении не одинок!). Будем называть ее репозитарием. Репозитарий для Management Server создается в отдельной схеме (еще одно противоречивое понятие в Oracle!) и может располагаться в одной из существующих в локальной сети БД (теперь уже – в смысле CREATE DATABASE …).

Management Server Service – служба (“сервис“ в NT/Win2000 или процесс в Unix), расположенная на узле (компьютере) с БД Management Server. В случае ее отсутствия или неактивного состояния OEM работоспособен, но теряет существенную долю своей функциональности.

Intelligent Agent – служба (см. выше), запускаемая на узлах (компьютерах) сети, где имеются БД под Oracle. Выполняет контролирующую роль; без нее, например, нельзя полноценно запускать и останавливать удаленные базы в сети.

Data Gatherer – еще одна служба на узлах с базами данных. Без них невозможны многие операции по извлечению данных из удаленных баз.

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

Таким образом, в сети должен иметься хотя бы один Management Server (а может быть и больше), и, соединяясь с ним (с того же узла, где он расположен, или с любого другого, где имеется “клиентское” ПО OEM – не имеет значения) администратор может наблюдать и контролировать работу всех имеющихся баз.

Как установить Management Server

Дальнейшее изложение будет подразумевать NT. Любители Unix обыкновенно достаточно продвинуты, чтобы сообразить по тексту ниже, как все будет выглядеть в их среде.

В Start Menu выбираем Enterprise Manager -> Configuration Assistant. В появившемся окошке нужно выбрать создание нового репозитария. Система предоставит вам первый выбор - указать пользователя и пароль:

А фактически здесь требуется указать имя пользователя Oracle, который будет создавать репозитарий для Management Server. Естественно, что для этой цели такому пользователю нужно будет обладать определенными административными полномочиями: он создаст владельца репозитария, табличное пространство и так далее. Простая кандидатура на это – SYSTEM, хотя вы вправе указать кого-нибудь еще.

Существующую БД, в которой будет все это новое хозяйство создаваться, нужно указать в поле Service в предложенном формате (имя_компьютера:порт:имя_БД).

Следующее окошко попросит у вас указать вторую пару пользователь/пароль:

Здесь спрашивается уже имя владельца репозитария. Именно его сейчас создаст по нашему указанию SYSTEM, фигурировавший в предыдущей форме, в качестве системного пользователя Oracle. (Проделав все шаги, вы сможете потом увидеть его среди прочих пользователей в базе TEC6). В принципе, имя неважно, но назвать его именем узла, на котором находится база, – как это предлагает Oracle – разумно.

Дальнейшее довольно просто. У вас спросят название и местонахождение табличного пространства для репозитария, и сам репозитарий (следом за пользователем Oracle – владельцем репозитария) будет создан.

Итак, Management Server создан.

Продолжение статьи