Достижение некоторого предела в z / OS с помощью драйвера DB2 Connect JDBC t4

Question

У нас есть приложение, подключающееся к 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 close что-то не так (по крайней мере, с точки зрения того, что ожидает DB2).

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

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

Answer 1

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

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

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

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

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

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

Спасибо полезным сотрудникам IBM Australia (лаборатория Западного Перта) за то, что они подсказали мне это.