db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Taylor <paul_t...@fastmail.fm>
Subject Re: Reclaiming space from Derby
Date Thu, 09 Sep 2010 14:20:14 GMT
Knut Anders Hatlen wrote:
> Paul Taylor <paul_t100@fastmail.fm> writes:
>
>   
>> Knut Anders Hatlen wrote:
>>     
>>> Paul Taylor <paul_t100@fastmail.fm> writes:
>>>
>>>   
>>>       
>>>> HI, I use derby in embedded mode, I let the user specify a maxmium
>>>> size for the derby database files, my program monitors this and if it
>>>> goes over the size I use SQL to delete records that are no longer
>>>> necessary in the hope of shrinking the database files size, but it
>>>> doesn't, how can I force Derby to shrink back down ?
>>>>     
>>>>         
>>> Hi Paul,
>>>
>>> The database files won't shrink unless you compress the tables.
>>>
>>> http://db.apache.org/derby/docs/10.6/ref/rrefaltertablecompress.html
>>> http://db.apache.org/derby/docs/10.6/ref/rrefproceduresinplacecompress.html
>>>
>>> Hope this helps,
>>>
>>>   
>>>       
>> Thanks guys that does help, the only problem is that it takes an
>> exclusive lock on the table and I wanted to run it in the background
>> as and when required when other tasks might be going ahead. But can
>> probaly work round this.
>>     
>
> In the issue tracker there's a request for allowing more concurrent
> activity while compressing a table, but there hasn't been any work on it
> yet. https://issues.apache.org/jira/browse/DERBY-3974
>
>   
I dont quote get the difference between the two procedures, one makes 
adjustments in place, the other doesnt, but they both exclusively lock  
the table so what is the advantage of one over the other ?


Paul

Mime
View raw message