indianiec wrote:
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
You will need to release something to effect a change and it sounds like
1) releasing a script will be acceptable and
2) deleting any data in the cache tables will not be a problem.
If so here's and idea: you can minimize the downtime needed to do the
compress by overlaying the expanded DB (lets call it usedDB) with an
already prepared set of files (lets call in freshDB). The script would
need to shutdown the application and database, copy usedDB to an archive
location (just in case - I am paranoid), then copy freshDB to the
location where the application expects it to be and restart the
application.
