ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
14 сообщений из 14, страница 1 из 1
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37903206
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
В частности есть два вопроса:

1) относительно автоматической настройки в пуле буферов, то есть в пуле буферов есть IBMDEFAULTBP, который стоит с автоматической настройкой с немедленным изменением размера. Если смотрим через ЦУ, то это отражается как следующее в колонке размера стоит -2, а в колонке автоматической настройки стоит "Да" лучше этот вариант чем ручная ловля размера буфера или нет?

2) вопрос относительно сортировок, мы используем конфигурацию dbm и db в которых по максимумы используется автоматическая настройка переменных, но на одной из баз число тупиковых ситуаций всё равно остаётся высоким и составляет от 5 до 16 шт/ч:

для проблемной БД:

Самонастраивающаяся память (SELF_TUNING_MEM) = ON (Active)
Размер совм.памяти базы данных(4 Кбайт)(DATABASE_MEMORY)= AUTOMATIC(3025264)
Макс. память списка блокировок (4 Кбайт) (LOCKLIST) = AUTOMATIC(4096)
Процент списков блокировки на программу (MAXLOCKS) = AUTOMATIC(98)
Размер кэша пакета (4 Кбайт) (PCKCACHESZ) = AUTOMATIC(57336)
Порог куч совмест. сортировок (4 Кбайт)(SHEAPTHRES_SHR) = AUTOMATIC(2462675)
Размер кучи списка сортировки (4 Кбайт) (SORTHEAP) = AUTOMATIC(492535)
Размер кучи базы данных (4 Кбайт) (DBHEAP) = AUTOMATIC(7000)

для самого экземпляра:

Размер кучи монитора баз данных (4 Кбайт) (MON_HEAP_SZ) = AUTOMATIC(1000)
Размер буфера аудита (4 Кбайт) (AUDIT_BUF_SZ) = 0
Размер совм.памяти экземпляра(4Кбайт) (INSTANCE_MEMORY) = AUTOMATIC(4194304)
Размер буфера резерв.копир. по ум. (4Кбайт) (BACKBUFSZ) = 1024
Размер буфера восстановлен.по умолч.(4 Кбайт)(RESTBUFSZ)= 1024
Порог кучи сортировки (4 Кбайта) (SHEAPTHRES) = 0
Размер пула агентов (NUM_POOLAGENTS) = AUTOMATIC(400)
Начальное число агентов в пуле (NUM_INITAGENTS) = 0
Макс. число взаимодействующих агентов (MAX_COORDAGENTS) = AUTOMATIC(400)
Макс. число соединений с клиентами (MAX_CONNECTIONS) = AUTOMATIC(1600)
Число помещенных в пул изолир. процессов (FENCED_POOL) = AUTOMATIC(MAX_COORDAGENTS)
Макс. уровень параллелизма запроса (MAX_QUERYDEGREE) = ANY
Число внутр.буферов связи (4 Кбайт) (FCM_NUM_BUFFERS) = AUTOMATIC(1024)
Число внутренних каналов связи (FCM_NUM_CHANNELS) = AUTOMATIC(512)

Поможет ли в данной ситуации ручное конфигурирование БД?
...
Рейтинг: 0 / 0
03.08.2012, 12:04
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37903805
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
Anka_Sлучше этот вариант чем ручная ловля размера буфера или нет?

Каковы критерии лучшести? Если вас устраивает эффективность пула (hit ratio), то оснований для беспокойства нет. По моему опыту автонастройка в течение нескольких часов приходит к оптимальной конфигурации, если нагрузка на базу постоянна по характеру и интенсивности.

Anka_Sчисло тупиковых ситуаций всё равно остаётся высоким и составляет от 5 до 16 шт/ч:

...

Поможет ли в данной ситуации ручное конфигурирование БД?

Что вы называете тупиковой ситуацией? Deadlock? Они обычно свидетельствуют о проблемах с логикой клиентского приложения, и бороться с ними настройкой параметров базы невозможно.
...
Рейтинг: 0 / 0
03.08.2012, 17:06
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37905287
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
mustaccio,
Каковы критерии лучшести?
Аргумент со стороны разработки-сопровождения следующий:
- во-первых, для пулов при 90-100% использовании не требуется постоянная выборка как следствие пользователь меньше ждёт.
Для этого Рассчитываем коэффициент попадания в пул = (1 - (("Физических чтений данных пула буферов " + "Физических чтений индекса пула буферов")/("Логических чтений данных пула буферов" + "Логических чтений индекса пула буферов")))*100 , если он ниже 90%, то увеличиваем число страниц- во-вторых,
По идее если пулы в автонастройки стоят, то коэффициент должен быть уже под 100% или нет?

