I am not sure what this application is doing. In general the space
associated with a table that is freed by deleting rows is available
for subsequent inserts. Without using compress the max size of the
table (when there were the most rows) stays allocated. After deletes
subsequent inserts to the same table use the exising deleted space.
This compress is not done automatically as many applications perform
better if the space is left allocated and automatically reused for
subsequent inserts. It would not be hard to create a system procedure
that would automatically do this - though in many cases the app itself
will know better when to call it than derby.
For most applications this works well, it does not work well for an
app that deletes all it's rows and subsquent inserts are to different
tables.
Hemant Gaur wrote:
Many thanks Knut,
I was able to get all the files shrinked using this.
So this has to be done manually every time using tht ij tool, else the
DB files will keep on growing or do we have some setting in derby which
can perform this cleanUP.
Regards,
Hemant Gaur
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 2:10 PM
To: Derby Discussion
Subject: Re: Derby DB Size
Hemant Gaur <[EMAIL PROTECTED]> writes:
Hi,
I am using the OpenJMS with derby DB. I ran some performance tests and
at the end of it I found DB folder size in 7.1 GB. The opemJMS clears
the tables after the messages are delivered. I verified that the
tables
don't have much data using in. Why then there are large sized .dat
files
in the database folder? Is there any DB configuration parameter
which
can be used to limit this size and hence the derby does the clean up
before the next insertion?
Hi Hemant,
It is possible to compress the tables to reclaim unused space. See
http://db.apache.org/derby/docs/10.2/ref/rrefaltertablecompress.html
for details.
