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







-----Original Message-----
From: Carl McNamee <[log in to unmask]>
To: [log in to unmask] <[log in to unmask]>
Date: Tuesday, March 30, 1999 3:09 PM
Subject: Performance/image question


>                We ran into an interesting performance scenario this past
>weekend that I have not been able to figure out.
>
>                While our programming staff was working on some of our y2k
>updates they found that streaming 3 or more jobs that update our Image
>database caused a sever impede problem.  The databases they were working
>with were the original and a copy that the y2k changes were written into.
>Both databases use Omnidex index keys.  Within the databases, the detail
>datasets they were accessing are "stand alone" and do not have any master
>datasets associated with them.  They had written a program that opens the
>input and output datasets, performs a dataset level lock on both the old
and
>new databases, then performs a serial read/updates/writes for all the
>records, and lastely it releases the locks.  Each run of the program
>accessed a different detail set.
>
>                When only two jobs were running at a time there was not
>problem.  When the third program was started they started to observe
>impedes.  When a fourth job was started the impede situation caused the
jobs
>to run very slowly.
>
>                Do the wise ones on the list have any thoughts on what
could
>have caused the impeded jobs?  We do not believe that it was an Image block
>since the datasets that were being worked on were not linked to each other.
>Beyond that I'm clueless!
>
>
>
>Carl McNamee
>Systems Administrator
>Billing Concepts
>7411 John Smith Dr  Suite 200
>San Antonio, TX  78229
>(210) 949-7282
>[log in to unmask]