[
https://issues.apache.org/jira/browse/DERBY-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6136:
---------------------------------
Attachment: derby-6136-01-ab-teardownCorruptDB.diff
Thanks for that feedback and for kicking the tires, Bryan. Attaching
derby-6136-01-ab-teardownCorruptDB.diff. With this rev of the patch, the full
tests run cleanly.
A later test (DboPowersTest) was failing. This was because the SQL
authorization decorator does not remove its database. RawDBReaderTest creates a
test involving a lot of decorators: authentication, SQL authorization, and
encryption. DboPowersTest tried to re-use the database but couldn't because
DboPowersTest didn't know the boot password created by RawDBReaderTest. The fix
was to have RawDBReaderTest delete the database so that it couldn't be re-used.
There may be a more elegant way to accomplish this, say, by composing the
decorators in a different order and by adding a drop-database decorator. I
couldn't figure out how to do that, however. My solution was to do the
following:
1) Make RawDBReaderTest.tearDown() delete the database.
2) That wasn't enough, however. After the database was deleted, the
authentication decorator's tearDown() logic re-created the database in order to
reset properties. So I had to tell the authentication decorator not to do that.
Touches the same files as the previous rev.
> 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
> 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,
> log2[1].dat, log3[1].dat, log4[1].dat, log5[1].dat, log[1].ctrl,
> logmirror[1].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
> records.
> 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
(v6.3.4#6332)
