db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: SYSCS_UTIL.SYSCS_COMPRESS_TABLE
Date Mon, 01 Dec 2008 16:02:50 GMT
Wei Jiang <_weijiang_@yahoo.com> writes:

> 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?

Not as far as I know. Feel free to log an improvement request at
https://issues.apache.org/jira/browse/DERBY to allow more concurrent
activity while compressing a table.

One thing that may help a little, is to split the compress
operation. That is, when you run a full in-place compress like this

  CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('S','T',1,1,1)

you could instead do it in two phases like this

  CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('S','T',1,0,0)
  CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('S','T',0,1,1)

If you commit between the two calls to SYSCS_INPLACE_COMPRESS_TABLE, the
exclusive table lock will be released after the purging of the committed
deleted rows, so that you allow the transactions that were blocked by
the table lock to continue before the second call (which performs
defragmentation and truncation) can reobtain the exclusive table
lock. This might reduce the maximum wait times seen by the other
threads.

-- 
Knut Anders

Mime
View raw message