[
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
DataFileVTI.java
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 the contents of SYSSCHEMAS, SYSTABLES,
SYSCONGLOMERATES, and SYSCOLUMNS. There is more work 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 arguments:
create view sysschemas
as select * from table
(
sysschemas
(
'/Users/rh161140/derby/mainline/db1',
'cc0.dat',
'( schemaID char(36), schemaname varchar(128), authorizationid
varchar(128) )',
null,
'APP',
null
)
) 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:
a) NATIVE
b) BUILTIN
c) LDAP
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: 10.11.0.0
> 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:
> 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
