Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sat, 18 Feb 2006 00:45:35 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Derby db files get corrupted
In-reply-to: <loom.20060217T233247-404@post.gmane.org>
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <878xs9sg68.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
References: <20060216074417.714D3D54E4@poczta.interia.pl>
 <wjo8irrfbrew.fsf@sun.com> <loom.20060217T233247-404@post.gmane.org>

Maciek <wegorkie@interia.pl> writes:

> Knut Anders Hatlen <Knut.Hatlen@...> writes:
>
>> I have seen this error when I have deleted the database directory and
>> recreated the database, but not deleted the log directory. Could that
>> be your problem too?
>
> Well, deleting log files helped. DB is working and the user claims no data is
> lost. Maybe adding a "repair tool" to my app that deletes log files could solve
> future problems of this.

I have been trying to reproduce this problem with no luck. Then I
moved from the development trunk to the 10.1.1.0 release, and I was
immediately able to reproduce the error by doing this:

  1) Create a database with logDevice set to /tmp/log
  2) Run some transactions so that a couple of log files are generated
  3) Kill Derby
  4) Delete database directory
  5) Re-create database with logDevice set to /tmp/log
  6) Run some transactions so that some, but not all of the log files
     are overwritten.
  7) Kill Derby
  8) Restart Derby

During the recovery in 8) I got this error message:

  ERROR XSDB4: Page Page(0,Container(0, 768)) is at version 2,657, the
  log file contains change version 2,715, either there are log records
  of this page missing, or this page did not get written out to disk
  properly.

Since I don't get this error with the development trunk (and I have
really tried hard!), it seems like the problem has been fixed. I was
also able to reproduce the error using the 10.1.2.1 release.

Maybe someone knows when this was fixed and can advise how to port the
fix to the release you are running?

-- 
Knut Anders