Коллеги, есть слабенький сервер, санфайр 240, с 2-мя процессорами по 1.5ГГц, 8Гб памяти. я всё понимаю, слабое железо. фиг с ним.
на нём в данный момент считается з/п на 6000 человек за май (1 мес.)
считается в ERP 2004 SR1

в джобах висит процесс. уже 3,5 часа. я пытаюсь понять - где тормоза (кроме железа, это и так ясно)

по top'у загрузка только у ворк-процесса - 49.88% disp+work, оракл при этом не загружен 0.34% oracle (иногда конечно до 2..4% прыгает)

в логах трейсов (st05) есть операции (FETCH, REEXEC например) по 8..15 сек. суммарно набегает порядочно.

в логах st01 (только на SQL включал) - инфы побольше, но не очень понятно, какая операция. времена есть большие. от 8 до 200 сек - я не очень понимаю что это за операции такие. как это определить? можно провалиться в абап, но там рядовые селекты.. я склоняюсь к тому, что это FETCH (не могу нигде найти, что SAP понимает под FETCH) так долго выполняется. можно как то ускорить это дело??? соптимизировать?

вопрос то у меня простой - что ж это воркпроцесс так нагружен, а БД нет? прочесть бы гденть, как оно работает... такое впечатоение (не претендую на правильность) - что оракл быстренько всё выбрал, отдал апликейшену, а тот начинает в свои НЕ оракловые таблички как то косо распихивать. как на самом деле??

Для начала можешь в SCI посмотреть

посмотрел.. саповские проги непогрешимы
не даёт проверить HRUCALC0. в набор не добавляется.

Можно попробовать скореллировать длительные FETCH по таблицам с информацией в ST04 по тем же таблицам и посмотреть из-за чего операция с базой подвисает: возможно с индексами или статистикой проблемы...

Как правило, запросы из САПа в оракл идут не очень сложные.

По производительности ST02, ST04 - по минимуму "красноты". Особое внимание - экстендед мемори. Ораклу главное, чтобы кволити в буф. кэше и шаредпуле было не ниже 98%. Остальное практически по барабану.

Далее, надобно смотреть. Если хочется пооперативнее - ST04 -> Detail analysis menu -> Oracle sessions (покажет примитивные САПовкие запросы в Оракл) и SAP client (Кстати на него ноту надо накатывать - может и не работать).

Обычно делаю SM50 + F8(refresh) - практически сразу видно кривизну, табличку к которой обращается запрос(ы), съеденное процессорное время, автора и т.д.

PS Я обычно просто беру этот оракловый запрос(как его посмотреть см. выше) и работаю с ним. Например, как вариант делаю индекс и регистрирую стандартным способом.

в sm50 табличку не рисует.. как не жми рефреш. отчёт (в sm50) называется SAPLHRPL хотя в джобе запускался HRUCALC0. никакого криминала на сапнете по ним не нашёл. при трейсе sql - есть много табличек - время операций с которыми огромное. до 96 сек. например PCL2. и вообще нет индекса. как такая кривизна могла пролезть??

все кволити у меня по 99.8%. оракл НЕ грузит проц. какие то доли процента.. а вот ворк-процесс саповский - 49.80% disp+work. что он такое делает уже 8 часов? при этом расчиталось всего 500 или 600 сотрудников )).
я не верю что железо (типа мощное) даст какой то дикий прирост производительности... это какая то кривизна с алгоритмом...

не знаю, у меня гуй 620-ый все рисует и в R/3 и в BW. Должно быть примерно так (... x00-клиент ФИО Последов. считывание(значится на синглриде - по индексу тоесть, или "Прямое считывание" - понятно, что директскан) VBRP(типа табличка/объект))
Но спорить не буду.
Тогда просто SM66 - если сессия в активе - покажет.

Вообще не плохо было бы уточнить тип системы. Это R3/BW?
Судя по SAPLHRPL - это HR Payroll Protokollie, стало быть R/3???
Видимо немного кастомизировали, это скорее всего к разработчикам.
Надо изучать проблему более подробно.

