Wei Jiang <[EMAIL PROTECTED]> 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
