DB2로 Z/OS에서 약간의 한계를 치십시오. 연결 JDBC T4 드라이버

Question

Z/OS에서 DB2에 연결하는 응용 프로그램이 있으며 잠시 후 메인 프레임 측에 자원 제한이 발생하는 것 같습니다. 우리가 BIRT를 사용하고 있기 때문에 JDBC 코드에 대한 유일한 컨트롤은 URL 자체의 Stanzas를 사용하는 것 같습니다. 보고서 디자인 내에서 JavaScript를 사용하여 가능할 수 있지만 연결 또는 문 (SQL 자체 제외)에 대한 직접적인 Java 제어가 없습니다 (물론 SQL 자체 제외). 따라서 우리는 다음과 같은 것로 디버깅을 켤 수 있습니다.

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

결국 JDBC를 사용하는 응용 프로그램은 단순히 중지되며 더 이상 데이터가 로그 파일에 기록되지 않습니다. a TSO NETSTAT 메인 프레임에서 약 50 개의 세션이 표시됩니다 ESTABLISHED 상태.

이제 우리는 이것이 메인 프레임 측의 문제라는 것을 알고 있습니다. 아니요 해당 인스턴스에 대한 JDBC 연결이 작동합니다 ( 어느 고객). 이 시점에서 계속하려면 데이터베이스를 다시 시작해야합니다.

나는 꽤 많은 것들을 googed했는데, 그 중 일부는 당신이 커밋해야 할 수도 있음을 나타냅니다. 쿼리 세션을 마치기 전에. Birt Close 코드에 문제가 있기 때문에 세션이 열려있을 수 있습니다 (적어도 DB2가 기대하는 측면에서).

전에 이런 경험을 한 사람이 있습니까? 어떻게 고치 셨나요 (만약). 보고서 디자인 내에서 JDBC URL Stanzas 또는 JavaScript 코드 만 사용하여 해결할 수있는 방법이 있습니까?

FWIW, 우리는 DB2 9.1 및 Birt 2.2.1을 사용하고 있습니다.

Answer 1

이것은 실제로 다른 포럼에서 해결되었습니다. 나는 여기서 후손을위한 솔루션을 복사하고 있습니다.

호출되는 매개 변수가 있음이 밝혀졌습니다 IDTHTOIN 에서 DSN6FAC DB2 매개 변수의 섹션 어셈블리/링크 작업 (일반적으로 db2prefix.SDSNSAMP(DSNTIJUZ) 설정이 다를 수 있지만) 우리의 경우 0으로 설정되었습니다. 이 매개 변수는 IDLE TIME OUT ~을 위한 DDF 스레드와 0은 "타임 아웃 없음"을 의미합니다.

이것을 180으로 설정하면 문제가 해결되었습니다. 잠금 장치를 잡고 있던 실은 그 3 분 동안 활동이 없다면 종료되었습니다. 스레드는 어쨌든 2 분마다 확인되므로 (최소한 DB2 V9에서) 스레드는 120 세 미만으로 설정하는 것은 유용하지 않습니다.

당신은 또한 설정해야합니다 CMTSTAT=INACTIVE 잘 행동하는 스레드 (모든 리소스 잠금 장치를 공개했지만 여전히 스레드를 열어두고있는 스레드)를 보호합니다.

스레드가 보고서 용이기 때문에 이것은 우리의 특정 문제에 대해 괜찮다는 것을 명심하십시오. 그들의 행동은 세션을 열고보고를위한 데이터를 얻은 다음 더 이상 세션이 필요하지 않은 것입니다. 장기 실행 세션이있는 경우 조심해야합니다 (어쨌든 3 분 이상 잠금 장치가있는 세션은 의심되는 경우가 있습니다).

당신은 편집해야합니다 DSNTIJUZ 멤버, 작업을 실행 한 다음 DB2 인스턴스를 재활용하거나 실행하십시오. SET SYSPARM.

IBM Australia (West Perth Lab)의 도움이되는 Bods에게 이것을 위해 이것을 소개해 주셔서 감사합니다.