  Global pages and Ingres 
 The Question is:
 
My database will not come up after increasing
the number of GBLPAGES to be used.  I am using
Ingres 6.4 DBMS and have the following:
 
VAX/VMS V6.2 7630 (1 Gig Memory):
 
GBLPAGES          750000    15000       512   4194176   Pages
GBLSECTIONS         3072      250        60      4095   Sections
GBLPAGFIL         150000     1024       128   4194176   Pages
 
591 Global Sections Used,  198722/551278 Global Pages Used/Unused
 
 
I use the run command to start a detached
process.  I want to start three DBMS servers
that will use a single shared_cahce to hold
the DBMS working pages.  I set the
/extent=150,000 (WSMAX=150,000)
/working_set=100,000
/maximum_working_set=80,000
(I read that the larges value for the
 last two is 64K, it gets truncated)
 
There is a switch for the DBMS to allowcate
shared_cache in global memory.  It is in
Ingres pages (4 VMS pages = 1 Ingres page)
 
/DMF=(/read_ahead=32, read_cnt=100,
      cache_size = 20000)
 
This should set aside 92,800 VMS GBLPAGES.
 
?Question?
1) Is the global pages (section, files) at
all dependent on the Working Set settings?
If so, how?
 
2) Using the above settings, the DBMS process
comes up running.  If I increase the
Cache_size=40000, the DBMS process does not
get created.  There should be enough memory
(GBL) correct?
 
3)Can you quickly show how GBLPAGES,
GBLSECTIONS, &amp; GBLPAGFIL are related?
 
4) Is the account's process settings (WS, etc)
 that creates the detached independent of the
detached process if the above switches are used?
 
 
 The Answer is:
 
    0: The Wizard strongly recommends contacting the folks at Ingres
    support for assistance with resolving an Ingres database problem.
 
 
    1: No. Working set sizes only control how much virtual memory may be
    in physical memory simultaneously for one process only.  Global pages
    are not charged against the working set.
 
 
    2: Not necessarily. Depending on the exact nature of the global cache
    (since the Wizard is not familiar with this data base, this is a best
    guess), it's likely that the global pages used must be contiguous.
 
    It is quite possible that even with 550000 free GBLPAGES, the largest
    contiguous block is smaller than 200000 -- much like disk storage,
    it is possible for global page tables to become fragmented. Use the
    lexical function F$GETSYI("CONTIG_GBLPAGES") to find out:
 
    	$ WRITE SYS$OUTPUT F$GETSYI("CONTIG_GBLPAGES")
    	142362
 
    If the cache is backed to the page file, the most likely explanation
    is that your GBLPAGFIL parameter is much too low.
 
 
    3: In short, they are not related.
 
    GBLSECTIONS controls how many global sections can exist on a system
    simultaneously. It is independent of the size of the sections. So a
    large number of small sections may take less GBLPAGES than a small
    number of large sections. The parameter is cheap, so aim for at least
    30% free at all times. In practice free sections are usually higher
    and, in the wizard's experience, problems due to insufficient global
    sections are very rare.
 
    GBLPAGES is the total number of pages in all global sections. In
    addition to considering the raw number of pages, you should also
    consider fragmentation, especially when dealing with large sections.
    There is also the issue of life time. Remember that deleting or
    replacing a global section is not necessarily synchronous, so, if you
    need to replace a particular section frequently, make sure you have
    sufficient pages for 2, or maybe even 3 CONTIGUOUS copies of the same
    section. In your case you want a section of around 180000 pages. If you
    want to be able to recreate it, I'd suggest allocating 600000 (or more)
    pages for that purpose. GBLPAGES are cheap, but not free. They cost 4
    bytes of physically resident memory for every 128 pages, so your 600000
    pages would cost 12.5Kbytes. Problems due to insufficient absolute or
    contiguous GBLPAGES are relatively common. Aim for at least 20% free at
    all times. When playing with large sections, go for 50-60% free. You
    can determine your peak usage from AUTOGEN:
 
    	$ @SYS$UPDATE:AUTOGEN SAVPARAMS SAVPARAMS	! Record feedback data
    	$ SEARCH SYS$SYSTEM:AGEN$FEEDBACK.DAT GBLPAGES
    	GBLPAGES_CUR = 250000
    	GBLPAGES_PEAK = 107262
 
    GBLPAGFIL is a "blade guard". Whenever virtual memory is created, it
    must be given a "backing store" (that is, somewhere to put the pages
    when they are not in physical memory). For a global section, the store
    may be an ordinary disk file, but it may also be the paging file. The
    choice is made when the section is created. Since the lifetime of a
    particular global section may be longer than that of the process which
    creates it, it is not possible to "charge" the page file usage of a page
    file backed global section against the quota of the creator. On the
    other hand, the pagefile usage must have some sort of quota, otherwise
    a nonprivileged user could consume all available pagefile space simply
    by creating a large enough global section. So, GBLPAGFIL is like a
    system wide PGFLQUOTA for pagefile backed global sections. In setting
    it remember that RMS global buffers must be counted, and the general
    rule of thumb is to keep pagefiles at least 50% free. If your section
    is pagefile backed (which is likely), you need to allocate at least
    200000 pages for it, plus any other requirements. Also remember that if
    section replacement is asynchronous, you may need allocation for 2.
    So, I'd suggest you start with GBLPAGFIL=550000. Just make sure you
    have sufficient page file that a user accidently or deliberately
    consuming all of GBLPAGFIL won't deplete your page file enough to hang
    your system. You can check your remaining of GBLPAGFIL in SDA:
 
    	$ ANALYZE/SYSTEM
    	EXAMINE MMG$GL_GBLPAGFIL
        MMG$GL_GBLPAGFIL:  00006A01   ".j.."
        EVALUATE 00006A01			! convert to decimal
        Hex = 00006A01   Decimal = 27137
 
    As of OpenVMS V7.1, GBLPAGFIL is a dynamic parameter. On prior versions
    changing it required a reboot (though you may be able to locate hacks
    around the web with which you could raise it dynamically, just don't
    complain to the wizard if you crash your system using it!).
 
 
    4: Given sufficient privilege (IMPERSONATE, as the DETACH privilege
    is now known) you may give a detached process a higher quota than the
    creator process. Without privilege, you are limited to the quotas of
    the creator.
 
    The Wizard suspects that your problem is simply that the GBLPAGFIL
    setting is too low.
 
 
