db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From José Arcángel Salazar Delgado (JIRA) <j...@apache.org>
Subject [jira] [Updated] (DERBY-6136) Create a custom/optional tool for dumping the data in a corrupted database.
Date Thu, 12 Mar 2015 10:44:38 GMT

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

José Arcángel Salazar Delgado updated DERBY-6136:
    Attachment: DerbyRecovery-0.0.1-SNAPSHOT.jar

I create DerbyRecovery-0.0.1-SNAPSHOT.jar file to simplify the process.

1.-Download lastest derby bin.
2.- Add DerbyRecovery-0.0.1-SNAPSHOT.jar to the ij classpath
3.- Run dataFileVTI.sql (remember to change the route to the database in the connect string)
3.- enter ij and connect to the database using upgrade=true
4.- use call SYSCS_UTIL.SYSCS_REGISTER_TOOL('customTool',true,'RawDBReader', 'CONTROL','RAW_','c:\db','','APP',null);
-> change the db route, password, bootpassword and schema
5.- check with select * from raw_app.table1;

> 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:
>            Reporter: Rick Hillegas
>         Attachments: DataFileVTI.java, DataFileVTI.java, DataFileVTI.java, DataFileVTI.java,
DataFileVTI.java, DerbyRecovery-0.0.1-SNAPSHOT.jar, RawDBReader.java, RawDBReader.java, dataFileVTI.sql
> 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:
> 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

View raw message