RE: SMP experiences

> SMP will help Query Optimizer a great deal so if you are using lots of
> SQL or OPNQRYF in your processing, you should see a notable performance
> improvement.

Most of our nightly processing uses native I/O but a lot of the newer stuff
and enhancements are being done using SQL.

> On the native I/O side of things, the only benefit I could think of with
> SMP is parallel index maintenance, which in itself may give you a boost
> in performance if your processing is update intensive and you have a lot
> of indexes (LFs) being maintained.

There is a lot of LF updating I believe.  We have three files that get hit
pretty hard every night.  The smallest has 94+ million records with 21
indexes and the largest is over 400 million with 6 indexes.  Currently the
QQRYDEGREE system value is set to *I/O prior to nightly processing.  I'm
having trouble finding much information on this option.  Are we already
getting the benefit of parallel index maintenance or should it be changed to
something else?  


> As for drawbacks, the only one I heard a customer mention is the
> aggressive utilization of system resources.  What I mean is, if you have
> some really intensive query app, optimizer will try to use 100% of CPU
> to fulfill its requests, which may slow down your interactive
> throughput.  It doesn't sound like that would be a problem on your
> system though, as you say you have 16 processors and you plan to use SMP
> to help nightly batch processing.  And even if it was a problem, there
> are ways (and products) that can help you deal with resource allocation
> management.

Doesn't this only happen if SMP is set to *MAX?  What I have read so far
implies that the *OPTIMIZE setting sets boundaries based on the memory pool
the job runs in to prevent what you have described from happening.  Am I
missing something?

Rick