Antwort: QZDASOINIT and sytem performance?

Hi TitanRebel!

I am sorry, but you can not blame SQL, nor can you blame Java for the bad 
performance. The only reason for the bad performance is either bad 
database design or bad coding of your SQL statements in your application. 

First of all are you using Prepared Statements with parameter marker?
Do you have the correct sort sequence defined at JDBC level and database 
level. If your access path are using another sort sequence then defined in 
your JDBC connection. the JDBC driver can not use this access pathes and 
have to create new one.
Debug the QZDASOINIT Job and see what suggestions the query optimizer 
makes.
Use the new profiling feature in WDSc 6.0 to find the methods in your Java 
programm which performs weak.

I hope this tips helps.

Greetings from Austria

Ralf




TitanRebel <TitanRebel@xxxxxxxxxxx> 
Gesendet von: java400-l-bounces+ralf.petter=artweger.at@xxxxxxxxxxxx
20.10.2005 17:22
Bitte antworten an
Java Programming on and around the iSeries / AS400 
<java400-l@xxxxxxxxxxxx>


An
Java Programming on and around the iSeries / AS400 
<java400-l@xxxxxxxxxxxx>
Kopie

Thema
QZDASOINIT and sytem performance?






QZDASOINIT prestart jobs service JDBC requests.  When running, they tend 
to "grab" a lot of CPU cycles.  I assume IBM designed it this way. 
Because of this, my Java applications typically get blamed for causing 
poor overall system performance (even for interactive jobs).

Is SQL (Java or RPG) more processor intensive than direct file access 
via RPG?  If so, does anyone know of any guidelines for "up-sizing" the 
iSeries box as legacy RPG applications get converted to Java or RPG with 
SQL file I/O?

Also, can the QZDASOINIT jobs cause performance problems for Interactive 
jobs?  I've always thought that they would NOT effect interactive jobs 
because of the "Interactive Card Tax" that supposedly isolates x CPW 
just for interactive jobs (Batch jobs can't use it... right??).

Any links or advice would be appreciated.

Thanks.