From derby-user-return-8703-apmail-db-derby-user-archive=db.apache.org@db.apache.org Fri Feb 15 18:39:52 2008 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 5719 invoked from network); 15 Feb 2008 18:39:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Feb 2008 18:39:52 -0000 Received: (qmail 22784 invoked by uid 500); 15 Feb 2008 18:39:45 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 22502 invoked by uid 500); 15 Feb 2008 18:39:44 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 22491 invoked by uid 99); 15 Feb 2008 18:39:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Feb 2008 10:39:44 -0800 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 32.97.110.151 is neither permitted nor denied by domain of Stan.Bradbury@gmail.com) Received: from [32.97.110.151] (HELO e33.co.us.ibm.com) (32.97.110.151) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Feb 2008 18:38:57 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1FIdF6V013098 for ; Fri, 15 Feb 2008 13:39:15 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1FIdF66193616 for ; Fri, 15 Feb 2008 11:39:15 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1FIdF2w024434 for ; Fri, 15 Feb 2008 11:39:15 -0700 Received: from [127.0.0.1] (bradbury-lt07.usca.ibm.com [9.72.133.135]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m1FIdEJY023390 for ; Fri, 15 Feb 2008 11:39:14 -0700 Message-ID: <47B5DC3F.2060502@gmail.com> Date: Fri, 15 Feb 2008 10:38:55 -0800 From: Stanley Bradbury User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Derby Discussion Subject: Re: Compressing DB while other process is using it References: <15483146.post@talk.nabble.com> In-Reply-To: <15483146.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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.