db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: SYSCS_UTIL.SYSCS_COMPRESS_TABLE
Date Mon, 01 Dec 2008 16:02:35 GMT
Maybe you could speed up the compression by playing with some of the 
Store parameters, but I'm skeptical. You will probably have to rely on 
mechanisms outside Derby.

Regards,
-Rick

Wei Jiang wrote:
> Thank you for your reply.
>
> Is there anything I can do to make Derby a always-available-database if the compress
process takes noticeable time?  
>
>
> --- On Thu, 11/27/08, Knut Anders Hatlen <Knut.Hatlen@Sun.COM> wrote:
>
>   
>> From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
>> Subject: Re: SYSCS_UTIL.SYSCS_COMPRESS_TABLE
>> To: derby-dev@db.apache.org
>> Cc: _weijiang_@yahoo.com
>> Date: Thursday, November 27, 2008, 4:54 AM
>> Wei Jiang <_weijiang_@yahoo.com> writes:
>>
>>     
>>> Hi,
>>>
>>> Can I use SYSCS_UTIL.SYSCS_COMPRESS_TABLE and
>>> SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE when the
>>>       
>> database is working
>>     
>>> with insert/delete/update?
>>>       
>> Yes, that's supposed to work. SYSCS_COMPRESS_TABLE will
>> obtain an
>> exclusive lock on the table, which means that it will wait
>> until all
>> transactions that are currently accessing the table have
>> released their
>> locks, and it will block new transactions from accessing
>> the table until
>> it has completed the compress operation.
>>
>> -- 
>> Knut Anders
>>     
>
>
>       
>   


Mime
View raw message