Bryan Pendleton commented on DERBY-6136:
I successfully used the new tool with the Derby 10.13.1.0 Release Candidate.
I used one of my regular Derby databases that I have lying around; this one
is an older database with several dozen user tables, originally created around
the 10.4 timeframe and then upgraded several times to (I think) 10.8.
In my first experiment, I simply used the tool to copy all the user tables out
of the existing database, which at the time was completely healthy and
operational. In this scenario, the tool worked fine and copied my user tables
to the new healthy database.
In my second experiment, I artificially damaged my database, by finding
and removing about a dozen system files which implemented the system
catalogs SYSROLES, SYSCOLPERMS, SYSDEPENDS, and SYSALIASES.
I picked these system files rather randomly, but the result of nuking these
files is that the databse became no longer bootable:
ERROR XSAI2: The conglomerate (336) requested does not exist.
Then, I once again made a new fresh healthy db, registered the tool against
my corrupt databse, and ran the recovery script.
Again, it loaded all of my user tables into my healthy DB.
These tests were performed on Windows 10, using the stock Java 8 JDK.
Although I'm sure we'll have occasion to revisit this tool in the future when it
gets used in other scenarios, I believe I've done enough testing to confirm
that the tool is viable in the Derby 10.13 release and is ready for non-Derby
developers to use it in real-world conditions.
> Create a custom/optional tool for dumping the data in a corrupted database.
> Key: DERBY-6136
> URL: https://issues.apache.org/jira/browse/DERBY-6136
> Project: Derby
> Issue Type: Improvement
> Components: Tools
> Affects Versions: 10.11.1.1
> Reporter: Rick Hillegas
> Assignee: Bryan Pendleton
> Fix For: 10.13.1.0
> Attachments: DataFileVTI.java, DataFileVTI.java, DataFileVTI.java,
> DataFileVTI.java, DataFileVTI.java, DerbyRecovery-0.0.1-SNAPSHOT.jar,
> RawDBReader.java, RawDBReader.java, RawDBReader.java, dataFileVTI.sql,
> derby-6136-01-aa-productize.diff, derby-6136-01-ab-teardownCorruptDB.diff,
> derby-6136-02-aa-cleanup.diff, log2.dat, log3.dat, log4.dat,
> log5.dat, log.ctrl, logmirror.ctrl
> It would be useful to have a tool for dumping the data in a corrupted
> database. This could start out as a custom tool. After we debug the tool and
> get some experience with it, we can consider promoting it to be a (possibly
> undocumented) optional tool which we ship with the product. I think the tool
> should have the following behavior:
> 1) The tool should not subvert the security of the corrupted database. If the
> corrupted database is password-protected, then you would need to present its
> DBO's credentials in order to use the tool. Naturally, an encryption key
> would have to be presented in order to decode an encrypted database.
> 2) The tool should not stop reading a table when it hits a corrupt record.
> Instead, the tool should soldier on and collect a list of warnings on bad
> Such a tool would be useful in situations where some part of a heap table is
> corrupt but the following heap conglomerates are intact:
> i) SYSSCHEMAS
> ii) SYSTABLES
> iii) SYSCONGLOMERATES
> iv) SYSCOLUMNS
> v) property conglomerate
> Such a tool would be useful for some situations where data can't be dumped
> even after you delete the log files in order to short-circuit recovery.
This message was sent by Atlassian JIRA