Hi, We're working on a java webapp and using a derby database (v10.5) in embedded mode. The first version of the application went live about 2 months ago. The application gets used for making invoices and we also store the XML of an invoice document in the derby DB (input data for generating a PDF against a template). Today, the database is about 1,7GB on disk.
During these 2 months, we've released some minor upgrades, including database migration scripts (like extra tables for new functionality). Now we've noticed that, when we ran our latest upgrade, the database has suddenly shrunk to a size of 600MB. This latest upgrade contained a migration script that dropped a no longer needed timestamp column on practically every table. It's after executing this script that the shrink happened. You can see about practically every .dat file getting touched (or rebuilt) and this shrinks the seg0 folder. We did some debugging and hit suspend when the disk size started shrinking, it lead us to a Derby class called "ReclaimSpace". We're afraid the database will start using up unnecessary space again soon, and of course, we're not going to have a similar migration script in every upgrade. Why is derby so greedy with disk space (in our configuration)? I'm also not sure what made the database grow in the first place. Was is just using the DB or was it the migration scripts from the previous releases, I don't know. Is there an elegant way to configure derby to do this cleaning continuously, or to let our webapp instruct derby to do some cleaning? We're launching the webapp from within a small java webstart app (we launch a Jetty and attach our war file), so it's even OK for us to write some java code to do it programmatically. We've found this, but it's on a per table basis :-( http://db.apache.org/derby/docs/10.1/adminguide/cadminspace21579.html http://db.apache.org/derby/docs/10.5/ref/rrefaltertablecompress.html By the way, as a comparison, we're running about 10 of these webapps on different desktop PC's. Each webapp synchronizes its data to a server running a postgresql 9 database. This means that this postgres database accumulates all the data of these 10 webapps (some data is shared, so it's not times ten). The size of this postgres DB is less than 1GB, which sounds OK against the 600MB of one of those webapps, but not against 1,7GB for one webapp. Any help on all of this would be more than welcome. Kind regards, Tim De Meyer
