On 3/16/2011 4:07 AM, Phil Bradley wrote:
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
The one thing that looks strange to me there is that log913 is dated
after log914 and log915 and that the dates on the ctrl files don't match
with the last log file log915.dat. I am not quite sure how this could
happen in normal operations. What is the latest timestamp on the files
in the seg0 directory? This should tell us when the last checkpoint
occurred.
I was wondering, do you expect your application to be creating and
dropping tables or indexes as part of normal operation or should they
have been created up front? If it is the latter and you have a good
recent backup, then we could try to identify the conglomerate in question.
The next thing you can do to make sure that the log records make sense
and also to determine if compress might be involved is use a *sane*
build andstart ij with the properties:
derby.debug.true=DumpLogOnly,LogTrace
Start with the database as you got it from the site if you have it, as
just attempting to boot it can change things.
What will happen is that in the derby.log you will see a text
representation of the full set of log entries.
The database will not actually try to boot so you will see a different
error with your connect command
Helping you analyze the trace, particularly if you can't share it,
might be difficult, but if you have any specific questions, let's move
this conversation over to the derby-dev list as that seems a better
place for it. I have long had on my list to set up a wiki page for
analyzing corrupt databases, but haven't done it yet. Maybe this will
inspire me to finally do it.
Kathey
