Another option you may consider is to disable TPI, load the data into the
base, and then re-index the base.  There are a number of factors to
consider in this approach, including whether or not the indexes themselves
are a part of the batch run processing and whether or not other users are
utilizing the base at the same time.  However, you may find this approach
faster because the 3rd party index products themselves are also a part of
the XM transaction and when the index's b-tree splits due to the addition
of data, there are a number of actions performed which add to the XM
overhead.  Given that the 3rd party products can re-build indexes quite
quickly, the added cost of this step may be less than the overall cost of
doing index maintenance at the same time as your batch processing.  This
approach may reduce your XM cost but allow you to continue to utilize XM to
protect your database integrety should a system problem occur.

I would recommend that you consult with DISC on this approach as they can
better advise you as to the potential benefits/impacts.

I simply do not know if the approach of removing b-trees, adding your data,
and then re-building the b-trees provides any benefit if you are utilizing
IMAGE b-trees for indexing also.

One other possibility you might consider, and this depends upon your
application access and the design of the database.  You might want to
enable DSEM (Dynamic Semaphores) in DBUTIL if the datasets being
locked/updated by the processes do not share any paths.
This is because IMAGE normally has a single 'put/delete/update' flag that
it internally locks at critical times regardless of the user's locking
strategy.  So even if the application is locking/processing into separate
sets, each process may queue-up on this internal flag at certain points in
processing so IMAGE can manage exclusive access to internal information.

The recent DSEM enhancement to IMAGE allows IMAGE to assign individual
flags for each 'group' of networked sets.  A 'networked' set is one or more
master/detail sets which are linked by paths.  It is possible that all sets
in a base are linked through a series of paths, in which case the new DSEM
feature provides no benefit.  But if a base has 2 or more independently
linked groups of sets which are accessed independently, using this feature
may enhance overall performance when adding/updating these independent
groups of sets.

This is a case whereby you can easily enable this feature and if it doesn't
help performance, oh well, as there is no known impact in overall
performance.  Also, you may consider enabling the prefetch flag in DBUTIL
also, as this too, may help in performance, especially if access tends to
be in a serial fashion.

Let us know if any of these approaches help!


At 08:31 AM 3/31/99 -0600, Carl McNamee wrote:
>After looking over the Perfview stuff again I believe you may have hit the
>nail on the head.  Whenever 3 or more batch jobs were running XM was active
>all the time.  If only one or two were running it was not as active.
>
>Thanks for everyones input on this.
>
>Carl
>
>-----Original Message-----
>From: Mike Hornsby [mailto:[log in to unmask]]
>Sent: Wednesday, March 31, 1999 8:14 AM
>To: Carl McNamee; [log in to unmask]
>Subject: Re: Performance/image question
>
>
>On these types of 'batch' loads one must remember that the transaction
>manager (XM) is transparently buffering, logging and posting the dirty pages
>to the volume master and to the actual virtual location.
>
>If it is at all possible you should have disabled the XM, by enabling the
>database for autodefer. I prefer to do this with dbcontrol mode 1, as this
>is a temporary situation. I do not recommend using dbutil to permanently
>disable the XM for this database unless this is a test/development
>system/account. This should cut the execution time down by at least half.
>
>Another way to improve IO performance if you can't enable autodefer
>(translated this is a production database) is to have a separate volume set
>for the group where the database is located and avoid putting any of the
>datasets on the volume master.
>
>And finally, the other IO options are to put in as much memory as will the
>box/MPE version will allow, and to use the fastest drives on SCSI/FW
>interfaces. Attached are the performance specs for selected drives.
>
>Mike
>
>
>ST-34501W, 5.591 FORMATTED CAPACITY (GB)
>RPM 10,000
>AVERAGE ACCESS (ms read/write)____________7.7/8.7
>
>ST-15150W, 4.294 FORMATTED CAPACITY (GB)
>RPM 7,200
>AVERAGE ACCESS (ms) (read/write)___________8.0/9.0
>
>HPC3010, 2.0 FORMATTED CAPACITY (GB)
>RPM 5400
>AVERAGE ACCESS (ms) (read/write)___________11.5/?
>
>HPC2490, 2.132 FORMATTED CAPACITY (GB)
>RPM 6400
>AVERAGE ACCESS (ms) (read/write)___________8.75/9.75
>
X-no-Archive:yes


/jf
                              _\\///_
                             (' o-o ')
___________________________ooOo_( )_OOoo____________________________________

                        Wednesday, March 31st

          Today in 1933 - Civilian Conservation Corps was created.

___________________________________Oooo_____________________________________
                            oooO  (    )
                           (    )  )  /
                            \  (   (_/
                             \_)