ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Мониторинг производительности сессии
24 сообщений из 24, страница 1 из 1
Мониторинг производительности сессии
    #35769235
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Вот возникла очередная задача при переходе с Оракла на ДБ2. Нужно определить проблемы производительности сессии. Есть сессия, которая посылает базе запросы типа INSERT, UPDATE, DELETE, SELECT.

1. Нужно определить суммарное время затрат ЦПУ, суммарные ожидания по видам.
2. Кроме того такую же статистику нужно получить для каждого отдельного запроса дабы выяснить, какие запросы расходуют ЦПУ, какие долго ждут и почему.

В Оракле для решения задачи 1 есть системные представления в которых собирается сессионная статистика. После отработки теста я могу точно сказать, сколько база потратила ЦПУ на мою сессию, сколько она ждала на дисковых операциях по чтению, по записи и пр.

Для решения задачи 2 есть сессионные трейсы, которые собирают статистику в разрезе отдельных запросов - планы запросов, сколько фетчей было сделано по запросу, сколько физических чтений с диска, сколько чтений из кеша и пр.

Какие средства ДБ2 нужно использовать, чтобы получить аналогичные результаты. Ткните, пожалуйста, в правильную доку и статьи. Доку "Tuning Database Performance" изучаю.
...
Рейтинг: 0 / 0
21.01.2009, 13:26
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35769446
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_ду,

Почитайте тут про create event monitor.
...
Рейтинг: 0 / 0
21.01.2009, 14:31
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35778098
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Mark Barinsteinшубин_ду,

Почитайте тут про create event monitor.

Прочитал, попробовал, но остается много вопросов. Например, каждый запрос записывается в таблицу мониторинга STMT_XXX 4 раза. Разборки выявили отличие в колонке STMT_OPERATION. Это поле числовое. Значения 1,4,7,6. В доке System Monitor Guide and Reference в описании STMT_OPERATION приводятся однако строковые значения SELECT, PREPARE, EXECUTE. Из чего сделал вывод, что каждая строка в STMT_XXX соответствует фазе исполнения запроса. Но как сопоставить числа строковым значениям?

Собственно вопрос даже не столько в этой частности, сколько в том, есть ли описание методики тестирования производительности в виде док, статей, книг и пр.? Где было бы написано как правильно интерпретировать результаты event monitoring. Пока поиски ничего не дали. Может есть какой-нибудь классический источник, в котором представлены основные методики?
...
Рейтинг: 0 / 0
26.01.2009, 17:00
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35778282
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_дуПрочитал, попробовал, но остается много вопросов. Например, каждый запрос записывается в таблицу мониторинга STMT_XXX 4 раза. Разборки выявили отличие в колонке STMT_OPERATION. Это поле числовое. Значения 1,4,7,6. В доке System Monitor Guide and Reference в описании STMT_OPERATION приводятся однако строковые значения SELECT, PREPARE, EXECUTE. Из чего сделал вывод, что каждая строка в STMT_XXX соответствует фазе исполнения запроса. Но как сопоставить числа строковым значениям?ищите в ...\sqllib\include\sqlmon.h по строке "Statement Operation Types".
шубин_дуСобственно вопрос даже не столько в этой частности, сколько в том, есть ли описание методики тестирования производительности в виде док, статей, книг и пр.? Где было бы написано как правильно интерпретировать результаты event monitoring. Пока поиски ничего не дали. Может есть какой-нибудь классический источник, в котором представлены основные методики?
Best practices for DB2 for Linux, UNIX, and Windows .
Ищите там по "Tuning".
...
Рейтинг: 0 / 0
26.01.2009, 17:49
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35778290
mitek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mitek
Участник
шубин_ду Может есть какой-нибудь классический источник, в котором представлены основные методики?
Можно здесь и здесь посмотреть для начала
...
Рейтинг: 0 / 0
26.01.2009, 17:50
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35778402
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Спасибо, Mark и mitek,

