db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Newsham" <jnews...@referentia.com>
Subject RE: Compressing DB while other process is using it
Date Thu, 14 Feb 2008 18:00:34 GMT

Although Derby doesn't immediately release space freed up by deleted
records, it will eventually re-use that space (when new records are
inserted).  So the issue that you have is really only a problem if you are
deleting a large number of records at once and you need that space back
immediately.  If you are performing inserts and deletes interspersed with
each other, then it shouldn't be much of an issue.  Using a database as a
cache might exhibit this pattern depending on the design.

Here are some ideas:

- If you need to run an external script that accesses the database at the
same time, your application can run in embedded+server mode.
- Alternatively, it's probably esier just to put the compress "script" in
the same process.  Just open another connection to the database in another
thread.
- I have had problems compressing tables while other connections were
accessing the same tables.  To solve this, I stop all other database
activity while compressing.  I use exclusive locking (Java concurrency
utils) in my database layer to prevent concurrent access.
- If you feel forced to delete the entire database, you might consider
dropping individual tables as an alternative that gives you the flexibility
to keep some of your data.  A clever approach might be to use dynamically
named tables for your cache, and roll through tables, creating new tables
for new cached data, and deleting old tables whose data are no longer
relevant.

Hope that helps,
Jim
 
> -----Original Message-----
> From: indianiec [mailto:indianiec69@tlen.pl]
> Sent: Thursday, February 14, 2008 7:39 AM
> To: derby-user@db.apache.org
> Subject: Compressing DB while other process is using it
> 
> 
> All,
> 
> I encountered a big problem. We recently released new software and have
> big
> problems with disk space. When we developed it we did not notice that you
> need to reclaim space after you delete rows. We need to find a solution to
> that problem without releasing new software version. We just got no time.
> We
> cannot release patch either. Too much testing is needed and issue needs to
> be resolved ASAP.
> 
> We could write a script compressing DB, but because it's embedded only one
> process can access it. That means stopping main application to be able to
> do
> that.
> 
> Option number two is deleting whole database (it's used for caching and
> application can recreate it no probs), but that sounds like hack. Whe may
> need to do that if no other choise is left.
> 
> Ideas?
> 
> Cheers
> --
> View this message in context: http://www.nabble.com/Compressing-DB-while-
> other-process-is-using-it-tp15483146p15483146.html
> Sent from the Apache Derby Users mailing list archive at Nabble.com.
> 




Mime
View raw message