TRANSFER Installation and Management Guide

Partitioning TRANSFER Database Files
Troubleshooting
13198 Tandem Computers Incorporated 12–9
Partitioning
TRANSFER Database
Files
If your TRANSFER system performs poorly because your database files are too large
or because of heavy demand to access certain database files, some of these files can be
partitioned. Partitioning should be done only by someone who understands file
partitioning.
Several of the TRANSFER database files lend themselves to partitioning, while others
do not. Of the six largest or most frequently used files, five files partition effectively
by use of the first two bytes of the primary key. These five are:
Folder file (FOLDER)
Inverted Folder file (IFOLDER)
Item Data file (ITEMDATA)
Item Descriptor file (ITEMDESC)
Recipient file (RECIP)
The first two bytes of the primary key are random for all these files. To determine the
partition ranges, treat the value in these two bytes as an unsigned integer and divide
by the number of desired partitions.
The Session file (SESSION), while typically not as large as any of the files listed above,
is frequently accessed and therefore a candidate for partitioning. Partitioning this file,
however, is not as easy as partitioning the previous five files. Partitioning the Session
file is discussed in the following subsection.
You can also partition the X400 Queue (X400QUEU) file by the first two bytes of the
physical key. To facilitate this partitioning, the first two bytes of the queue-name field
are used as the first two bytes of the X400QUEU physical key.
The rest of the TRANSFER database files are not likely candidates for partitioning. In
particular, the Name file (NAME) is accessed by only one server, the NAMESRV;
therefore, partitioning the NAME file does not help performance.
Partitioning the
Session File
The primary key of the Session file comprises an internal coding for the depot, 14
bytes, and a trailing INT32 that is random, so the first 18 bytes of the primary key must
be used. Furthermore, since the internal coding for the depot is sequential, there is no
easy method for determining the partition ranges. You can FUP COPY the Session file,
note the overall range of values in the first 18 bytes, and determine the partition values
based on the number of partitions desired.
There are two methods of partitioning keys for the TRANSFER Session file, depending
on whether you need only two partitions or more than two partitions.