буду разбираться дальше
...
Рейтинг: 0 / 0
26.01.2009, 18:33
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35781140
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Протестировал приложение с использованием SYSIBMADM.SNAPAPPL.

ELAPSED_EXEC_TIME_S + ELAPSED_EXEC_TIME_MS/1000000.0 действительно показывают правду. Полученное значение очень близко к значению которое получаем из клиента путем вычитания время завершения приложения из времени старта. Но из каких компонент состоит ELAPSED_EXEC_TIME непонятно. Смастерил вот такой запрос:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
select
   ELAPSED_EXEC_TIME_S + ELAPSED_EXEC_TIME_MS/ 1000000 . 0  as ELAPSED_EXEC_TIME,

   POOL_READ_TIME/ 1000 . 0  + POOL_WRITE_TIME/ 1000 . 0  + DIRECT_READ_TIME/ 1000 . 0  + DIRECT_WRITE_TIME/ 1000 . 0  + LOCK_WAIT_TIME/ 1000 . 0  + TOTAL_SORT_TIME/ 1000 . 0  +
   PREFETCH_WAIT_TIME/ 1000 . 0  + UOW_LOCK_WAIT_TIME/ 1000 . 0  + AGENT_USR_CPU_TIME_S + AGENT_USR_CPU_TIME_MS/ 1000000 . 0  + AGENT_SYS_CPU_TIME_S + AGENT_SYS_CPU_TIME_MS/ 1000000 . 0  as TOTAL_TIME,

   POOL_READ_TIME/ 1000 . 0  as POOL_READ_TIME,
   POOL_WRITE_TIME/ 1000 . 0  as POOL_WRITE_TIME,
   DIRECT_READ_TIME/ 1000 . 0  as DIRECT_READ_TIME,
   DIRECT_WRITE_TIME/ 1000 . 0  as DIRECT_WRITE_TIME,
   LOCK_WAIT_TIME/ 1000 . 0  as LOCK_WAIT_TIME,
   TOTAL_SORT_TIME/ 1000 . 0  as TOTAL_SORT_TIME,
   PREFETCH_WAIT_TIME/ 1000 . 0  as PREFETCH_WAIT_TIME,
   UOW_LOCK_WAIT_TIME/ 1000 . 0  as UOW_LOCK_WAIT_TIME,
   AGENT_USR_CPU_TIME_S + AGENT_USR_CPU_TIME_MS/ 1000000 . 0  as AGENT_USR_CPU_TIME,
   AGENT_SYS_CPU_TIME_S + AGENT_SYS_CPU_TIME_MS/ 1000000 . 0  as AGENT_SYS_CPU_TIME
FROM
   SYSIBMADM.SNAPAPPL
where
   AGENT_ID =  22424

Включил в запрос все временные компоненты, которые нашел в SYSIBMADM.SNAPAPPL. И все равно время TOTAL_TIME на 50% меньше времени ELAPSED_EXEC_TIME.

elapsed = 150 секунд, total = 102 секунды. А на что пошли еще 48? То, что это не APPL_IDLE_TIME проверил.
...
Рейтинг: 0 / 0
27.01.2009, 20:42
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35781238
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Аналогичная проблема с анализом через event monitor. Данные мониторинга пишу в таблицу. Вот запрос
для таблицы CONN для монитора TEST_DB_01:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT
   sum( elapsed_exec_time )/ 1000000 . 0  as elapsed_exec_time,
   sum( user_cpu_time )/ 1000000 . 0  as user_cpu_time,
   sum( system_cpu_time )/ 1000000 . 0  system_cpu_time,
   sum( direct_read_time )/ 1000 . 0  as direct_read_time, 
   sum( direct_write_time )/ 1000 . 0  as direct_write_time,
   sum( lock_wait_time ) / 1000 . 0  as lock_wait_time,
   sum( pool_read_time ) / 1000 . 0  as pool_read_time,
   sum( pool_write_time ) / 1000 . 0  as pool_write_time
