RE: Database server jobs and SQL tuning

Found a reference to this in a thread named "QZDASOINIT and ODBC
performance", but the only suggestion was to change the time slice to 200
and the run priority to 50.  I'm not sure how lowering the time slice from
2000 to 200 would increase speed.  Anybody?

Also, there was mention made of the processor speed affecting ODBC
performance.  I don't understand this.  If I paraphrase, "the overall speed
is only as fast as the slowest link", then what does the processor have to
do with this?  It would seem to me that communications would be the slowest
piece of the puzzle here.

- Dan Bale

> -----Original Message-----
> From: Colin Williams [SMTP:colin.williams@technocrats.co.uk]
> Sent: Wednesday, May 17, 2000 11:09 AM
> To:   'MIDRANGE-L@midrange.com'
> Subject:      RE: Database server jobs and SQL tuning
> 
> Scan the Midarange archives for QZDASOINIT, I was looking for something
> else, 
> but I'm sure I saw something in there about improving the performance of
> QZDASOINIT 
> 
> -----Original Message-----
> From: McCallion, Martin [mailto:MccalliM@Midas-Kapiti.com]
> Sent: Wednesday, May 17, 2000 2:46 PM
> To: 'midrange-l@midrange.com'
> Subject: Database server jobs and SQL tuning
> 
> 
> Hi folks.
> 
> We're currently in the process of testing an application where we've
> ported the database from SQL Server to the AS/400.  The client is
> written in VB and uses ODBC to communicate with the database.  One of my
> colleagues is currently testing it, and he has _33_ instances of the
> QZDASOINIT job servicing his user profile at present (he is working at a
> single workstation, I should add).  To my mind this seems preposterously
> many.  Does anyone know what causes the system to start a new instance
> of this job when there is an existing connection already?
> 
> What testing we have managed to do so far has given very disappointing
> results in terms of performance.  Clearly we'd all expect the AS/400 to
> wipe the floor with NT, and I'm fairly sure that the performance issues
> can be resolved with a little tuning.  Performance way well be related
> to the vast number of jobs referred to above, which is why I raised that
> first.
> 
> I spent most of yesterday searching the web and Infocenter for SQL
> performance information, and I'm investigating the DBMON commands
> (STRDBMON and ENDDBMON).  But I wondered whether anyone had any ideas;
> I'm sure some of you have been through something like this.
> 
> On specific question was, what would the difference be if we created our
> database as an SQL collection?  I found an IBM page that describes the
> very thing we're trying to do
> (http://www.as400.ibm.com/tstudio/dataware/migrate/Index_M.htm) and we
> had already done most of it, except that we just created a library and
> added the journalling objects manually.
> 
> Any thoughts, manuals, web sites, gratefully received.
> 
> Cheers,
> 
> Martin.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---