On Tue, 15 Mar 2011 10:43 +0100, "Knut Anders Hatlen" <[email protected]> wrote: > 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 >
Hi Kathey, Knut, Thanks for your feedback. I had seen bug 4275 but discounted it on the basis that the problem occurs even after shutting down the database. Apart from the stack trace, is there something else I can do that will help to diagnose this? Unfortunately, I can't send you the database as this would raise data protection issues but if there are any steps that I can take that will help to diagnose this I'll be happy to submit the results (I think this is too vague at the moment to raise a bug but if I can narrow it down, I'll be happy to do this). Regards, Phil