-во-вторых, уменьшение числа переполнения сортировок на БД, для этого опять же врукопашную выставлять SORTHEAP по снапам, при этом проверять выполнение условия MAX_CONNECTIONS > MAX_COORDAGENTS, INTRA_PARALLEL=YES + не очень понятное влияние SHEAPTHRES и SHEAPTHRES_SHR.
Для снапов нужны работающие мониторы, которые хоть и мало, но едят ресурсы.
Опять если стоит автоматическое определение размера кучи списка сортировок SORTHEAP и автоматическое определение порога кучи совместных сортировок SHEAPTHRES_SHR, то чем мне поможет ручное?

По моему опыту автонастройка в течение нескольких часов приходит к оптимальной конфигурации, если нагрузка на базу постоянна по характеру и интенсивности.

В общем, интенсивность, т.е. число поступивших и число отработанных запросов в течение суток непостоянно. Ночью базы копируются, реорганизуются и т.п., пользователи в это время с ними не работают, днём наоборот 9-10 пользователи кидаются работать с повышенным энтузиазмом, потом успокаиваются к обеду, победа пользователи опять рвутся в бой, поэтому три пика активности с 9 до 18 зафиксировать можно точно.

Что вы называете тупиковой ситуацией? Deadlock? Они обычно свидетельствуют о проблемах с логикой клиентского приложения, и бороться с ними настройкой параметров базы невозможно.

Да deadlock'и будь они ни ладны, но какой же из разработчиков признается в том что логика "кривая", а как доказать это я не очень хорошо представляю, что посоветуете?
...
Рейтинг: 0 / 0
06.08.2012, 10:46
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37907131
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.Panskikh
Гость
Anka_S,

Касательно deadlock - это всегда проблема проектирования приложения. Типовая ошибка - встреча двух транзакций, которые делают изменения в разных направлениях - одна update t1, update t2, другая наоборот - t2, потом t1. Это элементарно отлавливается на мониторе и тычется в морду разрабу. Советую включить DB2_CAPTURE_LOCKTIMEOUT=ON. Locktimeout также настраивается, в том числе и может быть изменен со стороны конкретного приложения.

Эффективность буферных пулов зависит от ситуации. Пул используется всегда. Поэтому, если появляются запросы, которые требуют масштабного чтения данных, происходит вымывание кэша - в нем элементарно не останется часто используемый контент. Поэтому и пулов можно создать много, под конкретные сегменты данных, к тому же еще и разделить для индексов и данных.
Обычно под справочники выделяем отдельный пул, размер которого равен объему. Определяем нагруженные таблицы, выносим их в отдельные tbs и подбираем практикой оптимальный размер кэша (начинаем с классических 10%). Ну и так далее, опираясь на ситуацию. У нас есть табличное пространство под массовые загрузки и промежуточные расчеты, попадание в пул там всегда меньше 30% в силу природы. Кроме этого, никакой кэш не будет эффективен, если запросы неэффективны.

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

Для варехаузов своя методика и свои подходы.

Andy
...
Рейтинг: 0 / 0
07.08.2012, 12:36
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37907995
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
Anka_SАргумент со стороны разработки-сопровождения следующий:
- во-первых, для пулов при 90-100% использовании не требуется постоянная выборка как следствие пользователь меньше ждёт.
Для этого Рассчитываем коэффициент попадания в пул = (1 - (("Физических чтений данных пула буферов " + "Физических чтений индекса пула буферов")/("Логических чтений данных пула буферов" + "Логических чтений индекса пула буферов")))*100 , если он ниже 90%, то увеличиваем число страниц- во-вторых,
По идее если пулы в автонастройки стоят, то коэффициент должен быть уже под 100% или нет?

Не всегда можно добиться 100% коэффициента попадания (эффективности). Кроме того, это не всегда нужно. По идее стоит измерять производительность приложения после каждого изменения размера БП и остановиться, если изменение не приносит видимого выигрыша в производительности. Это же касается и сортировок -- редко удается полностью избежать переполнения сортировок, и не всегда это нужно.

