db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject Re: SYSCS_UTIL.SYSCS_CHECK_TABLE
Date Wed, 02 Dec 2015 03:29:16 GMT
> Is it possible to manipulate the base tables and/or the btree indexes in a way to cause
inconsistencies

It's hard to do this reliably, or easily.

But I encourage you to try, it sounds like a good project,
and a good way to explore Derby internals and improve your
knowledge of Derby.

Here's a possible idea: take part, but not all, of your Derby
database "back in time".

A base table and its indexes are each stored in separate physical
files, which Derby calls "conglomerates".

So if you define a table with a number of secondary indexes,
and then insert some rows into that table, Derby will populate
the table and its indexes.

Then, shut down Derby cleanly and make a copy of the entire
database folder.

Then, start Derby back up and add some more rows into that
table.

Then, shut down Derby cleanly again.

Then, try (using yet another copy of the Derby database folder)
copying some of the table's index conglomerates from your first
backup copy into your master copy.

This will cause the base table rows to be "missing" some
index entries because you have essentially "rolled back" the
index conglomerates to an earlier time, causing them to be missing
the index entries that were created by your second batch of
insert statements.

Then see how the consistency-checking tools behave on that
artifically-damaged database.

Similar experiments are possible using other types of
integrity constraints (unique constraints, foreign key
constraints, etc), and using other types of "back-in-time"
intentional damage, such as rolling an index back to before
an update of an indexed column, or rolling an index back to
before a delete of a row, or rolling back one table but
not other table, when the tables have a referential
integrity constraint.

These are the sorts of consistency violations that a consistency-checking
tool is intended to catch, so it would be good to know if you
are able to provoke such types of damage and then observe
the tools helping you to diagnose the problem.

Regarding internal sorts of Btree integrity, that is a harder
problem, but it would be good for you to verify that you
can detect the simpler problems first.

thanks,

bryan



Mime
View raw message