[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ilbbak::ibi_focus

Title:FOCUS, from INFORMATION BUILDERS
Moderator:ZAYIUS::BROUILLETTE
Created:Thu Feb 19 1987
Last Modified:Mon May 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:615
Total number of notes:1779

104.0. "Large Database Design Considerations" by NRPUR::CUSACK () Thu Aug 04 1988 14:50

    I am going to be developing a database to be used strictly for 
    reporting purposes, and I expect the file will be in excess of 
    50,000 blocks (65,000 records).  Can anyone with experience using
    Focus for large databases give me some tips or things to consider
    for designing a database of this size?  I've done many smaller
    applications in Focus, but was wondering what I may have to do
    differently for a larger database.  Any help will be appreciated.
    
    Thanks,
    
    Mike Cusack
T.RTitleUserPersonal
Name
DateLines
104.1FINE TUNING TIPSPLANIT::RYANThu Aug 04 1988 20:2958
    Try these ideas:
                         
    1.  I/O is everything.
    
    2.  Figure out which fields will be used all the time (a), sometimes
    (b), and rarely.  Then design a master where you deposit the b and c
    fields into unique segments.  While this increases the number of
    segments/pages, it decreases I/O because FOCUS can now put more
    like-instances into one page of memory.  For example, if you had a
    master with only a 10 byte field in a segment, and you went to query
    the segment, FOCUS could load up 4096 / 10 instances in one page. In
    contrast, if you had a number of fields in the segment which totaled
    100 bytes, you could only get a fraction of this total into memory. 
                          
    3. If you use more than one file in most of your request, stick the
    reference databases on another disk pack to reduce disk contention.
    
    4.  Avoid joins when you can use static cross-references.  Static
    cross-references 'burn' pointer information into the primary file
    concerning the addresses of the secondary files.  While FOCUS updates
    these pointers anytime the data are accessed by a user (so long as the
    user has r+w access), you can also get clever and update the pointers
    at night or on the weekend by running some silly job that does
    something like COUNT ENTRIES BY X BY Y etc.
    
    5.  Change the disk cluster size on a disk to either 8 or 16.  This
    will substantially cut down on disk I/O because FOCUS will be able
    to perform a read in one I/O instead of 3 (default disk cluster
    size of 3).  Changing the cluster size to 16 means greater savings
    but also means that small files/non-FOCUS files will take up more
    space).  This is important.
                                       
    
    6.  Use the god-awful REBUILD facility periodically - maybe once a
    month.  REBUILD places like keyed items together physically, instead of
    logically.  REBUILD is a pig, but used on the weekend or at night will
    mean the difference between night-and-day retrieval speed. This becomes
    especially critical if you are performing frequent updates (read:
    daily) where data comes randomly in any order). 6.  Watch for disk
    fragmentation. 
    
    7.  If you running large updates, make sure you use VMS SORT before you
    input into FOCUS.  This not only saves update time, but also help
    insure that FOCUS will better tie physical/logical keys together (see
    #6). 
        
    8.  Watch out for disk fragmentation.  Just as a file can become
    disorganized, so can disks.  When the disk gets fragmented, do a
    backup and restore on it.  This sounds like a pain, but it can make
    a world of difference.
    
    
    Hopes this helps.  In working with the AIC databases, we spent a
    couple of years fine tuning large database - all so that we could
    avoid using summary files.
    
    -rpr-