30 ноября 2010 г.

SAP GUI for Windows, patches and hotfixes

На данный момент SAP поддерживает следующие версии SAP GUI for Windows:
  • SAP GUI 6.20 - окончание поддержки 31.12.2010,
  • SAP GUI 7.10 - окончание поддержки 12.04.2011,
  • SAP GUI 7.20 - окончание поддержки 09.04.2013.

Список поддерживаемых ОС начинается с Windows XP/Windows 2003 Server (состояние de-support, что означает - поддерживаем, но предлагаем сделать апгрейд), заканчивается Windows 7. Windows 2000 не поддерживается с 13.07.2010.

Получается, что в качестве оптимальной рабочей станции необходим компьютер под управлением Windows 7 или Windows Vista (окончание основной поддержки в 2012 году и выход на de-support со сроком до 2017 года) с SAP GUI 7.20. В крайнем случае Windows XP (Windows 2003 Server).
У меня на работе и дома стоит связка Windows XP + SAP GUI 7.10 last SP.

Теперь еще один новый нюанс. Для SAP GUI 7.20 вышел уже 3-й SP, который можно скачать с SAP Support Portal. Так как частота выхода SP для SAP GUI составляет 6-8 недель SAP ввел такое понятие как HotFix для SP. Это пакеты поддержки, которые выходят между основными SP для SAP GUI и содержат критические исправления. Относятся к конкретным SP (PL в описании) и устанавливаются так же как SP для SAP GUI (закрываем все окна SAP Logon и запускаем *.exe файл с пакетом поддержки). Подробности по поводу HotFix для SP для SAP GUI можно прочитать в SAP note # 1489891 - Hotfixes for SAP GUI for Windows 7.20.


Еще две полезные нотки:

Держите нос по ветру. ;)

Автор: Шиболов Вячеслав Анатольевич


18 ноября 2010 г.

ORACLE 8i, ORA-01555


В ORACLE 8i используются сегменты отката (ROLLBACK SEGMENTS) и ручное управление информацией отката. В табличном пространстве, обычно это PSAPROLL, находятся сегменты отката (типичные имена PRS_0, PRS_1, ...). Данные сегменты используются для отката/восстановления транзакций, обеспечения целостности чтения из базы (блоков данных, которые в данный момент времени изменяются) и для команд чтения данных на предыдущий момент времени. Количество сегментов отката можно посмотреть через транзакцию DB02. Все сегменты отката прописаны в профиле init<SID>.ora. Если меняете их количество, то не забудьте внести изменения в профиль.

Если возникает дамп в системе, который ссылается на ошибку СУБД ORA-01555 (ORA-01555: snapshot too old: rollback segment number <rbs_nr> with name "<rbs>" too small), то это про них, родимых.

Привожу список полезных SAP note по этой теме:


Если возникает именно ORA-01555, то стоит обратить внимание на параметр OPTIMAL у ROLLBACK SEGMENTS. Мне правильное выставление его позволило увеличить время хранения информации в ROLLBACK SEGMENTS с 3 до 6 часов. Частота дампов с ошибкой ORA-01555 резко уменьшилась. Порядок и SQL-запросы для пересоздания сегментов отката можно найти в вышеуказанных нотах.

Начиная с ORACLE 9i, сегменты отката (ROLLBACK SEGMENTS) переименованы в сегменты отмены (UNDO SEGMENTS) и появилось автоматическое управление данными сегментами. Задача администратора в этом случае сводится к активации/мониторингу этого режима и создании/поддержании UNDO табличного пространства достаточного размера.

Автор: Шиболов Вячеслав Анатольевич


17 ноября 2010 г.

Буферы ORACLE

Продуктивная система SAP R/3 4.6C с ORACLE 8.1.7.4.0 в качестве СУБД. В системе ежедневно порядка 600 активно работающих пользователей. Размер базы данных около 400 Гб. Были проблемы с производительностью. Среднее время отклика системы в среднем по диалоговым инстанциям стало 3000 мс. На наиболее загруженных серверах приложений доходило до 13000 мс!
После анализа ситуации было решено увеличить параметры памяти ORACLE (профайл init<SID>.ora):


После этого (параметры вступают в силу только после перезагрузки базы данных) картина загрузки дисков на дисковом массиве стала выглядеть иначе.
  • было:


  • стало:

Первый график (синяя кривая) - загрузка дисков в процентах. Второй график (красная кривая) - время ожидания запросов в очереди к дискам в мс. Графики взяты за рабочий день с высокой нагрузкой.

Среднее время отклика системы в среднем по диалоговым инстанциям стало 1000-1200 мс, уменьшение произошло за счет "Времени БД". На наиболее загруженных серверах приложений доходит лишь до 1500-2000 мс.

Увеличение параметров происходило в 2 этапа. Это видно на первом скриншоте. Второй этап имел меньшую эффективность, поэтому дальнейшее увеличение параметров пока не планируется.

Начиная с версии ORACLE 9.2 параметры немного изменились, их стало меньше.

Полезная SAP note на эту тему:
Note # 789011 - FAQ: Oracle memory areas.

Вывод: не зажимайте ORACLE, дайте ему тоже поработать.

Автор: Шиболов Вячеслав Анатольевич


13 ноября 2010 г.

Spool в системе SAP R/3 4.6C и поддержка со стороны SAP

Имеем систему - SAP R/3 4.6C, Oracle - 8.1.7.4.0, SAP_BASIS - SAPKB46C57, sap kernel 46D - 2364 patch level.
Система, мягко говоря, не первой свежести, но я думаю, что используется такая версия еще часто. Так вот, после 01.2008 sap kernel 46D не поддерживается компанией SAP и обновления для ядра не выпускаются. Предлагается переход на ядра 46D_EXT или 46D_EX2, которые требуют версию ORACLE не ниже 9.2. На днях на ландшафте клиента было обнаружено, что запросов в spool хранится больше, чем обычно. Разбор полетов показал, что стандартное фоновое задание SAP_REORG_SPOOL работает в холостую и ни одного запроса в spool не удаляет.


Данное задание запускает в фоне программу RSPO0041 (SAP note # 41547) с вариантом SAP&001. Вариант представляет из себя следующее:


То есть фоновое задание запускается ежедневно и удаляет "Устаревшие запросы в спул". У каждого запроса в spool (spool request) есть "Дата удаления" (Delete data), которая формируется по формуле: дата создания + 8. Число 8 берется из параметра инстанции rspo/req_lifetime, который можно установить в значения от 1 до 8. Анализ запросов в spool показал, что совершенно у всех запросов в поле "Дата удаления" стоит - 01.01.2100!
Была найдена SAP note # 1422843 - Wrong deletion date in spool request, в которой описана проблема, возникающая после 23.12.2009. Данная проблема исправляется ручными манипуляциями + установкой новой версии sap kernel. Но так как в данной системе без апдейта ORACLE обновление sap kernel невозможно, решено было удалить фоновое задание SAP_REORG_SPOOL и запланировать периодическое (ежедневно) выполнение программы RSPO0041 со следующими опциями:


"Пора-пора делать upgrade...", - шепчет компания SAP на ушко своим клиентам. ;)

Автор: Шиболов Вячеслав Анатольевич