Рассуждаем логически:
1. Процессора хватает (даже до 50% не дотягивает).
2. Красноты нет в ST02?
3. Если нет, тогда смотрим на частоту swap в ST06.
4. Если там все неплохо, то проблема на уровне Oracle. Большое время выборки: либо диски слабы, либо запросы не оптимизированы:
5. Диски - опять в ST06. Загрузка менее 100% и очереди нет?
6. Тогда смотрим на запросы: либо оптимизатор ошибается (старая статистика), либо сами запросы в программе написаны плохо.

Согласен с PK6, но на статистике если она хоть раз в месяц собирается много не выиграть. Нужно проверять код. Типичная для САПа ситуация, когда запрос идет по индексу, вроде все верно. Но.... Индекс некий пикей из 10-ка столбцов, а в запросе в WHERE 2-3 из них, а может есть 4-ый которого вАпче нету в этом PK . Это просто "НАПРИМЕР".

Значится делаем индекс по тем столбцам, которые нам интересны. Ес-но проверяем на тестовой системе и смотрим на скорость. Если эффект есть - транспорт в продуктив.

Подобный анализ и оптимизация - это долгая и кропотливая работа.

PS ИМХО А "по хорошему" серьезную проверку системы надо начинать сначала. Например, с количества симафоров в /etc/system

в общем кое как решилось.

1. убрал "красноту" в st02 - хоть и не очень критично. мало её.
2. добавил пару индексов к паре таблиц - тут канечно полный кавардак. даже странно что их постоянно не хватает. фигня какая то.. . насчот запросов и составных индексов полностью согласен с Victor.
3. но глобально всё решилось рачётом пачками по 200..300 табельных номеров. вот тут как говорится карта пошла ) память сосёт со страшной силой расчёт этот. где то на 200-ом табельном - уже 2.5 гига жрёт процесс - дальше - хуже. потом начинает свопить. потом уже вообще в час по чайной ложке...
4. запуск параллельно двух расчётов - система загрузила оба проца на 100%, а до этого только 1.

да, система какая - в первом посте я описал. все /etc/system, размеры свопа, etc - из инсталл гайда.

в общем проблема можно сказать решена, всем спасибо за советы.

Стоп!

Сегодня считаем зряплату

А проблема то известная! Сорри, сразу как то не разобрался!

Последовательность должна была быть такой.

1. SE38 - > Свойства (продукт от SAP), т.е. это просто некая настраиваемая байда мейд ин Воллдорф и значится местные умельцы вринципе нипричем.

2. SM50 - смотрим SPID(серверный пид)

3. ST04 - > Det analysys menu - > Oracle sessions Нету там ничего ораклового!

Это впринципе НЕ ОРАКЛ, а САП(АБАП)
Т.о. орАкла тут вообще нипричем! Вот прямо сейчас вижу перед собой целую кучу "SAPLHRPL". Даже делаю "напрямую"

--PID & SID
SELECT s.sid, s.serial#, p.pid, p.spid "Server PID", s.user#, s.username, s.osuser,
s.status, s.lockwait, s.terminal, s.program, s.logon_time
FROM v$session s, v$process p
WHERE s.paddr = p.addr
--and p.spid in (16067, 16001, 16243)
and p.spid = 2513
ORDER BY 4;

Ну нету таких SPID-ов в оракле! Это "Чиста АБАП"!

Тут тока либо действительно пачками(кстати, надо будет попробовать),
либо количеством процессоров. И никак иначе. Это "Родное приложение" его и при горячем желании не улучшить.

ðàçäåëÿé è âëàñòâóé!

что не оракл - я ж сразу в первом посте сказал - он НЕ грузил проц вотще.
вопрос вот какой - если есть в табличке (некоей) составной индекс из десятка полей, и есть селект по паре полей входящих в этот индекс - то сап (это же абап, не оракл) юзает этот индекс? или надо свой навешивать?? вот никто не может мне точно ответить...

А что Вам мешает оттрассировать селект?

abap вообще никаких индексов не использует... А вот используется индекс сервером БД можно посмотреть в плане выполнения запроса в SQL trace (ST05)