Я бы не стал заниматься настройкой ради настройки. Если у вас есть конкретная проблема с производительностью, стоит понять ее происхождение и нанести точечный удар по истинной причине этой проблемы.

Посмотрите результат SYSIBMADM.MONREPORT.DBSUMMARY -- это даст вам общую картину проблемных мест.



Anka_SДля снапов нужны работающие мониторы, которые хоть и мало, но едят ресурсы.

Пользуйтесь программным интерфейсом монитора (представления MON_* и функции MON_GET_*) -- они должны существенно меньше влиять на общую производительность.


Anka_SВ общем, интенсивность, т.е. число поступивших и число отработанных запросов в течение суток непостоянно. Ночью базы копируются, реорганизуются и т.п., пользователи в это время с ними не работают, днём наоборот 9-10 пользователи кидаются работать с повышенным энтузиазмом, потом успокаиваются к обеду, победа пользователи опять рвутся в бой, поэтому три пика активности с 9 до 18 зафиксировать можно точно.

Если вас не устраивает поведение STMM, вы можете отключить его сразу после одного из пиков активности, зафиксировав значения параметров, определенные автоматически, и подстроить вручную те, что необходимо.


Anka_SДа deadlock'и будь они ни ладны, но какой же из разработчиков признается в том что логика "кривая", а как доказать это я не очень хорошо представляю, что посоветуете?

Соберите информацию монитора дедлоков (см. здесь: http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.mon.doc/doc/c0054136.html и здесь: http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.mon.doc/doc/t0055093.html). Не забудьте "db2 update db cfg for sample using mon_deadlock hist_and_values ". В этом случае полученный отчет будет содержать не только запросы, вызвавшие дедлок, но и предыдущие запросы в каждой из участвующих сессий. Этого должно быть достаточно для информативного разговора.
...
Рейтинг: 0 / 0
07.08.2012, 23:31
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37908101
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
A.PanskikhAnka_S,

Касательно deadlock - это всегда проблема проектирования приложения. Типовая ошибка - встреча двух транзакций, которые делают изменения в разных направлениях - одна update t1, update t2, другая наоборот - t2, потом t1. Это элементарно отлавливается на мониторе и тычется в морду разрабу. Советую включить DB2_CAPTURE_LOCKTIMEOUT=ON. Locktimeout также настраивается, в том числе и может быть изменен со стороны конкретного приложения.


Время ожидание блокировки (сек) (LOCKTIMEOUT) = 60 стоит по умолчанию
Что даст включение DB2_CAPTURE_LOCKTIMEOUT=ON?

A.PanskikhЭффективность буферных пулов зависит от ситуации. Пул используется всегда. Поэтому, если появляются запросы, которые требуют масштабного чтения данных, происходит вымывание кэша - в нем элементарно не останется часто используемый контент. Поэтому и пулов можно создать много, под конкретные сегменты данных, к тому же еще и разделить для индексов и данных.
Обычно под справочники выделяем отдельный пул, размер которого равен объему. Определяем нагруженные таблицы, выносим их в отдельные tbs и подбираем практикой оптимальный размер кэша (начинаем с классических 10%). Ну и так далее, опираясь на ситуацию. У нас есть табличное пространство под массовые загрузки и промежуточные расчеты, попадание в пул там всегда меньше 30% в силу природы. Кроме этого, никакой кэш не будет эффективен, если запросы неэффективны.


Эффективность запросов я могу улучшить только построением индексов, но это увеличивает размер самой БД.
Пулы стоя под автонастройкой, чем и почему она хуже ручной?
...
Рейтинг: 0 / 0
08.08.2012, 07:32
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37908108
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
mustaccioЯ бы не стал заниматься настройкой ради настройки. Если у вас есть конкретная проблема с производительностью, стоит понять ее происхождение и нанести точечный удар по истинной причине этой проблемы.
Посмотрите результат SYSIBMADM.MONREPORT.DBSUMMARY -- это даст вам общую картину проблемных мест.


Согласна на все 100, настройка ради эксперимента, по-моему, годиться только на тестовых БД, на промышленной БД это нервы пользователей и мои

mustaccioПользуйтесь программным интерфейсом монитора (представления MON_* и функции MON_GET_*) -- они должны существенно меньше влиять на общую производительность.


Немножко не поняла, можно подробнее про программный интерфейс монитора ...

