On Tue, 15 Mar 2011 06:04 -0700, "Kathey Marsden"
<[email protected]> wrote:
> On 3/15/2011 4:40 AM, Phil Bradley wrote:
> >
> > 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).
> >
> I think the first thing to do is to take a look at the ls -lR output of
> the corrupt database, preferably with original timestamps intact, to
> make sure the transaction logs were not accidentally or intentionally
> deleted.
Hi Kathey,
The log folder contains the following files:
1048576 Mar 15 12:38 log913.dat
48 Mar 14 18:17 logmirror.ctrl
48 Mar 14 18:17 log.ctrl
1048576 Mar 10 11:47 log915.dat
1048756 Mar 10 04:02 log914.dat
If I've understood your previous email, I think this is fine in that the
files are sequential so there's no indication that someone has deleted
one of the logs (although no guarantee that they haven't:)
> You can think about your
> application and when it creates tables and indexes to consider if this
> is how it might have gone missing. One good way to help protect the
> database from users if you suspect this to be the problem is to have
> your application do an orderly shutdown on exit.
Tables and indexes are created on application startup but only if they
don't already exist in the local database (so whenever an upgrade
results in a schema change which hasn't happened in a while). I don't
think this is what happened in this case but I'll put the clean shutdown
into the next release anyway, I imagine it will only help:)
Regarding the version, thanks for your advice on this. Our internal
decision on this was that we would definitely be upgrading to 10.8 when
it gets released due to DERBY-4741 (interrupt handling) being addressed.
On this basis, we decided to defer upgrading to 10.7.
Regarding further investigation, this application has been running for a
year on approx 200 systems and this is the first time we have seen this
error. We can't reproduce the conditions that led to the database
getting into this state and it's not causing a major problem at the
client site so it doesn't present an urgent problem to us. Having said
that, if you think there's a possibility that further investigation
might help identify a problem in Derby, I'll be happy to continue with
this.
Thanks and regards,
Phil
