Corrupted database - missing system files

[David Sitsky <da...@gmail.com>]

Hi all,

I have a customer who somehow is in a situation where a number of
their Derby files are missing.  When booting up, the first message
that came was:

ERROR XSAI2: The conglomerate (192) requested does not exist.

I know this corresponds to the file cc0.dat (since 192 == 0xc0).  Out
of desperation, I tried to copy this file from another database, just
to see if this would help, realising this is probably not a good idea.
 I then had to add cd1.dat and then the database would boot up.
However running any commands generating similar messages of missing
conglomerates.

It turned out there are plenty of files missing, including:

c90.dat
ca1.dat
c81.dat
ce1.dat
cb1.dat
cf0.dat

After adding these in, I get assertion failures when trying to run
some queries, which is perhaps not surprising.

Seemingly, it seems all the "user" conglomerates are present, looking
at the list of filenames present.

Is there any way I can get this database into a useable state?  I
suspect being confidential data, I may not be allowed to put this
anywhere public.  I appreciate any advice people can provide.

Cheers,
David

Re: Corrupted database - missing system files

[David Sitsky <da...@gmail.com>]

Hi Bryan,

> Even the smallest differences in the two schemas would cause internal
> assertions to fire, but with some effort you could probably diagnose
> where the schema mismatch was, from the information in the assertion,
> and from your knowledge about the expected schema.
>
> But it's going to be a lot of work, sorry.

No worries.. appreciate the response.

Cheers,
David

Re: Corrupted database - missing system files

[Bryan Pendleton <bp...@gmail.com>]

> After adding these in, I get assertion failures when trying to run
> some queries, which is perhaps not surprising.
>
> Seemingly, it seems all the "user" conglomerates are present, looking
> at the list of filenames present.
>
> Is there any way I can get this database into a useable state?

I can't think of any straightforward way.

It seems like, if you could create an empty database with an *identical*
schema, you might stand some chance of copying the user conglomerates
from the damaged database to the empty database and running SELECT
commands to extract the data.

Even the smallest differences in the two schemas would cause internal
assertions to fire, but with some effort you could probably diagnose
where the schema mismatch was, from the information in the assertion,
and from your knowledge about the expected schema.

But it's going to be a lot of work, sorry.

bryan