понедельник, 28 марта 2011 г.

Установка Oracle DB 11g на Fedora 14

Возникла необходимость установить Oracle 11g на домашнюю машину под управлением Fedora 14. Процесс установки описывать целиком смысла не вижу.
Особенности для неподдерживаемой платформы:
1. Предлагаем системе притвориться пятым редхатом echo "redhat release 5" > /etc/redhat-release
2. Проблемы с "несовместимостью gcc" есть теперь и для Oracle !
При установке получаем ошибку:
Error in invoking target 'agent nmhs' of makefile'/app/oracle/product/11.2.0/sysman/lib/ins_emagent.mk'




Почитав интернет, можно найти два решения:
в процессе установки подкорректировать файл 
$ORACLE_HOME/sysman/lib/ins_emagent.mk
Заменив в нём $(MK_EMAGENT_NMECTL) на $(MK_EMAGENT_NMECTL) -lnnz11



Второй вариант - найти вот такой архив в дистрибутиве
../stage/Components/oracle.sysman.agent/<версия>/1/DataFiles/filegroup40.jar
в нём редактируем файл env_emagent.mk так же, как и в первом случае.
Должно помочь.

четверг, 24 марта 2011 г.

Пример конфигурирования домена Weblogic

Примеров конфтгурирования доменов Weblogic в сети достаточо много. К ним у меня есть только одно существенное дополнение. В сколько-нибудь production-среде weblogic сервера ассоциируются с машинами. AdminServer - тоже сервер, и его тоже неплохо бы расположить на машине. Лучше отдельной.
Для порядка, чтобы "всё было" выложу тут пару скриншотов. Поупражняюсь во вставке картинок в блог, заодно.

понедельник, 21 марта 2011 г.

Перенос конфигурации домена

Немного теории о том какакие существуют утилиты для создания, модификации и переноса доменов weblogic.

1. Утилита config.sh - в процессе настройки домена не генерирует его с чистого листа. Она предоставляет интерфейс для редактирования шаблонов из папки
$DOMAIN_HOME/wlserver_10.3/common/templates/domains
и интерфейс добавления к существующему домену изменений на основе всё тех же шаблонов, сгенерированных, например, утилитой config_builder.sh
2. Утилита config_builder.sh генерирует шаблон домена целиком с возможностью добавлять собственные конфигурационные скрипты или генерирует шаблон изменений. Утилита может генерировать шаблон на основе существующего и работающего домена. Полученные с её помощью jar-архивы можно скормить config.sh или отредактировать с помощью консоли WLST.
3. C помощью weblogic.WLST можно сделать практически всё. В частности, можно отредактировать шаблон с доменом, используя те же самые команды конфигурирования, что и для развёрнутого домена.
Открываем шаблон:
wls:/offline/ > readTemplate('template.jar')
Редактируем
wls:/offline/base_domain > create('...')
Сохраняем
wls:/offline/base_domain >writeTemplate('newTemplate.jar')
 4. С помощью weblogic.WLST можно запускать jyton-скрипты. Этот способ переноса домена не использует шаблоны и не позволяет перносить дополнительные файлы и директории. Из основных его плюсов стоит отметить простоту использования. Вот пример команды, генерирующей скрипт:

$ configToScript('/path/to/domain','script.py')

и команды разворачивающей на его основе домен:
$ weblogic.WLST script.py
Стоит отметить, что скрипт перенесёт не только конфигурационные файлы, но и файлы с паролями, например boot.properties, если такой файл был создан.

5. Утилита pack позволяет создать архив для переноса домена целиком или для переноса отдельного его сервера. Генерируя архив для перноса управляемого сервера, утилита не включает в него некоторые файлы, например  SerializedSystemIni.dat. Об этом надо просто помнить и следовать инструкциям Oracle по поднятию Managed серверов.

6. В поставку weblogic включён так же скрипт clone.sh
Утилита клонирует файлы из каталога с доменом. Что именно копировать, можно указать в лежащем рядом конфигурационном файле clone.xml.
Важная особенность: можно воспользоваться этим способом только если совпадают директории установки приложений на development  и production средах. Я не очень углублялся в возможности этой утилиты. На первый взгляд она очень напоминает копирование.

7. При должном понимании того, что делаешь, можно перенсти сервер простым копированием файлов.

Oracle предлагает несколько способов разворачивания production-среды, видимо, намекая на то, что не нужно конфигурировать production домен от самого Simple Domain Template

Установка

Установка Weblogic достаточно проста, но есть несколько особенностей.
1. Надо не забыть, что в системе может быть установлена собственная опенсорсная или любая другая Java-машина и заранее определить путь к той, которую мы хотим использовать.
export JAVA_HOME=/opt/oracle/java/latest/bin/java
export PATH=$JAVA_HOME/bin:$PATH 

2.  для 64 битных систем указываем ключик  -d64. У меня это JAVA64=-d64
3. Я использовал файл ответов, отчего нашёл ещё одну "особенность" установки.
В файле ответов, предлагаемом Oracle, присутствуют линшние символы переноса строки.
Если копироваь файл со странички, и подсовывать в качестве файла ответов, получим ошибку
The local BEA product registry is corrupted

лечится очень просто. Удаляем все лишние пробелы в разделе "COMPONENT_PATHS" В итоге получаем что-то вроде

echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
   <bea-installer>
     <input-fields>
       <data-value name=\"BEAHOME\" value=\"${BEA_HOME}\" />
       <data-value name=\"WLS_INSTALL_DIR\" value=\"${WL_HOME}\" />
       <data-value name=\"COMPONENT_PATHS\"
        value=\"WebLogic Server/Core Application Server|WebLogic Server/Administration Console|WebLogic Server/Configuration Wizard and Upgrade Framework|WebLogic Server/Web 2.0 HTTP Pub-Sub Server|WebLogic Server/WebLogic JDBC Drivers|WebLogic Server/Third Party JDBC Drivers|WebLogic Server/WebLogic Server Clients|WebLogic Server/WebLogic Web Server Plugins|WebLogic Server/UDDI and Xquery Support|WebLogic Server/Server Examples\"/>
       <data-value name=\"INSTALL_SHORTCUT_IN_ALL_USERS_FOLDER\" value=\"no\"/>
       <data-value name=\"LOCAL_JVMS\" value=\"${JAVA_HOME}\"/>
     </input-fields>
</bea-installer>" > /tmp/silent$$.xml

Запускаем
java ${JAVA64} -jar ${WL_DISTRIB} -mode=silent -silent_xml=/tmp/silent$$.xml
Готово.