Kathey Marsden <[email protected]> writes: > On 3/14/2011 11:33 AM, Phil Bradley wrote: >> Hi, >> >> I have a Java application using derby 10.4 in embedded mode which has >> been in production for approximately 1 year. About 2 months ago, I added >> a function to run SYSCS_COMPRESS_ TABLE on a nightly basis (this may or >> may not be related to the issue below). A few days ago, the client >> reported the following error on application startup: >> >> ERROR XSAI2: The conglomerate (180,512) requested does not exist. >> >> I now have a copy of the database and when I connect via ij, I receive >> the same error (completely reproducibly). I am attaching this output for >> reference. Note that the application uses derby 10.4 while I used the >> 10.5 libraries to make the connection; the observed behaviour is the >> same however. >> >> As regards the production issue, the client simply removed (copied >> actually) the problematic database and reinitialised the application so >> my goal is to understand (if possible) the cause of this and to identify >> possible work arounds. Is there anything I can do that might help >> resolve why this error is occurring? Is there additional logging that I >> can enable that might give more visibility on what is actually >> happening? >> > There was a coruption issue that is now fixed: > https://issues.apache.org/jira/browse/DERBY-4239 > SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE is called during checkpoint
We also have a report about conglomerate does not exist errors after SYSCS_COMPRESS_TABLE: https://issues.apache.org/jira/browse/DERBY-4275 But that issue went away after rebooting the database (presumably because of stale query plans in the statement cache), so it's probably not the same bug. > I am not sure if this affects SYSCS_COMPRESS_TABLE or not. Perhaps > Mike could speak to that. -- Knut Anders
