Why is it when I do a DELETE-ACCOUNT of a database account, the disk
space recovered is just a tenth of space consumed when the account was
restored?

Is there some type of compaction that needs to be done?

If so, how is it done?


Thanks,
Danny

This is under D3/NT (a VME account)? D3/Linux?

Both have been known to have frame "leaks", but a 90% loss seems high?!

How are you "measuring" space? via FREE or POVF? Has anything else
happened on the system between when account was loaded & removed?


ddspell-m3 wrote:

Ross Ferris wrote:
D3/Linux

I'm using the results from FREE.


Thanks,
Danny

What have you "done" in the account - for example, if you SAVE-LIST
then the results are stored in pointer-file, which is (by default)
shared across all accounts [and so would not be removed when the
account is deleted]

Was is, by any chance, an FSI file? FSI files take up very little virtual
space, so deleting one will return little if anything to the overflow table.


Mark Brown


"ddspell-m3" <ddspell (AT) yahoo (DOT) com> wrote

Mark Brown wrote:
Mark,

He is on D3/Linux

Ross Ferris wrote:
I logged in as DM and did it from the DM account.
At TCL I did a DELETE-ACCOUNT account_name.

I know don't know why you mention the pointer-file. I know that is the
DM account. I was asking about the lack of compaction or release of
disk space when I was deleting an account that had taken up 13% of my
disk space. I know because I had restored it earlier and saw the space
decrease by that percentage, yet when I removed it, I only got about 5%
back.

Do I need to delete D3 and restore it to get rid of fragmentation?

I've never done that. I don't know how to do it and because of that,
I'm afraid to risk it even when I have what I think is a good backup.


Thanks,
Danny

Sorry for the vagueness of the answer, but it kind of depends...

When you restore an account, you "carve" files out of overflow. The base
file size (for example, 13) carves "contiguous" frames, frames numbered one
after the other. When you put data into the file, it may require more
space, which is tacked onto the end of each group, one frame at a time,
using whichever frame is available next from the overflow table.

When you release a file or an account, all the frames that are being used
are released back into one of three possible overflow tables, depending on
which ones need space at that time: the local overflow table (kept for each
user), the main ovf table which you see with POVF and the "safe" table, a
set of (IIRC) 200 blocks, each at least 50 frames long, which is supposed to
be held safe in case of a crash so you have some overflow to continue
processing at least long enough to do a full save.

There are some options on the POVF command that show some or all of your
overflow. Check and make sure you're using the one that shows ALL available
overflow.

On a linux, unix, aix system, all frames should return to overflow when a
file is deleted.

It's possible that your restore merely returned space to the 'SAFE' table
and you just don't "see" the difference.


Mark Brown


"ddspell-m3" <ddspell (AT) yahoo (DOT) com> wrote

Here's what I get when I do povf:
ovf


overflow: 2327994 reserve: 1024 blocks: 34016 b-tree levels: 3
leaves: 239

I don't know if this is good, bad or just informational.


Clueless (more or less) in Dallas,
Danny