[
https://issues.apache.org/jira/browse/DERBY-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6136:
---------------------------------
Attachment: RawDBReader.java
Attaching a new version of RawDBReader.java. This version writes out a recovery
script as it creates the table functions and views needed to read the corrupt
database. The recovery script recreates all of the user schemas and tables in
the new database and siphons the data out of the corrupt tables into the new
tables. The recovery script includes comments which help an administrator
identify which seg0 files correspond to which tables.
So, for instance, if the corrupt database has this schema:
{noformat}
schema1.t1
schema1.t2
schema2.t1
schema2.t2
{noformat}
...then running the following statements...
{noformat}
connect 'jdbc:derby:tmpdbs/db1;create=true';
call syscs_util.syscs_register_tool
(
'customTool',
true,
'RawDBReader',
'CONTROL11',
'RAW11_',
'tmpdbs/db0',
null,
'APP',
null
);
{noformat}
...would create a file named recovery.sql in the current directory with the
following contents...
{noformat}
connect 'jdbc:derby:tmpdbs/db1';
create schema "SCHEMA1";
-- siphon data out of c490.dat
create table "SCHEMA1"."T1" as select * from "RAW11_SCHEMA1"."T1" with no data;
insert into "SCHEMA1"."T1" select * from "RAW11_SCHEMA1"."T1";
create schema "SCHEMA2";
-- siphon data out of c4a0.dat
create table "SCHEMA1"."T2" as select * from "RAW11_SCHEMA1"."T2" with no data;
insert into "SCHEMA1"."T2" select * from "RAW11_SCHEMA1"."T2";
-- siphon data out of c4b0.dat
create table "SCHEMA2"."T1" as select * from "RAW11_SCHEMA2"."T1" with no data;
insert into "SCHEMA2"."T1" select * from "RAW11_SCHEMA2"."T1";
-- siphon data out of c4c0.dat
create table "SCHEMA2"."T2" as select * from "RAW11_SCHEMA2"."T2" with no data;
insert into "SCHEMA2"."T2" select * from "RAW11_SCHEMA2"."T2";
{noformat}
> 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,
> 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)
