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. Sometimes people mistake the transaction log for the error log
and start deleting stuff under there or follow really bad, wrong and
horrible instructions to do so and corrupt their database that way. If
you look at the log directory the logx.dat files should be in order with
no gaps and generally should not start with 1 if this system has been
running for a while. If a table or index was created and then the jvm
exits without recovering the log because of manual manipulation,
obviously the conglomerate will be missing. 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. This will eliminate
the need for recovery on each boot and perhaps make startup a bit
faster. Of course recovery will be needed in the event of a crash and
will be performed normally in that case. If you think the database
looks clean and untampered, repost and I can suggest a few more steps.
Kathey
