[ https://issues.apache.org/jira/browse/DERBY-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021410#comment-15021410 ]
Bryan Pendleton commented on DERBY-6136: ---------------------------------------- FWIW, the "productize" patch built cleanly on my system, and the new RawDBReader test passed when I ran it. This seems like a useful tool to have in the distribution; thanks for taking the time to keep pushing it forward. > 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, 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)