FROM
   CONN_TEST_DB_01;

elapsed в моем тесте равен 20 секундам. А сумма всех остальных времен только 15 секунд. На что ушли оставшиеся 5 секунд? Учитывается ли тут время на статический SQL? У меня есть триггеры и вызовы процедур из триггеров. Процедуры выдает пару селектов и инсертов.
...
Рейтинг: 0 / 0
27.01.2009, 22:06
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35781753
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Дайте вывод команды:
db2 get dbm cfg | grep DFT_MON
...
Рейтинг: 0 / 0
28.01.2009, 09:48
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35782402
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Mark BarinsteinДайте вывод команды:
db2 get dbm cfg | grep DFT_MON

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
$ db2 get dbm cfg | grep DFT_MON
   Buffer pool                         (DFT_MON_BUFPOOL) = ON
   Lock                                   (DFT_MON_LOCK) = ON
   Sort                                   (DFT_MON_SORT) = OFF
   Statement                              (DFT_MON_STMT) = ON
   Table                                 (DFT_MON_TABLE) = ON
   Timestamp                         (DFT_MON_TIMESTAMP) = ON
   Unit of work                            (DFT_MON_UOW) = ON
$

Спасибо. Мысль понял. Сбор временной статистики для сортировак не был включен. Сейчас проверю снова.
...
Рейтинг: 0 / 0
28.01.2009, 12:48
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35782470
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_дуСпасибо. Мысль понял. Сбор временной статистики для сортировак не был включен. Сейчас проверю снова.Только сделайте
Код: plaintext
db2 update dbm cfg using DFT_MON_SORT on immediate
и перезапустите приложение.
И всё равно, скорее всего, не сойдется. :)
В случае выключенного параллелизма
Код: plaintext
db2 get dbm cfg | grep INTRA
если NO, то разница покажет вам время "вне db2" - из-за сети и процессинга на стороне приложения.
Если YES и приложение использует несколько агентов, то сравенение может быть вообще некорректным, т.к. некоторые операции оно может делать параллельно...
...
Рейтинг: 0 / 0
28.01.2009, 13:03
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35783542
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Возникла новая проблема - Как посмотреть производительность статического SQL. В базе имеется несколько хранимых процедур, которые очевидно сильно грузят базу. Но в SYSIBMADM.SNAPDYN_SQL нет ни одного запроса, которые выдаются из этих хранимых процедур. В доке "Administrative Routines and Views" ничего подходящего не нашел.

В best practise нашел только вот это: db2pd –static
...
Рейтинг: 0 / 0
28.01.2009, 17:11
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35783550
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dmitry Y.
Гость
Есть еще такая утилитка db2mon .
...
Рейтинг: 0 / 0
28.01.2009, 17:17
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35783661
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_дуВозникла новая проблема - Как посмотреть производительность статического SQL. В базе имеется несколько хранимых процедур, которые очевидно сильно грузят базу. Но в SYSIBMADM.SNAPDYN_SQL нет ни одного запроса, которые выдаются из этих хранимых процедур. В доке "Administrative Routines and Views" ничего подходящего не нашел.

В best practise нашел только вот это: db2pd –staticЭто и event monitor for statements
...
Рейтинг: 0 / 0
28.01.2009, 17:48
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35784037
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Mark Barinsteinшубин_дуВозникла новая проблема - Как посмотреть производительность статического SQL. В базе имеется несколько хранимых процедур, которые очевидно сильно грузят базу. Но в SYSIBMADM.SNAPDYN_SQL нет ни одного запроса, которые выдаются из этих хранимых процедур. В доке "Administrative Routines and Views" ничего подходящего не нашел.

В best practise нашел только вот это: db2pd –staticЭто и event monitor for statements

Спасибо, Mark!

