Re[2]: Logical File Rebuild time

     Dave,
     The only thing that makes that make sense to me is that OS400 still 
     has to load the record images into memory in order to see the key 
     field data. Very long record formats occupy more storage, fewer 
     will be available in cache, resulting in higher DB page faulting.
     
     Just a guess.....
     Eric


______________________________ Reply Separator _________________________________
Subject: Re: Logical File Rebuild time  
Author:  <MIDRANGE-L@midrange.com > at INET_WACO
Date:    10/2/98 10:47 AM


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


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