db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: PLEASE REVIEW: New release notes and changes generated for 10.3.3
Date Sat, 03 May 2008 00:29:14 GMT
On Fri, May 2, 2008 at 4:05 PM, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
> I have the same concerns, we really don't want to undersell how hard it may
> be to get your data back.  How about something like:
>
>  <snip suggestion/>

Hi Mike,

Thanks for the suggestion, I've incorporated part of it. I want to
keep it brief, so I think we should ask users to post to derby-user if
they find they have been affected by this issue for advice specific to
their situation. Here's my proposed updated announcement:

-----

NOTICE TO ALL DERBY v10.3 USERS : CRITICAL FIX NOW AVAILABLE

 The Bottom Line:

 If you are currently using Derby 10.3.1.4 or Derby 10.3.2.1, it is strongly
 recommended that you upgrade to Derby 10.4.1.3 or 10.3.3.0 to avoid
 any chance of database corruption due to an issue with multiple threads
 accessing a database that is documented in <a
href="issues.apache.org/jira/browse/DERBY-3347">DERBY-3347</a>.

 This bug can cause unrecoverable database corruption during periods of
 heavy, multi-thread I/O operations.  The error produced in the test case
 used to diagnose the problem was:

 ERROR XSDB3: Container information cannot change once written: was 0, now 80

 It is felt that other errors might also be generated when this type of
 corruption occurs.  The corruption message will most likely refer to page 0
 of the container. For example:

 ERROR XSDG1: Page Page(0 ,Container(0, 5856)) could not be
 written...

 This bug corrupts the pages on disk and can go unnoticed.  If you do not
 run database consistency checks regularly it is recommended you begin doing
 so as soon as possible after the upgrade.  To insure that corruption has not
 already occurred in existing databases, after upgrade run the database
 consistency check at least once to validate all tables in the database.  This
 process is documented at:

 http://wiki.apache.org/db-derby/DatabaseConsistencyCheck

If the corruption has already occurred there is no guaranteed recovery of data
other than to recover from the last good backup.  When doing so one should
also check that the previous backup did not also have the corruption.

In some cases one may recover data from the existing
database, depending on the extent of the corruption, but will require
by hand data recovery.  Depending on the type of corruption this may
be successful or not. one should consult the Derby list if attempting
this recovery - no automatic software solution to this recovery exists.

 Version 10.3.3.0 can be downloaded from:
 http://db.apache.org/derby/releases/release-10.3.3.0.cgi

 Version 10.4.1.3 can be downloaded from:
 http://db.apache.org/derby/releases/release-10.4.1.3.cgi

For help or questions, please post to derby-user@db.apache.org.

For instructions on how to subscribe to derby-user, please see:

http://db.apache.org/derby/derby_mail.html

----

I'll begin building the release shortly, and will include this version
of the announcement in the release notes.

andrew

Mime
View raw message