mustaccioЕсли вас не устраивает поведение STMM, вы можете отключить его сразу после одного из пиков активности, зафиксировав значения параметров, определенные автоматически, и подстроить вручную те, что необходимо.


Включенная самонастраивающаяся память (SELF_TUNING_MEM), штука хорошая, но при снижении нагрузки она перестраивает параметры для того что бы они не держали ресурсы так и соответственно при следующем рывке опять будет перестройка параметров или нет. Я пыталась указывать от какого значения брать автоматические параметры например так выставляю LOCKLIST=4096, а после применения этого значения изменяю значение параметра на AUTOMATIC не знаю правильно это или нет

mustaccio http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.mon.doc/doc/t0055093.html)


Ссылка дала 404 ошибку, что в ней?
...
Рейтинг: 0 / 0
08.08.2012, 07:57
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37908372
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.Panskikh
Гость
Anka_SВремя ожидание блокировки (сек) (LOCKTIMEOUT) = 60 стоит по умолчанию


Для oltp-системы, к примеру, это неразумное время - ожидать минуту ответа системы!

Anka_SЧто даст включение DB2_CAPTURE_LOCKTIMEOUT=ON?


Автоматом в каталоге DB2DIAG будут создаваться файлики на каждую ситуацию locktimeout/deadlock.

Anka_SЭффективность запросов я могу улучшить только построением индексов, но это увеличивает размер самой БД.
Пулы стоя под автонастройкой, чем и почему она хуже ручной?

Чем плох размер базы? Для некоторых систем размер индексов превышает объем данных... Дисковая память дешевая, падение производительности на операциях записи? Другое дело, что большое количество индексов, которые к тому же дублируют друг друга - это ошибки проектирования. Если мы вынуждены построить на таблицу 2 индекса (F1,F2) и (F2,F1) - 99,99%, что нужно уволить проектировщика без выходного пособия.

Про автонастройку - она же авто, действует по некоторому сценарию, ИИ не обладает. И рассчитана алгоритмически на типовую нормально спроектированную среду. А это из области фантастики :)
Пулы нужно настраивать ручками, с пониманием процессов. Находить баланс. Кроме того, автонастройка в документации для продуктивных сред не рекомендуется. Если мы совсем не знаем систему - то да, это способ получить начальные данные.

Andy
...
Рейтинг: 0 / 0
08.08.2012, 11:14
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37909110
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
Anka_S
mustaccioПользуйтесь программным интерфейсом монитора (представления MON_* и функции MON_GET_*) -- они должны существенно меньше влиять на общую производительность.


Немножко не поняла, можно подробнее про программный интерфейс монитора ...

Начиная с версии 9.5, помимо традиционного snapshot monitor появился другой способ получать значения различных метрик производительности БД, в документации это просто называют monitor functions and views (не уверен насчет русского перевода) - представления MON_* и функции MON_GET_*. Информация в них берется, в частности, от менеджера нагрузки (WLM). Новый монитор, назовем его так, значительно меньше влияет на производительность и является рекомендованным способом доступа к метрикам производительности.

Anka_Sвыставляю LOCKLIST=4096, а после применения этого значения изменяю значение параметра на AUTOMATIC не знаю правильно это или нет

UPDATE DB CFG FOR ... USING LOCKLIST 4096 AUTOMATIC

Anka_Smustaccio http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.mon.doc/doc/t0055093.html)


Ссылка дала 404 ошибку, что в ней?

Лишняя скобка. http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.mon.doc/doc/t0055093.html
...
Рейтинг: 0 / 0
08.08.2012, 15:44
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37909143
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
A.PanskikhВремя ожидание блокировки (сек) (LOCKTIMEOUT) = 60 стоит по умолчанию

Для oltp-системы, к примеру, это неразумное время - ожидать минуту ответа системы!


От разработчика и конторы этот параметр предлагают выставлять по вилке от 30 до 60

A.PanskikhЧем плох размер базы? Для некоторых систем размер индексов превышает объем данных... Дисковая память дешевая, падение производительности на операциях записи? Другое дело, что большое количество индексов, которые к тому же дублируют друг друга - это ошибки проектирования. Если мы вынуждены построить на таблицу 2 индекса (F1,F2) и (F2,F1) - 99,99%, что нужно уволить проектировщика без выходного пособия.

