Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
Смотрю данные по активности использования таблиц и не понимаю: через get snapshot for tables данные по таблицам вижу, а в административном вью snaptab некоторых таблиц нет. Даже эксперимент провел - деактивировал базу, потом снова запустил и прочитал неск. таблиц - get snapshot данные по прочитанным таблицам выводит, а в snaptab их нету. Почему так может быть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2011, 10:21 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
Andron, 1. Какая версия DB2? 2. Что выдают: Код: plaintext 1. Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2011, 11:29 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
1. Версия db2 v9.7.0.2 2. Переключатель для базы (включен для текущей сессии из которой и выполняю все запросы) Table Activity Information (TABLE) = ON 16.03.2011 10:09:26.339657 для инстанса выключен Table (DFT_MON_TABLE) = OFF 3. Да, результатов после того как таблица прочитана в snaptab нету, то же самое если смотреть через функцию snap_get_tab. Но в snaptab есть данные для других таблиц. Причем если например сделать удаление данных из тестовой таблицы то она появляется в snaptab, rows_written не 0, зато значение rows_reads у нее 0 несмотря на то что перед удалением данные выбирались из нее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2011, 11:42 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
Andron1. Версия db2 v9.7.0.2 2. Переключатель для базы (включен для текущей сессии из которой и выполняю все запросы) Table Activity Information (TABLE) = ON 16.03.2011 10:09:26.339657 для инстанса выключен Table (DFT_MON_TABLE) = OFF 3. Да, результатов после того как таблица прочитана в snaptab нету, то же самое если смотреть через функцию snap_get_tab. Но в snaptab есть данные для других таблиц. Причем если например сделать удаление данных из тестовой таблицы то она появляется в snaptab, rows_written не 0, зато значение rows_reads у нее 0 несмотря на то что перед удалением данные выбирались из нее.Все эти sysibmadm.snap* и sysproc.snap* реагируют на соответствующие DFT_MON_* параметры инстанса. Если параметр выключен, информация для показателей, от него зависящих, не собирается. get snapshot реагирует на переключатели монитора, установленные в сессии. Эти сессионные переключатели получают первоначальные значения от соотв. параметров инстанса и потом могут быть изменены командами update monitor switches, а не update dbm cfg. Сделайте: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2011, 18:12 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
[quot Mark Barinstein]Andron... Сделайте: Код: plaintext Я уже так делал, включал DFT_MON_TABLE, потом включал в базе - не показывает данные по ROWS_READ все равно. Данные появляются только если сделан update или delete и только в столбце rows_written, rows_read остается равным 0 после нескольких выборок из таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2011, 08:39 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
[quot Andron]Mark Barinsteinпропущено... Я уже так делал, включал DFT_MON_TABLE, потом включал в базе - не показывает данные по ROWS_READ все равно. Данные появляются только если сделан update или delete и только в столбце rows_written, rows_read остается равным 0 после нескольких выборок из таблицы.И после переустановки соединения с базой тоже? В 9.7 можно также (и это более предпочтительно): Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2011, 11:13 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein, если использовать mon_get_table то row_reads показывает :) И все же получается что имеет место баг с view snaptab? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2011, 14:09 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
AndronИ все же получается что имеет место баг с view snaptab?У меня на 9.7.3 это не воспроизводится. Что это за 9.7.0.2 версия у вас? Что db2level выдаёт? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2011, 14:41 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release "SQL09072" with level identifier "08030107". Informational tokens are "DB2 v9.7.0.2", "s100514", "IP23088", and Fix Pack "2". Product is installed at "/opt/ibm/db2/V9.7". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2011, 14:44 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
Теперь разбираюсь с mon_get_table, тут как выясняется тоже не все гладко: db2 => select varchar(tabname, 20) as tabname, rows_read, table_scans from table(mon_get_table('DB2INST1', '', -1)) TABNAME ROWS_READ TABLE_SCANS -------------------- -------------------- -------------------- 0 record(s) selected. db2 => select count(*) from employee 1 ----------- 42 1 record(s) selected. db2 => select varchar(tabname, 20) as tabname, rows_read, table_scans from table(mon_get_table('DB2INST1', '', -1)) TABNAME ROWS_READ TABLE_SCANS -------------------- -------------------- -------------------- EMPLOYEE 0 0 1 record(s) selected. db2 => Как видим несмотря на то что была выборка из employee, данные мониторинга об этом ничего не говорят. Зато если сделать такой запрос: db2 => select count (*) from staff 1 ----------- 35 1 record(s) selected. db2 => select varchar(tabname, 20) as tabname, rows_read, table_scans from table(mon_get_table('DB2INST1', '', -1)) TABNAME ROWS_READ TABLE_SCANS -------------------- -------------------- -------------------- EMPLOYEE 0 0 STAFF 35 1 2 record(s) selected. Как видим для таблицы staff мониторинг возвращает данные а для employee нет. Почему? Таблицы вроде обычные, из учебной схемы. Я бы списал все на какой нибудь кэш, где данные "застревают" но почему так избирательно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2011, 11:19 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
AndronКак видим для таблицы staff мониторинг возвращает данные а для employee нет. Почему? Таблицы вроде обычные, из учебной схемы. Я бы списал все на какой нибудь кэш, где данные "застревают" но почему так избирательно?Может зависеть плана запроса. Если план - index access only, то rows_read не будет увеличиваться. У меня при select count(*) from employee именно index access only. Access plan Код: 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. 36. 37. 38. 39. 40. 41. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2011, 12:04 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
Сравните с: select count(*) from staff Код: 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. 36. 37. 38. 39. 40. 41. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2011, 12:08 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
Действительно, если посмотреть в mon_get_index то для индекса XEMP2 у таблицы employee есть сканы, а у таблицы staff индексных сканирований нет. Спасибо, Марк! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2011, 12:38 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
А как сбросить данные мониторинга, которые я получаю через функции, например mon_get_tab ? Reset monitor не сбрасывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2011, 09:10 |
|
||
|
Данные в snaptab
|
|||
|---|---|---|---|
|
#18+
AndronА как сбросить данные мониторинга, которые я получаю через функции, например mon_get_tab ? Reset monitor не сбрасывает.Эти показатели для функций mon_* реагируют на соотв. параметры mon_* БД. Код: plaintext Например, pool_data_l_reads : В 'Table 1. Table Function Monitoring Information' (это для функций mon_*) для ф-ции MON_GET_BUFFERPOOL указано, что оно собирается, если параметр DATA OBJECT METRICS (MON_OBJ_METRICS) установлен в BASE. Для ф-ции MON_GET_UNIT_OF_WORK этот же самый счётчик будет собираться, если параметр REQUEST METRICS (MON_REQ_METRICS) установлен в BASE. Т.е. чтобы сбросить такой счётчик, надо выключить и включить (хотя бы в BASE) соотв. параметр БД. Для rows_read написано, что для MON_GET_TABLE оно собирается всегда, т.е. вне зависимости от установленных параметров. Т.е. чтобы сбросить такой счётчик, надо реактивировать БД (выгнать из неё всех, а потом пустить). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2011, 11:12 |
|
||
|
|

start [/forum/topic.php?fid=43&gotonew=1&tid=1602336]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
63ms |
get topic data: |
9ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 263ms |
| total: | 419ms |

| 0 / 0 |
