From: laut@alien.gici.com (Bill Laut)
Newsgroups: comp.databases.ingres
Subject: Re: Ingres on VMS with disk defragmenter
Date: 7 Oct 92 21:36:23 GMT
Organization: Gull Island Consultants, Inc.

In article <1992Oct7.080029.81@rivers>, acs_mn@rivers.acc.uwrf.edu writes:
> 
>     I remember a long time ago there was a warning not to allow a disk
> defragmenter to touch Ingres databases since the files weren't opened using
> normal RMS means and the defragmenter might move an open file causing big
> problems.
> 
>     Has this ever been fixed or it is still recommended to exclude database
> from disk defragmentation?
> 
>     We are using INGRES VAX Version 6.4/01 (vax.vms/01) running on VAX/VMS
> 5.5-1. The disk defragmenter is Dec's File Optimizer.
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Marlys A. Nelson			System Manager, Systems Programmer,
> Academic Computing			Network Manager, etc., etc.
> Univ. of WI - River Falls
> Internet: Marlys.A.Nelson@uwrf.edu

At one of our client sites, we were told that v5.5 is supposed to be compatible
with *anything*, because DEC's Optimizer uses a new(?) ACP function incorporated
into the XQP, that allows the XQP itself to move the file and make it
contiguous in the process.  To wit, since it's the XQP doing the moving, and
because Ingres still has to go through the XQP to get to the file, you
should have an ability to defrag your disks, regardless of what is accessing
them (unless its doing IO$_READLBLK or IO$_READPBLK, of course).

Anyway, at that one site I mentioned, they are running VMS v5.4-2 along with
DISKIT.  DISKIT generally seems to work fine, except that it can't touch
the actual INGRES tables themselves, because (at that place) they are almost
always open.  To address the issue of fragged INGRES tables, you can try
running ANA/RMS/FDL (true!) on it, and edit the FDL file to increase the
space allocation to accomodate your reasonable growth.  Then, when you do
defrag your disks (and with INGRES graveyard-doorknob-dead dead) do your
usual SYSMODs, etc. on the affected tables.  Then, use the CONVERT/FDL
utility to copy over the INGRES tables, making them contiguous again, and
also pre-allocating space at the end of the table to accomodate future
growth.  You can do this because the ODS-2 file system maintains both a logical
and physical EOF position.  As the table grows, and INGRES tries to expand it,
the XQP will simply push back the logical EOF to acquire the required space.
During the process, the table still remains physically contiguous on the disk.

I can appreciate your concern about defragging.  I'm the lead analyst/guru/etc
at one site running a pair of VAX-9210s, with about 50gb of disk space (and
more on the way.  Because of disk fragging, we already have our ACP parameters
so high that it takes about 10mb of paged-pool space to house the disk caches
set up by the XQP.  If we go any higher, the VAX crashes during sysinit.  We
do anything we can to defrag our disks, when we can get the downtime.

One request:  You mentioned that you were at v5.5-1 and running the DEC
Disk Optimizer.  Would you please post your experiences with it?  I'm
certain others in the group would like to hear what you say.


-- 
Bill Laut			Internet:  laut@alien.gici.com
Gull Island Consultants, Inc.	Phone:     (616) 780-3321
P.O. Box 627
Muskegon, MI  49440		>> "Usual disclaimers, apply within" <<
Newsgroups: comp.databases.ingres