Сделал мониторинг в режиме statements. Анализ трейсовой таблицы STMT_XXX показывает, что после каждой операции UPDATE на таблице с триггерами идет список "пустых" операций у которых поле STMT_TEXT не заполнено.

Судя по-всему это и есть статический SQL, который вызывается при изменении записи в таблице. Такие "пустые" строки имеют 1 в колонке STMT_TYPE, тогда как строки с заполненным текстом SQL имеют в STMT_TYPE значение 2.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SELECT \
  TRANSLATE(CAST(SUBSTR(STMT_TEXT,  1 ,  20 ) AS VARCHAR( 20 ))) as SQL_TEXT, \
  STMT_TYPE, \
  PACKAGE_NAME \
FROM  \
  STMT_XXX  \
order by   START_TIME \


SQL_TEXT             STMT_TYPE            PACKAGE_NAME
-------------------- -------------------- --------------
UPDATE MYTAB1  SET                       2  SYSSN200
                                         1  P2402204
                                         1  P2402204
UPDATE MYTAB   SET                       2  SYSSN200
                                         1  P2402204
                                         1  P2402204

В поле пакета у таких запросов стоит нечто, отличное от SYS, вероятно по этому имени как-то можно отыскать текст статического SQL. А как это сделать не понял. Есть какая-то возможность получить в трейсе текст статического SQL, а не только статистику по нему? Иначе непонятно, какую нагрузку на базу накладывают запросы из триггеров.

Еще раз спасибо за поддержку.
...
Рейтинг: 0 / 0
28.01.2009, 20:53
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35784747
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_ду,

1.
О влиянии триггеров на команду вы можете судить только по
INT_ROWS_DELETED, INT_ROWS_INSERTED, INT_ROWS_UPDATED
Вся остальная статистика приводится по команде в целом.
2.
Чтоб достать текст любого (динамического или статического (STMT_TYPE = 1)) запроса:
Код: plaintext
1.
2.
3.
4.
select coalesce(e.stmt_text, s.text) as text
from stmt_xxx e
left join syscat.statements s on
e.CREATOR=e.PKGSCHEMA and e.PACKAGE_NAME=s.PKGNAME
and e.SECTION_NUMBER=s.SECTNO
...
Рейтинг: 0 / 0
29.01.2009, 11:06
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35785330
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Спасибо Mark,

статический SQL нашелся. Однако оказалось, что трейс для режима statements не содержит SQL-запросов, которые были выданы из триггера. Монитор создавал так:

Код: plaintext
1.
CREATE EVENT MONITOR M01 FOR TABLES, CONNECTIONS, STATEMENTS, TRANSACTIONS WHERE APPL_ID='BLABLABLA' WRITE TO TABLE

Триггер делает INSERT в таблицу X и вызывает хранимую процедуру, которая делает DELETE из таблицы X. INSERT в трейсе отсутствует, тогда как DELETE в трейсе имеется (в виде статического SQL).

Может быть триггер выполняется под другим APPL_ID и поэтому выданные им запросы не попадают в трейс?

Собственно сейчас удалось установить, что приложение тормозит из-за триггера. Если его отключить, то время DIRECT_WRITE_TIME в SYSIBMADM.SNAPAPPL для приложения резко сокращается. Хотелось бы получить точную статистику для SQL-запросов внутри триггера, чтобы быть уверенным, что "виноват" триггер.

