Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=gCwymOHI0mxQzGXOAGxgkz6zblMfMCXtmuqLi0Os3tC+dIMYPpzXc+4Iq46/Tj29bsmxsW7EGQwpnXD5E10O0+7PK7o6AVg1D69RM9cAkdm+rlFqXgm+SEUk17Vrl2E23Dk5pVtuJd3nsTemHLrNixdTVXGxSpeHxWhFMINsAkQ=;
Message-ID: <248507.5047.qm@web58505.mail.re3.yahoo.com>
References: <97687.71494.qm@web58507.mail.re3.yahoo.com>
 <71a64ba60909231831j4c594066vba74608f93bd4511@mail.gmail.com>
 <512348.6994.qm@web58508.mail.re3.yahoo.com>
 <71a64ba60909231839t39ab3163r8774c744fb1fcfa1@mail.gmail.com>
 <664145.32658.qm@web58504.mail.re3.yahoo.com>
 <65702.59040.qm@web58502.mail.re3.yahoo.com> <wjo863b8u5zf.fsf@sun.com>
 <980604.21709.qm@web58506.mail.re3.yahoo.com>
Date: Thu, 24 Sep 2009 12:51:34 -0700 (PDT)
From: T K <sanokistoka@yahoo.com>
Subject: Re: Horrible performance - how can I reclaim table space?
To: Derby Discussion <derby-user@db.apache.org>
In-Reply-To: <980604.21709.qm@web58506.mail.re3.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1830855086-1253821895=:5047"

--0-1830855086-1253821895=:5047
Content-Type: text/plain; charset=us-ascii

The space was reclaimed by the stored proc when the database was "quiet" as I describe it below - that's my definition of true offline mode. This makes me suspect that, before, the stored proc may have tried to X-lock the table a couple of times and may have failed and given up while the database was heavily utilized, but this is just a theory.

However, the most significant issue at the moment related to unreclaimed space seems to be bugs http://issues.apache.org/jira/browse/DERBY-4054 and http://issues.apache.org/jira/browse/DERBY-4055 which have yet to be resolved.


________________________________
From: T K <sanokistoka@yahoo.com>
To: Derby Discussion <derby-user@db.apache.org>
Sent: Thursday, September 24, 2009 8:14:56 AM
Subject: Re: Horrible performance - how can I reclaim table space?


Yes that's the one I am calling and the space is not reclaimed.


________________________________
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
To: Derby Discussion <derby-user@db.apache.org>
Sent: Thursday, September 24, 2009 4:00:52 AM
Subject: Re: Horrible performance - how can I reclaim table space?

T K <sanokistoka@yahoo.com> writes:

> BTW, I have to ask this question: how exactly do we define OFFLINE
> compression? I assume I still bring the database up and call the compression
> stored proc from ij, but no one else connects, correct?

When people talk about offline compression, I think they mean the
SYSCS_UTIL.SYSCS_COMPRESS_TABLE routine, as opposed to
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE. Probably, the use of
online/offline when talking about compression is due to confusion with
the backup terminology.

-- 
Knut Anders


--0-1830855086-1253821895=:5047
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:bookman old style,new york,times,serif;font-size:12pt"><div>The space was reclaimed by the stored proc when the database was "quiet" as I describe it below - that's my definition of true offline mode. This makes me suspect that, before, the stored proc may have tried to X-lock the table a couple of times and may have failed and given up while the database was heavily utilized, but this is just a theory.<br><br>However, the most significant issue at the moment related to unreclaimed space seems to be bugs <a href="http://issues.apache.org/jira/browse/DERBY-4054">http://issues.apache.org/jira/browse/DERBY-4054</a> and <a href="http://issues.apache.org/jira/browse/DERBY-4055">http://issues.apache.org/jira/browse/DERBY-4055</a> which have yet to be resolved.<br></div><div style="font-family: bookman old style,new york,times,serif; font-size:
 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> T K &lt;sanokistoka@yahoo.com&gt;<br><b><span style="font-weight: bold;">To:</span></b> Derby Discussion &lt;derby-user@db.apache.org&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Thursday, September 24, 2009 8:14:56 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: Horrible performance - how can I reclaim table space?<br></font><br>
<meta http-equiv="x-dns-prefetch-control" content="off"><div style="font-family: bookman old style,new york,times,serif; font-size: 12pt;"><div>Yes that's the one I am calling and the space is not reclaimed.<br></div><div style="font-family: bookman old style,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Knut Anders Hatlen &lt;Knut.Hatlen@Sun.COM&gt;<br><b><span style="font-weight: bold;">To:</span></b> Derby Discussion &lt;derby-user@db.apache.org&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Thursday, September 24, 2009 4:00:52 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: Horrible performance - how can I reclaim table space?<br></font><br>
T K &lt;<a rel="nofollow" ymailto="mailto:sanokistoka@yahoo.com" target="_blank" href="mailto:sanokistoka@yahoo.com">sanokistoka@yahoo.com</a>&gt; writes:<br><br>&gt; BTW, I have to ask this question: how exactly do we define OFFLINE<br>&gt; compression? I assume I still bring the database up and call the compression<br>&gt; stored proc from ij, but no one else connects, correct?<br><br>When people talk about offline compression, I think they mean the<br>SYSCS_UTIL.SYSCS_COMPRESS_TABLE routine, as opposed to<br>SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE. Probably, the use of<br>online/offline when talking about compression is due to confusion with<br>the backup terminology.<br><br>-- <br>Knut Anders<br></div></div></div><br>

      <meta http-equiv="x-dns-prefetch-control" content="on"></div></div></div><br>

      </body></html>
--0-1830855086-1253821895=:5047--