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 <[EMAIL PROTECTED]> 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
