[ 
https://issues.apache.org/jira/browse/DERBY-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-6136:
---------------------------------

    Attachment: DataFileVTI.java

Attaching a new version of DataFileVTI which preserves triggering Throwables in 
the SQLWarnings passed back to the user.
                
> 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.0.0
>            Reporter: Rick Hillegas
>         Attachments: DataFileVTI.java, DataFileVTI.java, DataFileVTI.java, 
> DataFileVTI.java, DataFileVTI.java, dataFileVTI.sql, RawDBReader.java, 
> RawDBReader.java
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to