[
https://issues.apache.org/jira/browse/DERBY-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6136:
---------------------------------
Attachment: derby-6136-01-aa-productize.diff
Attaching derby-6136-01-aa-productize.diff. This patch converts RawDBReader
from a custom tool into a full-fledged optional tool which is bundled in
derbyoptionaltools.jar. I am running tests now.
The rawDBReader optional tool has the following signature:
call syscs_util.syscs_register_tool
(
'rawDBReader',
true,
'$pathToRecoveryScript',
'$controlSchema',
'$shadowSchemaPrefix',
'$pathToCorruptDatabase',
'$encryptionAttributes',
'$ownerOfCorruptDatabase',
'$ownerPassword'
);
where
1) The recovery script will be written to $pathToRecoveryScript
2) The $controlSchema is where the tool creates views on the core catalogs of
the corrupt database.
3) The $shadowSchemaPrefix is a string which is prefixed to the names of all
the user schemas observed in the corrupt database. Views on the corrupt tables
are created in the good database to which the data will exported. These views
are created in shadow schemas in the good database.
4) $pathToCorruptDatabase is the location of the corrupt database.
5) $encryptionAttributes is the list of encryption attributes needed to connect
to the corrupt database.
6) $ownerOfCorruptDatabase is the DBO of the corrupt database.
7) $ownerPassword is the DBO's password.
For instance,
{noformat}
call syscs_util.syscs_register_tool
(
'rawDBReader',
true,
'/Users/rhillegas/sql/zrecovery.sql',
'CONTROL11',
'RAW11_',
'tmpdbs/db0',
'bootPassword=fooBarWibble',
'TEST_DBO',
'TEST_DBORRT'
);
{noformat}
Follow-on work will include user documentation and some cleanup of these
classes.
Touches the following files:
--------------
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/insane.derbyoptionaltools.jar.lastcontents
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/sane.derbyTesting.jar.lastcontents
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/insane.derbyTesting.jar.lastcontents
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/sane.derbyoptionaltools.jar.lastcontents
Build machinery.
--------------
M java/engine/org/apache/derby/impl/sql/compile/StaticMethodCallNode.java
M java/engine/org/apache/derby/catalog/Java5SystemProcedures.java
A java/optional/org/apache/derby/optional/dump
A java/optional/org/apache/derby/optional/dump/RawDBReader.java
A java/optional/org/apache/derby/optional/dump/DataFileVTI.java
The new rawDBReader optional tool.
--------------
A
java/testing/org/apache/derbyTesting/functionTests/tests/lang/RawDBReaderTest.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java
Tests.
> 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)