Сергей
...
Рейтинг: 0 / 0
29.01.2009, 13:22
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35785365
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_дустатический SQL нашелся. Однако оказалось, что трейс для режима statements не содержит SQL-запросов, которые были выданы из триггера. Монитор создавал так:Вы нигде текст триггера не увидите в трейсах. Это действительно неудобно.
шубин_дуСобственно сейчас удалось установить, что приложение тормозит из-за триггера. Если его отключить, то время DIRECT_WRITE_TIME в SYSIBMADM.SNAPAPPL для приложения резко сокращается.DIRECT_... связано с объектами, которые не кэшируются, а работа с которыми производится напрямую с диска (long varchar, lob).
...
Рейтинг: 0 / 0
29.01.2009, 13:30
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35785734
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Mark Barinsteinшубин_дустатический SQL нашелся. Однако оказалось, что трейс для режима statements не содержит SQL-запросов, которые были выданы из триггера. Монитор создавал так:Вы нигде текст триггера не увидите в трейсах. Это действительно неудобно.
шубин_дуСобственно сейчас удалось установить, что приложение тормозит из-за триггера. Если его отключить, то время DIRECT_WRITE_TIME в SYSIBMADM.SNAPAPPL для приложения резко сокращается.DIRECT_... связано с объектами, которые не кэшируются, а работа с которыми производится напрямую с диска (long varchar, lob).

Речь идет не от тексте триггера, а о INSERT, SELECT, которые выдаются внутри триггера. Мне нужна статистика по SQL-запросам, выдаваемым внутри триггера.

Что касается DIRECT_WRITE_TIME, то при записи на диск (INSERT, DELETE) у меня увеличивается время именно в этой колонке, а не в POOL_WRITE_TIME. LONG и LOB в приложении нет, но сейчас еще раз проверю.
...
Рейтинг: 0 / 0
29.01.2009, 15:00
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35785791
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_дуРечь идет не от тексте триггера, а о INSERT, SELECT, которые выдаются внутри триггера. Мне нужна статистика по SQL-запросам, выдаваемым внутри триггера.Я это и имел ввиду.
Кроме кол-ва измененных строк триггерами отдельной статистики по триггерам нет.
шубин_дуЧто касается DIRECT_WRITE_TIME, то при записи на диск (INSERT, DELETE) у меня увеличивается время именно в этой колонке, а не в POOL_WRITE_TIME. LONG и LOB в приложении нет, но сейчас еще раз проверю.Виноват, в прямую запись еще входит увеличение sms табличных пространств:
direct_writes
...
Рейтинг: 0 / 0
29.01.2009, 15:14
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35786520
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
После всех проведенных тестов обнаружил в базе один запрос у которого особенно большое время
total_exec_time. Чтобы установить на что тратится время сделал такой запрос, в который включил все колонки со временем из sysibmadm.snapdyn_sql:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
select
   translate( cast( substr( stmt_text,  1 ,  2500 ) as varchar( 2500 ) ) ) as sql_text, 
   total_exec_time + total_exec_time_ms /  1000000 . 0  as exec_time,
   num_executions,
   total_usr_cpu_time + total_usr_cpu_time_ms/ 1000000 . 0  as total_usr_cpu_time,
   total_sys_cpu_time + total_sys_cpu_time_ms/ 1000000 . 0  as total_sys_cpu_time,
   stats_fabricate_time/ 1000 . 0  as stats_fabricate_time,
   prep_time_worst/ 1000 . 0  as prep_time_worst,
   prep_time_best/ 1000 . 0  as prep_time_best,
   total_sort_time/ 1000 . 0  as total_sort_time,
   sync_runstats_time/ 1000 . 0  as sync_runstats_time
from
   sysibmadm.snapdyn_sql 
order by
   exec_time desc
fetch first  100  rows only

Получаю вот такую статистику для наиболее тяжелого запроса:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
EXEC_TIME            =  213901 , 89 
NUM_EXECUTIONS       =  7172 
TOTAL_USR_CPU_TIME   =  11 , 02 
TOTAL_SYS_CPU_TIME   =  0 , 60 
STATS_FABRICATE_TIME =  0 
PREP_TIME_WORST      =  0 , 028 
PREP_TIME_BEST       =  0 . 004 
TOTAL_SORT_TIME      =  0 
SYNC_RUNSTATS_TIME   =  0

