Oracle 11g и SAP

На Service Marketplace наткнулся на следующие ноты:
1339724 - Oracle 10.2 Extended Support free until July 31, 2011
1398634 - Oracle database 11g: Integration in SAP environment

В связи с этим возникает вопрос об необходимости и целесообразности перевода существующих систем SAP на Oracle 11g.

Что поэтому поводу думаете Вы?

Ошибка при импорте пакетов в ABAP

Во время фазы импорта XPRA_EXECUTION возникла ошибка:
TP_STEP_FAILURE - Return code: 0012
Помогло выпонение сброса буферов:
/$SYNC
(http://forums.sdn.sap.com/thread.jspa?threadID=1560652)

Подручные средства

Если небходимо распаковать архив zip на сервере AIX и нет возможности установить штатный архиватор:
1. Если устанвлена java, то можно использовать jar -xvf
2. Если установлен Oracle, то unzip расположен в $ORACLE_HOME/bin.

Осторожнее с рекомендациями

При изучении отчетов EarlyWatch многие игнорируют раздел Database Settings. "Но он ведь там не зря.." = подумал я. И решил привести параметры базы данных к рекомендованным.
Сначала изучил ноту SAP 830576. Наиболее сложным оказался параметр PROCESSES. Он вычисляется по формуле:
#ABAP work processes * 2 + #J2EE server processes * + PARALLEL_MAX_SERVERS + 40
Количество рабочий процессов ABAP (#ABAP work processes) можно посмотреть через транзакции SM50/SM51
Процессов сервера J2EE (#J2EE server processes) всего 2 (сервер сообщений и собственно сама Java-инстанция)
Значение параметра определяется следующим образом:
1. Запускаете Visual Administrator
2. Раскрываете узел server -> services -> JDBC provider
3. Открываете закладку "Properties"
4. Проверяете значение поля max no. of connections (по умолчанию 100)
Если имеется более одной Java инстанции необходимо к этому значению прибавить значения параметра для каждой инстации.
(http://forums.sdn.sap.com/thread.jspa?threadID=1502920&tstart=75)
Параметр PARALLEL_MAX_SERVERS вычисляется по формуле #DB-CPU-Cores * 10, где #DB-CPU-Cores - количество процессоров на сервере базы данных. В случае, если база данных и система расположены на одном и том же сервере, то полученное значение делится пополам или #DB-CPU-Cores * 0,5 * 10.
Параметр LOG_BUFFER вычисляется Oracle самостоятельно. Также можно отключить проверку этого параметра в DB17.
Еще один параметр, который заслуживает внимания это LOG_ARCHIVE_DEST_1. В ноте указано, что он должен иметь значение: "LOCATION=/oraarch/arch". Здесть таится опасность, если у Вас установлены параметры LOG_ARCHIVE_DEST или LOG_ARCHIVE_DUPLEX_DEST, то использовать LOG_ARCHIVE_DEST_1 нельзя. Это приведет к невозможности запуска базы данных. Что собственно произошло со мной. Но по порядку.
после корректировки параметров базы данных был осуществлен перезапуск системы. И тут выяснилось что не стартует база данных. В журнале /home/savadm/startdb.log была обнаружена ошибка:
ORA-16019: cannot use LOG_ARCHIVE_DEST_1 with LOG_ARCHIVE_DEST or LOG_ARCHIVE_DUPLEX_DEST
Порядок исправления был такой:
1. Регистрируемся как ora
2. Запускем sqlplus /nolog
3. Выполняем команду CREATE PFILE [='pfile_name'] FROM SPFILE [='SPfile_name'];
4. Удаляем неправильный параметр из pfile
5. Выполняем команду CREATE SPFILE FROM PFILE [='pfile_name'];
6. Перезапускаем систему.

Я еще выполнял команду STARTUP NOMOUNT между шагами 2 и 3, но не уверен что это необходимо.

Непотопляемый cron...

Сегодня возникла необходимость в остановке cron в AIX. Оказалось не все так просто. Простая команда kill ничего не дает. После поисков в Google, выяснил что для остановки демона необходимо выполнить следующее:

- отредактированть файл
/etc/inittab, используя команду vi /etc/inittab
- в нем найти строку
cron:23456789:respawn:/usr/sbin/cron
- закомментировать её
:cron:23456789:respawn:/usr/sbin/cron
- сохранить файл
- выполнить команду
init q

Для запуска необходимо строку раскомментировать и снова выполнить команду.

Индексы, индексы....

Все началось с отчета EarlyWatch, согласно которому на BW-системе перестала собираться статистика базы данных (Oracle). Изучение лога задания по обновлению статистики показало, что причиной тому ошибка:

ORA-20000: index "SAPSR3"."/BIC/B*KE" or partition of such index is in unusable state

Сначала бы надена нота 1235952 - Minor functional enhancements in BR*Tools (пункт 6) и предпринята попытка пересоздать индексы с помощью команды

brspace -u / -c force -f idrebuild -i unusable

Команда выполнялась от имени пользователя ora<sid>.
Каково же было удивление, когда на следующий день индексы стали опять "unusable". Выснилось, что эти индексы "бивишных" PSA-таблиц и при удалении данных они разваливались, хотя должны были просто перестроится.
Затем на форуме sdn.sap.com была найдена следующая ветка https://www.sdn.sap.com/irj/scn/thread?messageID=6483705#6483705, где упоминалась нота 1042182 - Secondary index is inconsistent for PSA tables и отчет RSAR_PSA_PARTITION_CHECK. При прочтении ноты было вычитано следующее:

Depending on the scenario, a secondary index can also be created automatically in the background when you use semantic groups.
A secondary index for access optimization when reading from a DataSource must be created locally or in partitions for 'ORACLE' database systems if tables are partitioned.

Проверка с помощью отчета показала, что все разваливщиеся индексы не были локальными. Запуск отчета в режиме "REPAIR' конвертировал индексы в локальные и создавал их заново. Проверка с удалением данных показала, что индексы перестали "разваливаться".
После этого операция была проведена на продуктивной системе.
Вот оно счастье. :)

Начало...

Сейчас многие ведут блоги. Это модно и даже иногда бывает полезно. Вот и я решил завести свой блог. Я постараюсь, чтобы он был полезен и интересен. Итак в путь...