Про автонастройку - она же авто, действует по некоторому сценарию, ИИ не обладает. И рассчитана алгоритмически на типовую нормально спроектированную среду. А это из области фантастики :)
Пулы нужно настраивать ручками, с пониманием процессов. Находить баланс. Кроме того, автонастройка в документации для продуктивных сред не рекомендуется. Если мы совсем не знаем систему - то да, это способ получить начальные данные.

Базы большие, промышленные пухнут и без индексов поэтому лишнего дискового нет, а СХД есть, а дискового нет
Но на СХД свои фишки
...
Рейтинг: 0 / 0
08.08.2012, 15:58
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37914052
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
A.PanskikhАвтоматом в каталоге DB2DIAG будут создаваться файлики на каждую ситуацию locktimeout/deadlock.


Да после включения db2set DB@_CAPTURE_LOCKTIMEOUT=ON пошли создаваться файлы с именами типа db2locktimeout.0.1112.YYY-MM-DD-HH-MM-SS, но их гораздо меньше, чем записей в db2diage c текстом

2012-08-13-12.41.10.255000+360 E33233836F904 LEVEL: Warning
PID : 3876 TID : 2212 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000 DB : nameDB
APPHDL : 0-20163 APPID: GA420215.A10E.120813072727
AUTHID : DB2ADMIN
EDUID : 2212 EDUNAME: db2agent (nameDB)
FUNCTION: DB2 UDB, database monitor, sqmLockEvents::collectLockEvent, probe:267
MESSAGE : ADM5506I "Deadlock" event has occurred on lock
"02000B001400EB080000000052" at timestamp
"2012-08-13-12.41.05.800687" with event ID "29". The affected
application is named "db2jcc_application", and is associated with the
workload name "SYSDEFAULTUSERWORKLOAD" and application ID
"GA420215.A10E.120813072727" at member "0". The role that this
application plays with respect to this lock is: "Victim".

2012-08-13-12.41.10.255000+360 E33234742F909 LEVEL: Warning
PID : 3876 TID : 2828 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000 DB : name DB
APPHDL : 0-64863 APPID: GA420215.K607.120813195225
AUTHID : DB2ADMIN
EDUID : 2828 EDUNAME: db2agent (nameDB)
FUNCTION: DB2 UDB, database monitor, sqmLockEvents::collectLockEvent, probe:267
MESSAGE : ADM5506I "Deadlock" event has occurred on lock
"02000B001300EB080000000052" at timestamp
"2012-08-13-12.41.05.800687" with event ID "29". The affected
application is named "db2jcc_application", and is associated with the
workload name "SYSDEFAULTUSERWORKLOAD" and application ID
"GA420215.K607.120813195225" at member "0". The role that this
application plays with respect to this lock is: "Participant".

Выше один из сегодняшних deadlock'ов, а файлика к нему нет, почему так?
...
Рейтинг: 0 / 0
13.08.2012, 10:47
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37914068
Anka_S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anka_S
Гость
конечно в команде стоит "db2", т.е. db2set DB2_CAPTURE_LOCKTIMEOUT=ON, а знак "@" случайная опечатка, но суть вопроса остаётся почему нb на каждую ситуацию deadlock'а есть файл?
...
Рейтинг: 0 / 0
13.08.2012, 10:53
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37914305
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Anka_Sконечно в команде стоит "db2", т.е. db2set DB2_CAPTURE_LOCKTIMEOUT=ON, а знак "@" случайная опечатка, но суть вопроса остаётся почему нb на каждую ситуацию deadlock'а есть файл?Deadlock'и ловит event monitor for deadlocks, вывод которых находится либо в таблицах, либо в файлах (в этом случае надо форматировать вывод этого монитора).
В 9.7 есть более правильный сбособ для ловли deadlocks, lock waits, lock timeouts Event monitor for locking .
...
Рейтинг: 0 / 0
13.08.2012, 12:37
| Ответить | Цитировать | Написать  
Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
    #37915547
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.Panskikh
Гость
Anka_SВыше один из сегодняшних deadlock'ов, а файлика к нему нет, почему так?

Если настроен wlm, то попадающие под его правила события не будут попадать в данный монитор... Это, так скажем, особенность.
Сейчас ситуация между WLM и мониторингом, по крайней мере к которому я привык, иногда взаимоисключающая. Мне пока не хватает времени разобраться со всеми нюансами.

Andy
...
Рейтинг: 0 / 0
14.08.2012, 10:53
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Нужна информация о эффективности автоматической настройки конфигурации dbm/db в DB2 v9.7.0
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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