Subject | Re: [firebird-support] Dealing with DB corruption |
---|---|
Author | Ann W. Harrison |
Post date | 2008-07-23T18:28:22Z |
fusion35 wrote:
capabilities that the new-fangled stuff doesn't have. (We
had an electric car (circa 1908) in our town parade this year.
Maybe in a few years we'll see the next generation of electric
cars... Without tiller-steering I hope - and after that, a
modern query language that does cross database operations).
Anyway. If you've got a table that's not listed in
RDB$RELATIONS, you've got a problem. One thing to check
is whether there is an entry in RDB$PAGES for a table that
doesn't exist in RDB$RELATIONS. Something like
select P.RDB$RELATION_ID from RDB$PAGES P
where not exists
(select 1 from RDB$RELATIONS R
where R.RDB$RELATION_ID = P.RDB$$RELATION_ID)
If you find anything, those may be the pointer pages for the
table you're looking for and the data may still exist. If so,
look in RDB$FORMATS for any rows with that RDB$RELATION_ID.
If there is only one format, you could try (no guarantees)
creating another table exactly identical to the one you lost,
and then changing the RDB$RELATION_ID to the value you found
from the RDB$PAGES query.
Depending on how anal the InterBase guys have gotten over
protecting metadata, that might work. Did I mention before
that you should do all this on a spare copy of the database?
If all this sounds pretty hairy, you might contact ibphoenix
which has tools for extracting mostly missing data from mostly
dead databases. Paul Beach - pbeach@.... Even
without the pointer pages, they can find data pages and glue
them back to a new table definition. Unless the pages have
been released and reused, which is, unfortunately, quite
likely.
Cheers,
Ann
>That's likely. QLI is a real antique - though it has some
> I have a corrupted DB (one of the table has gone missing) very similar
> to the situation described at :
>
> I am using IB7.5 and can not find QLI.exe in my bin folder.
capabilities that the new-fangled stuff doesn't have. (We
had an electric car (circa 1908) in our town parade this year.
Maybe in a few years we'll see the next generation of electric
cars... Without tiller-steering I hope - and after that, a
modern query language that does cross database operations).
Anyway. If you've got a table that's not listed in
RDB$RELATIONS, you've got a problem. One thing to check
is whether there is an entry in RDB$PAGES for a table that
doesn't exist in RDB$RELATIONS. Something like
select P.RDB$RELATION_ID from RDB$PAGES P
where not exists
(select 1 from RDB$RELATIONS R
where R.RDB$RELATION_ID = P.RDB$$RELATION_ID)
If you find anything, those may be the pointer pages for the
table you're looking for and the data may still exist. If so,
look in RDB$FORMATS for any rows with that RDB$RELATION_ID.
If there is only one format, you could try (no guarantees)
creating another table exactly identical to the one you lost,
and then changing the RDB$RELATION_ID to the value you found
from the RDB$PAGES query.
Depending on how anal the InterBase guys have gotten over
protecting metadata, that might work. Did I mention before
that you should do all this on a spare copy of the database?
If all this sounds pretty hairy, you might contact ibphoenix
which has tools for extracting mostly missing data from mostly
dead databases. Paul Beach - pbeach@.... Even
without the pointer pages, they can find data pages and glue
them back to a new table definition. Unless the pages have
been released and reused, which is, unfortunately, quite
likely.
Cheers,
Ann