× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Logical File Rebuild time
  • From: "David Prowak" <prowakd@xxxxxxx>
  • Date: Fri, 2 Oct 1998 10:47:15 -0400

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 
> +---
>      
> 
> 
> +---
> | 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
> +---
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.