db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6136) Create a custom/optional tool for dumping the data in a corrupted database.
Date Mon, 01 Apr 2013 19:29:15 GMT

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

Rick Hillegas updated DERBY-6136:

    Attachment: dataFileVTI.sql

Attaching the first rev of DataFileVTI, a table function which reads a heap conglomerate.
Also attaching dataFileVTI.sql, a script which shows how to use this table function to read
to be done on this table function, but I think that it's worth getting community feedback
on this early version.

The table function takes the following arguments:

    databaseDirectoryName varchar( 32672 ),
    heapConglomerateFileName varchar( 32672 ),
    tableSignature varchar( 32672 ),
    bootpassword varchar( 32672 ),
    dboName varchar( 32672 ),
    dboPassword varchar( 32672 )

...and requires that you declare the shape of the rows in the target heap. Here, for instance,
is how you would declare a table function to read SYS.SYSSCHEMAS in a corrupt database:

create function sysschemas
    databaseDirectoryName varchar( 32672 ),
    dataFileName varchar( 32672 ),
    tableSignature varchar( 32672 ),
    bootpassword varchar( 32672 ),
    userName varchar( 32672 ),
    password varchar( 32672 )
returns table
( schemaID char(36), schemaname varchar(128), authorizationid varchar(128) )
language java
parameter style derby_jdbc_result_set
no sql
external name 'DataFileVTI.dataFileVTI';

Typically, I think that you would wrap the table function in a view in order to hide the messy

create view sysschemas
as select * from table
        '( schemaID char(36), schemaname varchar(128), authorizationid varchar(128) )',
)  t;

Then you would dump the data in the heap by selecting from the view:

select * from sysschemas;

You will get an error if the credentials or bootpassword are invalid or if the user name is
not the name of the owner of the corrupt database. I have tested this logic when the following
authentication schemes are specified by database-only properties in the corrupt database:

d) custom

I am aware of the following defects:

I) The tool will probably fail to run against really old databases which use BUILTIN authentication
or password substitution.

II) The tool will fail to read rows which spill across multiple heap pages.

III) I have not stressed the unencryption argument yet. The logic is merely based on what's
done in the DataFileReader program attached to DERBY-5201. I'm sure it doesn't handle the
difference between bootpasswords and encryption keys.

> 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.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 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

View raw message