Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 90738 invoked from network); 6 Jul 2010 18:27:09 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Jul 2010 18:27:09 -0000 Received: (qmail 40623 invoked by uid 500); 6 Jul 2010 18:27:09 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 40537 invoked by uid 500); 6 Jul 2010 18:27:08 -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 40524 invoked by uid 99); 6 Jul 2010 18:27:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jul 2010 18:27:08 +0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [32.97.110.152] (HELO e34.co.us.ibm.com) (32.97.110.152) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jul 2010 18:26:58 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o66IIA5q009358 for ; Tue, 6 Jul 2010 12:18:10 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o66IQJ2F218176 for ; Tue, 6 Jul 2010 12:26:21 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o66IQAhL017080 for ; Tue, 6 Jul 2010 12:26:10 -0600 Received: from [127.0.0.1] (sig-9-48-99-80.mts.ibm.com [9.48.99.80]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o66IQ8ft017025 for ; Tue, 6 Jul 2010 12:26:09 -0600 Message-ID: <4C337540.1010309@sbcglobal.net> Date: Tue, 06 Jul 2010 11:26:08 -0700 From: Kathey Marsden User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: derby-user@db.apache.org Subject: Re: How to best constrain database space with many records being inserted and deleted References: <97EB699F861AD841B5908C7CA9C956560127D9F5F694@VSERVER1.canoga.com> In-Reply-To: <97EB699F861AD841B5908C7CA9C956560127D9F5F694@VSERVER1.canoga.com> Content-Type: multipart/alternative; boundary="------------020803020200030004050405" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------020803020200030004050405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/6/2010 11:09 AM, Bergquist, Brett wrote: > > I What I am seeing is that the database is growing and it does not > seem to be reusing the deleted space. Should it be? The records > being inserted are exactly the size of the records being deleted. > The known issues in this area are: https://issues.apache.org/jira/browse/DERBY-4057 https://issues.apache.org/jira/browse/DERBY-4055 For DERBY-4055 a possible workaround is here: https://issues.apache.org/jira/browse/DERBY-4055?focusedCommentId=12680196&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12680196 Also synchronizing table access has helped some users. You can verify if you are seeing DERBY-4055 by running with a SANE build and putting derby.debug.true=DaemonTrace in your derby.properties. All that said, I have heard anecdotal reports that there may be another bug. If you can come up with a reproduction that is not either of these issues, we would appreciate it. Thanks Kathey --------------020803020200030004050405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/6/2010 11:09 AM, Bergquist, Brett wrote:

I  What I am seeing is that the database is growing and it does not seem to be reusing the deleted space.  Should it be?  The records being inserted are exactly the size of the records being deleted.

 

The known issues in this area are:
https://issues.apache.org/jira/browse/DERBY-4057
https://issues.apache.org/jira/browse/DERBY-4055

For DERBY-4055 a possible workaround is here:
https://issues.apache.org/jira/browse/DERBY-4055?focusedCommentId=12680196&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12680196
Also synchronizing table access has helped some users.

You can verify if you are seeing DERBY-4055 by running with a SANE build and putting
derby.debug.true=DaemonTrace

in your derby.properties.

All that said, I have heard anecdotal reports that there may be another bug.  If you can come up with a reproduction that is not either of these issues, we would appreciate it.

Thanks

Kathey
--------------020803020200030004050405--