Here is a note on Performance and Ksam files.  This may help with your
testing.  You are however testing apples and oranges....Ksam is not a SQL
database.


KSAM64: PRO AND CONS DocId: KBAN00001093   Updated: 20040622

DOCUMENT
KSAM 64 has better performance the KSAM/XL.

This is not a true statement.

The real differences between KSAM/XL and  KSAM 64 is that
KSAM 64 will hold more records and the index is bigger.

Is KSAM/XL faster than KSAM/3000?

Is KSAM 64 faster than KSAM/3000 and or KSAM/XL?

The  answer is it depends.  For the most part KSAM/3000 has a
better write performance then KSAM 64 and KSAM/XL files [1653125344 and
1653042903}.  Both KSAM 64 and KSAM/XL files have a better delete
performance then KSAM/3000

All KSAM files use B-trees and that's the real penalty of a load
or update, balancing those trees.

XM Overhead

Fcopying to a new KSAM 64 file avoids the XM overhead.  So to avoid
XM overhead the customer must do the following;

File myfile;REC=,,,,KSAM 64;,,etc
Fcopy from=KSAM/XL;to=(*myfile);NEW

Building a file and then copying to it does not avoid the XM overhead.
The following would have XM overhead.

Build myfile;REC=,,,;KSAM 64,,,,etc
Fcopy from=KSAM/XL;to=(myfile)

Use OPTMBLK (better performance?)  All this option would really do is
more efficiently use disk space, and it has a bug, this option will cause a
SYSTEM ABORT 614 ,not good. CR#  [8606208699/STARS-ACTIVE/English]

Other Known Problems

CR#  [8606356250/STARS-ACTIVE/English]  patch [GR for 7.5] MPEMXP0.
Problem is with the reuse option.
The problem is that reuse does not work and the file appears to fill up,
as if reuse was not used.

CR# 8606216742 no patch.
The problem listfile options 8,9,10,11 do not report the correct number of
readers/writers nor the exclusive mode when performed on a KSAM 64 file.

KSAM 64 files make a great "look up" tool but adding records to very large
files can cause periodic performance hits when blocks split and trees have
to be rebalanced. {This is also true for KSAMXL files).

I would like to recommend.
KSAM 64/XL: PERFORMANCE DocId: KBAN00000748


Blocking factors of a KSAM 64, how is this calculated:

 When building a KSAM/XL file, the system does not use user-specified
blocking factors. The system computes an optimal blocking factor, based on
the key structure. The KSAM/XL file includes the key structure.   This is
the same for KSAM 64.

KSAM 64 uses the requested key blocking factor for all of your keys to
determine the largest key block size. This size is then used to set the
actual key blocking factor (which may be larger but never smaller than the
requested (value). This method results in the best use of key file space.

Blocking factors only really made a significant difference on MPE IV where
there was no disk caching and disk i/o was such a big deal.  In the olden
days of classic MPE, data was read in blocks, determined by the blocking
factor specified.  MPE/iX reads a fixed number of bytes regardless of the
blocking factor, and in that sense the blocking factor is "ignored".


KSAM 64 TOOLs

There are no tools for KSAM 64.  KSCHKIX is for KSAM/XL
files, it does not do recovery.  This tool provides structure information
only.  KSAMUTIL is for KSAM/3000 files.  It does do recovery and
provides structure information on KSAM/3000 files only.

XM

XM does not seem to be a real factor when it comes to KSAM 64.  A
good note on xm:  6.5 and later is: XM: 6.5 changes to Transaction
Manager DocId: KBAN00001073


BOTTOM LINE:

Using KSAM 64 as a lookup tool is good, using KSAM 64 as a
database is not good.

Performance can be trouble because of the b-tree index...the more keys and
duplicates the worst the performance.  So the answer to KSAM Performance,
KSAM64, KSAM/XL, KSAM/3000 is:  it depends on how the file is going to be
used....


Cathlene Mc Rae
sr response center engineer

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *