Deleting data from GT.M

Hi

When I delete some data from database the is not smaller, after that
when I do extract from database and delete database files and load that
extract to that same database, then database files are smaller. is it
the only way to have smaller database files after delete something from
it?


Regards
Chaku

chaku wrote:
> When I delete some data from database it is not smaller

This is very reasonable and completely harmless behavior.
There is no reason to be concerned about it.

It is reason, what happens when file grow up to disk limit? I think
this is not good idea to let this problem without solution.

Denver napisal(a):
> chaku wrote:
> > When I delete some data from database it is not smaller
>
> This is very reasonable and completely harmless behavior.
> There is no reason to be concerned about it.

chaku wrote:
> It is reason, what happens when file grow up to disk limit? I think
> this is not good idea to let this problem without solution.
>
> Denver napisal(a):
> > chaku wrote:
> > > When I delete some data from database it is not smaller
> >
> > This is very reasonable and completely harmless behavior.
> > There is no reason to be concerned about it.

Mumps will re-use space released by deleting data before it attempts to
increase file size..

Bad idea to release disk space to OS when deleting data as the file
will become fragmented when it expands at a later date, always try to
create M data file at correct size & make sure no fragmentation for
optimum performance.

Mike

On Dec 14, 4:00 am, "MikeW" <mike.woodw...@dbh.nhs.uk> wrote:
> chaku wrote:
> > It is reason, what happens when file grow up to disk limit? I think
> > this is not good idea to let this problem without solution.

[KSB] In a production environment, I hope you will check disk usage so
that you detect when you are likely to run out of disk space long
before it happems. In a development environment, where a software bug
may cause a database to grow, you can set the automatic extension to
zero. GT.M will issue errors (refer to the documentation) when it is
not able to extend a file because it is out of space or because the
file system is out of space.

> > Denver napisal(a):
> > > chaku wrote:
> > > > When I delete some data from database it is not smaller
>
> > > This is very reasonable and completely harmless behavior.
> > > There is no reason to be concerned about it.Mumps will re-use space released by deleting data before it attempts to
> increase file size..
>
> Bad idea to release disk space to OS when deleting data as the file
> will become fragmented when it expands at a later date, always try to
> create M data file at correct size & make sure no fragmentation for
> optimum performance.

[KSB] This is good advice. In any case, GT.M does not release space
from a database file. You can use mupip reorg to compact the data
within the file while an application is in use, but GT.M will not
release unused space from the file back to the operating system.

Regards
-- Bhaskar
ks dot bhaskar at fnf dot com <-- send e-mail here

chaku wrote:
> Hi
>
> When I delete some data from database the is not smaller, after that
> when I do extract from database and delete database files and load that
> extract to that same database, then database files are smaller. is it
> the only way to have smaller database files after delete something from
> it?
>
>
> Regards
> Chaku

Try thinking about how you'd go about implenting a database from
scratch. You could store all the data in a big array, of course, but
you wouldn't want to have to re-copy the whole databasse (or most of
it) to fill in "holes". Of course, you don't want to insert data at
random, because then searching for it could take a very long time. You
also don't want to allocate data storage in arbitrary sized chunks
because the blocks of data need to align in some reasonable way. So,
you've got a few things going on here: You might be adding and deleting
data from a single block, or the system may be just marking a block
free, so that there is room for other contiguous pieces of data to
grow. These are both issues that arise with ordinary file systems, too.
What makes databases interesting is that you need to allow essentially
unbounded "room to grow", and you need to keep access time under
control, so it dends up being a kind of balanced tree structure. If you
know about red-black trees or one of their cousins, then you have the
basic idea. But BINARY trees are inappropriate for a couple of reasons:
Search time can still be long if the branching factor is only 2, and
you don't want to allocate storage in units of only a few bytes, so you
instead, you end up uing similar data structure with bigger blocks and
a larger branching factor known as a B-tree.