db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: PLEASE REVIEW: New release notes and changes generated for 10.3.3
Date Fri, 02 May 2008 23:05:57 GMT
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:

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.
Recovering data in this manner depends on the database being able to
boot, some instances of this corruption are uncovered during recovery
boot and in that case the situation is even harder to recover from.

This corruption affects one file at a time in derby, though may affect
multiple files in a single database.  Tools exist to check the 
consistency of all files in the database.  Derby stores each index and base
table data in a single file so if only one file is corrupted other files
may be accessible.

Examples of ways one may try to salvage data from a corrupted database
include:
o dropping and recreating an existing index (but it may take software 
hacking to get the drop of the index to work depending on the type of 
corruption).
o dropping only the affected tables.
o By hand exporting data from affected tables and importing into a fresh
db created with software that has the fix.

Those that have lost critical data to this corruption and don't have a
backup should consult the experts on the list for ideas.


Andrew McIntyre wrote:
> On Thu, May 1, 2008 at 1:14 AM, Andrew McIntyre <mcintyre.a@gmail.com> wrote:
>>  I made a pass at making a real RELEASE-NOTES.html and CHANGES.html for
>>  10.3.3.0 based on the latest code and JIRA results. The output is
>>  here:
>>
>>  http://people.apache.org/~fuzzylogic/10.3.3.0/RELEASE-NOTES.html
>>  http://people.apache.org/~fuzzylogic/10.3.3.0/CHANGES.html
>>
>>  Please let me know if you have any additions, clarifications, or
>>  changes to make.
> 
> Replying to my own mail because I want to bring up something I hope to
> get comments on a wording issue.
> 
> The important notice, originally authored by Stan and updated by me,
> includes the following wording:
> 
> "If corruption has already occurred the database will need to be recovered
> from the last good backup. There is no alternative solution."
> 
> I wondering if I should soften this. On the one hand, if the
> corruption has occurred and it's just in an index, the user can just
> upgrade, drop and recreate the index, and they are good. In other
> words, maybe this is going a bit too far, as the user should be able
> to salvage some of their data if they've hit this problem.
> 
> On the other hand, I think this is a sufficiently alarming statement
> that it will encourage users to upgrade to the new release as soon as
> possible.
> 
> If there are no alternative suggestions, I will leave the text as is.
> 
> thanks,
> andrew
> 


Mime
View raw message