Re: Logical File Rebuild time

Longer record length means more disk data must be read to get the index
fields from the records being indexed.  No matter what fields you use
the system will need to get the record from the disk and pick out the
index fields.  Bigger Records = Bigger File = More I/O = Longer rebuild
time.

Larry Bolhuis
Arbor Solutions, Inc
lbolhui@ibm.net

David Prowak wrote:
> 
> Regarding Eric's reply:
> 
>    Record length.  A large record length will slow the rebuilding of an
>     access path because more data is looked at.
> 
> Why would the rec length effect the time needed to rebuild logical files?
> I thought that the access path was only concerned with the keys of the
> logical file.
> If this is correct, why would the rec length impact the logical rebuild
> times?
> 
> Dave
> ----------
> > From: eric.delong@pmsi-services.com
> > To: MIDRANGE-L@midrange.com
> > Subject: Re: Logical File Rebuild time
> > Date: Friday, October 02, 1998 10:58 AM
> >
> >
> > >From "DB2 for OS400 Database Programming":
> > --------------------------------------
> > 3.4.3.2.1 Rebuilding Access Paths
> > Rebuilding a database access path may take as much as one
> > minute for every 10,000 records.
> >
> > Note:  This estimate should be used until actual times for your
> >        system can be calculated.
> >
> > The following factors affect this time estimate (listed in general order
> > of significance):
> >
> >    Storage pool size.  The size of the storage pool used to rebuild
> >     the access path is a very important factor.  You can improve the
> >     rebuild time by running the job in a larger storage pool.
> >
> >    The system model.  The speed of the processing unit is a key
> >     factor in the time needed to rebuild an access path.
> >
> >    Key length.  A large key length will slow rebuilding the access path
> >     because more key information must be constructed and stored in
> >     the access path.
> >
> >    Select/omit values.  Select/omit processing will slow the
> >     rebuilding of an access path because each record must be
> >     compared to see if it meets the select/omit values.
> >
> >    Record length.  A large record length will slow the rebuilding of an
> >     access path because more data is looked at.
> >
> >    Storage device containing the data.  The relative speed of the
> >     storage device containing the actual data and the device where
> >     the access path is stored has an effect on the time needed to
> >     rebuild an access path.
> >
> >    The order of the records in the file.  The system tries to rebuild an
> 
> >     access path so that it can find information quickly when using that
> >     access path.  The order of the records in a file has a small affect
> >     on how fast the system can build the access path while trying to
> >     maintain an efficient access path.
> >
> >
> > All of the preceding factors must be considered when estimating the
> > amount of time to rebuild an access path.
> >
> >
> >
> > ______________________________ Reply Separator
> _________________________________
> > Subject: Logical File Rebuild time
> > Author:  <MIDRANGE-L@midrange.com > at INET_WACO
> > Date:    10/1/98 6:43 PM
> >
> >
> > Hi all,
> >
> > We're testing our Y2K conversion programs and we're in need of your
> advice.
> >
> > We have several hundred physical files comprising almost 50 million
> records.  Th
> > routine we go through is to remove all of the logical file members for
> the targe
> > physical file libraries, convert the files using a RPG programs, and then
> we add
> > ll of the logical file members back to system so that the index paths get
> 
> > rebuilt.
> >
> > Because we have access to how far along each RPG program is in the
> conversion ph
> > e, we can fairly accurately estimate how long it will take.  We are
> having diffi
> > lty determining how long it might take to add the logical file members,
> however.
> >
> > Is there any programmatic way to gather from the system just how far
> along an in
> > x rebuild is?  Even a method for coming up with a rough guess would be
> great.
> >
> >
> >
> > Regards,
> > Rich
> >
> > ============================================
> > Rich Duzenbury
> > http://rich.dyn.ml.org
> > http://vpsolutions.com
> > ============================================
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---