Достижение некоторого ограничения в z / OS с драйвером DB2 Connect JDBC t4 - PullRequest
Новая
       22

Достижение некоторого ограничения в z / OS с драйвером DB2 Connect JDBC t4

1 голос
/ 22 сентября 2009

У нас есть приложение, соединяющееся с DB2 в z / OS, и через некоторое время кажется, что на стороне мэйнфрейма наблюдается некоторый лимит ресурсов. Поскольку мы используем BIRT, кажется, что единственный контроль, который мы имеем над кодом JDBC, - это разделы в самом URL. у нас нет прямого контроля Java над соединением или операторами (за исключением, конечно, самого SQL), хотя это может быть возможно при использовании Javascript в дизайне отчета. Таким образом, мы можем включить отладку примерно так: 

jdbc:db2://machine.com:1234/INSTANCE:traceFile=c:/db2.txt;traceLevel=-1;

В конечном итоге приложение, использующее JDBC, просто остановится, и в файл журнала больше не будет записываться никаких данных. Выполнение TSO NETSTAT на мэйнфрейме показывает около 50 сеансов в состоянии ESTABLISHED.

Теперь мы знаем, что это проблема на стороне мэйнфрейма, поскольку, когда это происходит, нет JDBC-соединение с этим экземпляром будет работать (с любого клиента). В этот момент мы должны перезапустить базу данных, чтобы продолжить.

Я погуглил довольно много вещей, некоторые из которых, кажется, указывают на то, что вам может потребоваться совершить запросов , прежде чем закрыть сессию. Возможно, сеансы остаются открытыми, потому что в коде закрытия BIRT что-то не так (по крайней мере, с точки зрения того, что ожидает DB2).

Кто-нибудь испытывал что-либо подобное раньше? Как ты это исправил (если вообще)? Есть ли способ решить эту проблему, используя только разделы URL JDBC или код Javascript в дизайне отчета?

FWIW, мы используем DB2 9.1 и BIRT 2.2.1.

1 Ответ

1 голос
/ 30 сентября 2009

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

Оказывается, есть параметр с именем IDTHTOIN в разделе DSN6FAC задания по сборке / связыванию параметров DB2 (обычно db2prefix .SDSNSAMP(DSNTIJUZ), хотя ваши настройки могут отличаться), для которого задано значение ноль в нашем случае. Этот параметр является IDLE TIME OUT для DDF потоков, а ноль означает «нет времени ожидания».

Установка этого значения в 180 решила нашу проблему. Потоки, которые удерживали замки, были закрыты, если они не выполняли никаких действий в течение этих трех минут. Установка значения меньше 120 бесполезна, поскольку потоки все равно проверяются каждые две минуты (по крайней мере, в DB2 v9).

Вам также следует установить CMTSTAT=INACTIVE для защиты потоков с хорошим поведением (тех, которые сняли все свои блокировки ресурсов, но все еще удерживают поток открытым).

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

Вы должны отредактировать элемент DSNTIJUZ, запустить задание, а затем либо перезапустить экземпляр DB2, либо выполнить SET SYSPARM.

Спасибо сотрудникам IBM в Австралии (West Perth Lab) за помощь в этом.

...