[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mumps-l
Subject:    Re: Defragmenting a DSM database
From:       phil pybus <ppybus () intersys ! com>
Date:       1999-03-24 18:25:30
[Download RAW message or body]


Think I agree with Matthew.
Generally, Mumps/Cache databases do not get very fragmented, and I have heard
more negative results from compression than positive !

Of course there may be some applications or some globals where a huge number
of random deletes have occurred, then it might be worth considering.  But not
if you are going to insert records back into the 'older' parts of your
database (block-splitting !)

I was wondering - is it that Cache/Mumps systems require so little system
maintenance that people are 'looking for things to do' ??

Phil


At 15:12 03/24/99 -0000, you wrote:
>Why do you want to de-fragment the globals ?
>
>>From past experience of doing this I suggest not bothering unless the
>global is static - no sets or kills taking place, or almost all data access
>is $Ordering through large globals.
>
>In an active system, each global would use about 30% less space afterwards,
>but within a few weeks would actually use 10-15% more space (with no
>increase in the number of nodes), and much more on a database that is
>growing. This is due to most subsequent sets requiring a block split to
>take place.
>
>This results in needing to perform this process every few weeks if any
>benefits are to be maintained.
>
>As to performance, most updates will take place to multiple globals, which
>will all be growing at the same time, this will result in most data related
>to a logical record being located in blocks physically close together and
>parts of all globals will be placed (automatically) on all disks, probably
>reducing the access time.
>
>If you still want to go ahead, the suggestion of sequentially killing and
>re-adding all nodes is probably the easiest to implement if free space is
>low.
>
>For best performance without having to worry about global placement, etc,
>using Stripe sets (Raid 0) or Raid 5 is probably the best method.
>
>Matthew Gage
>QMI Limited
>
>
>-----Original Message-----
>From:   Hulsey, Bruce B [SMTP:HulseyBruceB@exchange.uams.edu]
>Sent:   16 March 1999 21:23
>To:     MUMPS-L@UGA.CC.UGA.EDU
>Subject:        Defragmenting a DSM database
>
>Greetings!
>
>I am running DSM 6.6b.  Is there any utility available which will allow me
>to 'defragment' the globals in a DSM database?  I know I can defragment the
>VMS .GLS file but I would like to efficiently reposition the global blocks
>within the database.  I do _not_ have enough room or sufficient available
>down time to use %GBS and %GBR to backup, delete, and restore the globals.
>Is there anything that will allow an 'in-place' defragmentation of DSM
>globals?
>
>---
>Bruce Hulsey
>Arkansas Cancer Research Center
>University of Arkansas for Medical Sciences
>
Phil Pybus, InterSystems Thailand
Cache : New Dimensions in Transaction Processing
<http://www.intersys.com>

[prev in list] [next in list] [prev in thread] [next in thread]