Если сложить имеющиеся в snapdyn_sql времена, то получим, что время EXEC_TIME на порядки превышает эту сумму, то есть запрос занимается чем-то, что не входит в статистику. Вероятно читает большую таблицу без индекса. Или ждет чего-то из-за блокировки.

Непонятно, как можно увидеть время, затраченное на ожидания ввода/вывода, на ожидания освобождения блокировки и пр.
...
Рейтинг: 0 / 0
29.01.2009, 19:16
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35786627
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Столкнулся с несовпадением статистик по общему времени исполнения:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
db2 => select \
   elapsed_exec_time_s + elapsed_exec_time_ms/ 1000000 . 0  as elapsed_exec_time \
from \
   sysibmadm.snapdbdb2

ELAPSED_EXEC_TIME
---------------------------------
                227844 , 93727600000 

   1  record(s) selected.

db2 => select \
   sum( elapsed_exec_time_s + elapsed_exec_time_ms/ 1000000 . 0  ) as elapsed_exec_time \
from \
   sysibmadm.snapappl
db2 =>
ELAPSED_EXEC_TIME
---------------------------------
                 29009 , 11971500000 

   1  record(s) selected.

db2 => select \
   sum( total_exec_time + total_exec_time_ms/ 1000000 . 0  ) as elapsed_exec_time \
from \
   sysibmadm.snapdyn_sqldb2

ELAPSED_EXEC_TIME
---------------------------------
                220314 , 73510400000 

   1  record(s) selected.

db2 =>

Получается, что сумма времен исполнения по всей базе равна 227844, по всем приложениям 29009, по всем динамическим запросам 220314.

Предполагаю, что это связано с тем, что SNAP дает моментальный снимок. Те приложения, которые уже закончились сюда не входят. Поэтому сумма по приложениям существенно меньше суммы по базе.

Сумма динамических запросов меньше суммы по базе в связи с тем, что часть запросов уже вытеснена из кеша. И кроме того еще имеются статические запросы, которые вносят вклад в сумму для базы, но не учитываются в динамических запросах.
...
Рейтинг: 0 / 0
29.01.2009, 20:59
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35802796
шубин_ду
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
шубин_ду
Участник
Очередная странность с elapsed_exec_time_s

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
db2 => select \
db2 (cont.) =>    appl.elapsed_exec_time_s + appl.elapsed_exec_time_ms /  1000000 . 0  as elapsed_exec_time, \
db2 (cont.) =>    appl.agent_usr_cpu_time_s + appl.agent_usr_cpu_time_ms /  1000000 . 0  as user_cpu, \
db2 (cont.) =>    appl.agent_sys_cpu_time_s + appl.agent_sys_cpu_time_ms /  1000000 . 0  as sys_cpu \
db2 (cont.) => from \
db2 (cont.) =>    sysibmadm.snapappl      appl \

ELAPSED_EXEC_TIME                 USER_CPU                          SYS_CPU
--------------------------------- --------------------------------- ---------------------------------
                     0 , 00085400000                       0 , 02685500000                       0 , 03918000000 
                     0 , 04184500000                       0 , 00319600000                       0 , 00063200000 

   2  record(s) selected.

db2 =>

Как может быть ELAPSED_EXEC_TIME меньше время процессора?
...
Рейтинг: 0 / 0
06.02.2009, 19:42
| Ответить | Цитировать | Написать  
Мониторинг производительности сессии
    #35806596
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
шубин_дуКак может быть ELAPSED_EXEC_TIME меньше время процессора?На очень коротких промежутках времени такое бывает.
Не уверен, но по-моему производитель не делает "транзакций" для показателей монитора. Т.е. в како-то момент времени вы можете, действительно, поймать показатели на состоянии, когда оно обновило уже детальный счётчик, а аггрегат, в который он входит - нет...
...
Рейтинг: 0 / 0
09.02.2009, 18:20
| Ответить | Цитировать | Написать  
24 сообщений из 24, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Мониторинг производительности сессии
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]