简体   繁体   中英

jdbc and z/os db2

Can someone explain why i am seeing this behaviour from java JDBC accessing z/os DB2

i have az/os db2 v10 table with three columns, two columns comprise the uniue index, the third is a pureXML column that holds an xml document of 1KByte in length.

The table has 1million rows. each row has the same xml document for testing purposes.

when i run a loop that makes 10,000 random reads of the table, where each read will always find a row the db2 server time shown in my jdbc trace file varies between 2ms and 62,000ms

what would cause such a wide rnge of response times?

also why does my jdbc trace have negative times for core and network?


[jcc][SystemMonitor:start] 
[jcc][Time:2012-08-02-11:43:48.188][Thread:main][PreparedStatement@10b4b2f] executeQuery () called
[jcc][Time:2012-08-02-11:43:48.219][Thread:main][PreparedStatement@10b4b2f] executeQuery () returned com.ibm.db2.jcc.t4.j@812862
[jcc][SystemMonitor:stop] core: 22.185222ms | network: 21.831545ms | server: 2.956ms


[jcc][Time:2012-08-02-11:44:23.251][Thread:main][PreparedStatement@10b4b2f] executeQuery () called
[jcc][Time:2012-08-02-11:45:25.251][Thread:main][PreparedStatement@10b4b2f] executeQuery () returned com.ibm.db2.jcc.t4.j@68ef48
[jcc][SystemMonitor:stop] core: -3615.90705ms | network: -3616.401806ms | server: 61978.244ms

This is the java/jdbc environment details


[jcc] Driver: IBM Data Server Driver for JDBC and SQLJ 4.12.79
[jcc] Compatible JRE versions: { 1.6 }
[jcc] Target server licensing restrictions: { z/OS: enabled; SQLDS: enabled; iSeries: enabled; DB2 for Unix/Windows: enabled; Cloudscape: enabled; Informix: enabled }
[jcc] Range checking enabled: true
[jcc] Bug check level: 0xff
[jcc] Default fetch size: 64
[jcc] Default isolation: 2
[jcc] Collect performance statistics: false
[jcc] No security manager detected.
[jcc] Access to package sun.io is permitted by security manager.
[jcc] JDBC 1 system property jdbc.drivers = null
[jcc] Java Runtime Environment version 1.6.0_21
[jcc] Java Runtime Environment vendor = Sun Microsystems Inc.
[jcc] Java vendor URL = http://java.sun.com/
[jcc] Java installation directory = C:\Program Files\Java\jre6
[jcc] Java Virtual Machine specification version = 1.0
[jcc] Java Virtual Machine specification vendor = Sun Microsystems Inc.
[jcc] Java Virtual Machine specification name = Java Virtual Machine Specification
[jcc] Java Virtual Machine implementation version = 17.0-b17
[jcc] Java Virtual Machine implementation vendor = Sun Microsystems Inc.
[jcc] Java Virtual Machine implementation name = Java HotSpot(TM) Client VM
[jcc] Java Runtime Environment specification version = 1.6
[jcc] Java Runtime Environment specification vendor = Sun Microsystems Inc.
[jcc] Java Runtime Environment specification name = Java Platform API Specification
[jcc] Java class format version number = 50.0
[jcc] Operating system name = Windows XP
[jcc] Operating system architecture = x86
[jcc] Operating system version = 5.1
[jcc] File separator ("/" on UNIX) = \
[jcc] Path separator (":" on UNIX) = ;
[jcc] Dumping all file properties: {  }
[jcc] pureQuery present = false

Database product name: DB2 Database product version: DSN10015 Driver name: IBM Data Server Driver for JDBC and SQLJ Driver version: 4.12.79

z/OS has the world's most sophisticated dispatcher with all sorts of controls on how resources are handed out...this is a relic from the days when hardware was expensive, and businesses wanted control over where those scarce resources went.

An example is performance periods. This is a way you can give short-running programs fantastic response time, while preventing longer processes from hogging resources. On a busy system, trivial work runs instantly, but the heavy resource users get slowed down. This could easily be part of what you're seeing.

Still, there are many, many variables...think of all the components involved: the client program, the network, LPAR hypervisor, the z/OS TCP/IP stack, DB2 - and then all the physical stuff like the disk farm, memory, etc. Any of these can introduce variability in response times.

There are very sophisticated performance monitoring products from IBM, CA and others that will give you more details than you'd every want. If your organization has any of these tools, it just takes a moment for someone with a trained eye to tell you what's going on.

Slightly above a minutes wait smells like a timeout set for a minute somewhere. Could it have been your app that could not allocate enough threads to make the requests (asynchronously)? Or something similar timing out in the server - 10000 sequential or parallell requests is a quite heavy load for any db.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM