Добрый день.

Сразу скажу, базисом занимаюсь недолго, при чем начал на Win + Sybase ASE, но по неведомым причинам все свернулось и меня попросили. Сейчас работаю с HP-UX(будь он неладен) + Oracle. На данный момент система разработки и QA периодически тупят. Нашел массу транзакций, с их помощью можно наблюдать и анализировать производительность системы. Но вот смотрю я на все эти таблицы и параметры, время выполнения и шаги и не понимаю, как мне оценить? Мне эти цифры ни о чем не говорят, много или мало это? Есть ли какие то мануалы с подробным описание всех этих дел или как вообще производится анализ производительности систем?

Курс ADM315. Думаю не стоит со своим уставом в чужой монастырь... Не даст вам особо ничего миграция на Windows. При чем, транзакции для мониторинга останутся те же.
По поводу мониторинга пару слов: сначала всегда смотрим в SM50, обновляем, смотрим как загружены процессы (диалоговые, фоновые и тп). Далее ST03n - анализ бизнес-транзакций - загрузка последних минут, ключевое поле dialog - среднее время реакции. Мое мнение, более 1000 мс - уже плоховато. Упрощенно, среднее время говорит, сколько система думает, пока человек нажал какую-либо кнопку в транзакции. Там же можно посмотреть доли времени. Обычно половина времени реакции это БД, вторая половина время обработки в процессоре.
Так же транзакция STAD (STAD, выбрать параметры, нажать enter), в ней можно посмотреть это подробнее, там видно на что тратилось время в каждом шаге транзакции. ST06 просмотр данных с уровня операционки. ST02 буферы. Если есть красные строчки, и они увеличиваются более чем на 10000 в сутки - значит нужно править профильные параметры для увеличения размера буферов. Эти параметры ST02 подскажет кнопкой Current Parameters. DBACOCKPIT - транзакция мониторинга базы данных.

* Задумчиво:
Весь опыт буйных лет в десятке строк...

И вновь я благодарен Вам RikoNw. Миграция мне нужна для упрощения обслуживания и повышения отказоустойчивости(все переведу в виртуальную среду) + я много работал и с виндами и в виртуализации кое-что понимаю. А вот веселье с HP-UX на Ia64 меня совсем не радует, ни виртуализировать, ни поднять его на какой нидь тачке для тестов, ибо случайно завалявшихся серверов и десктопов на итаниумах нет -=)
Буду пробовать на практике Ваши предложения.

Ах вот оно что, IA... Тогда вопросов нет
Успехов!
P.S. Хотя миграция на винду все-равно спорна, лучше бы SLES/RHEL

* Ещё более задумчиво
и ни слова про долгоиграющие селекты. у юноши, возможно, много интересного впереди.

Много много -=)

Ну вот читаю я АДМ315, штука хорошая, но можете на примере показать, что и как анализировать. К примеру в документации написано, что если processing time more than twice CPU time:CPU bottlenecks, т.е. на тянут процы? Ну это если судить по суточной статистике в ST03n, а там как раз процессинг тайм больше цпу тайм в 2 с лишним раза, ну ведь это усредненный результат и значит что у кого то нормально работало, а у кого то безбожно тупило... Но я сомневаюсь что 4 4-яйцевых итаниума не справляются...

А кто сказал, что это процы не тянут? Может они просто терпеливо ждут завершения ввода/вывода с тормозной дисковой системы?
Чтобы говорить о загрузке процессоров смотреть надо на уровне OS.

А минуя ОС, я могу по статистике из SAP понять в чем проблемы? Или все такие сначала нужно смотреть ресурсы на уровне ОСи? Точно дело не в процах.

Понять в чем проблема - это очень оптимистично
Увидеть проблему - да, чаще всего можно. Но все равно проблемы решаются головой.
Т.е. увидеть тормоза в системе, зайти в st06 и увидеть CPU I/O Wait 40-50% - это сразу понятно, что тормозят диски. Тоже самое можно увидеть и с уровня оси. Не помню, как это в чпуксах, а в линухах - iostat
А вот потом начинается самое интересное - понять ПОЧЕМУ тормозят диски.
Может базу надо подкрутить, может по дискам неправильно база и логи раскиданы. Вариантов чуть больше чем много. А может кто-то из юзеров запустил какой-то специальный z-отчет
С загрузкой процессоров - таже беда, надо искать причину. Т.е. что с уровня оси, что в системе в st06 нет явных указаний где и что надо сделать.
А процессоры, кстати, могут быть и не загружены, и I/O wait приличный, а все еле ползает.
А тогда уже надо смотреть по свопам объектов из кеща аппликухи (st02). Т.е. подкручивать аккуратненько буфера в профиле. А это требует перезапуска системы и недельки на набор статистики
И опять же все упрется в умные мысли и большую практику.
А все индикаторы в системе или на оси - это только индикаторы. Голова у человека может болеть от многих причин. И в лечение для разных случаев будет разное. Также и здесь.

Согласен, но для начала бы научиться определять кто виноват, а вот почему это уже понято, что отдельная история и никто явно не скажет где и какую кнопку нажать -=)
Благодарю...

Для Linux
iostat -xk -t 10 | awk '// {print strftime("%Y-%m-%d %H:%M:%S"),$0}' - воводить общую загрузку дисков за последние 10 секунд
iotop - вывод процессов, наиболее загружающих дисковую подсисетму
htop - показатель Load average даст понимание, сколько запросов на выполнение стоит в очереди на процессор. Вообще, говорят больше 2 уже напряг, я бы сказал больше 5 - система нагружена плотненько, если это значение постоянно такое - процы не справляются.

Для HP есть чудная утилита - glance ...Очень много чего видно о состоянии пациента.
Да и вообще - шикарная на мой взгляд платформа, просто так мигрировать с неё на мой взгляд - преступление...