Larry P wrote: > In %SYS, D ^INTEGRIT and look at the % full data: > > Global: ^rMAC > Top/Bottom Pnt Level: # of blocks=1 8kb (27% full) With only one block, it is whatever it is.
> Data Level: # of blocks=208 1,664kb (72% full) > Total: # of blocks=209 1,672kb (72% full) This is good "efficiency". > Fragmentation is not a performance issue in Cache' the way it > is in other databases. Pretty much true. > If you have fragmentation in "active" data > that is often a good thing as its better for performance. No, it is still less than ideal, bad even. Typically, fragmentation is rarely better. But you are calling storage efficiency/compaction "fragmentation". They are not the same attribute. Of course lack of compaction can be advantageous where insertions are occurring. ABFGDCEABFGCED is compact but fragmented. AABBCCDDEEFFGG is compact and not fragmented. A B C D E F G not compact. Whether it is fragmented depends on how the term is defined. > If you have fragmentation in historical data and you wish to remove > the fragmentation to save space you can use the ^GCOMPACT > utility. Any defragmentation done be GCOMPACT is purely consequential. As you point out, compaction is advantageous for static storage allocations. > Global integrity check and compaction are both available > from the Control Panel GUI as well. But not defragmentation. > > How do I know if I have database fragmentation? You have it. But you should not care.
