db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5195) Create tools for browsing the files in the database log directory.
Date Mon, 09 May 2011 15:35:03 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030774#comment-13030774

Rick Hillegas commented on DERBY-5195:

Thanks for the comments, Mike. Some more discussion below...

MM> o personally I would rather not see these types of tools added as supported to the
DERBY project, but rather either as unsupported
   SANE tools or as tools on top of derby in another project. I don't think the production
derby.jar should be weighed down with debugging code/tools.
  If we decide to start "supporting" more
   tools i think they should be checked into a different part of the codeline and a different
jar file. I do think it would be nice if there
   was a place to check in unsupported tools on top of DERBY, and we have discussed it in
the past but nothing came of it. A number
   of other things come to mind like user definined functions and datatypes. I think there
have been some useful VTI's that would
   also fit into this.

It might make sense to distinguish between supported and unsupported tools. I have attached
a number of tools to JIRA issues. Technically I don't consider myself responsible for fixing
them when they don't work as advertised. Practically speaking, I have been pretty responsive
about fixing these tools when complaints come in. It would be pretty funny if the distinction
between unsupported and supported turned out to be this: for an unsupported tool, a Derby
developer gives you a fix right away, whereas for a supported tool, you won't get a fix until
the next Derby release.

Another way to distinguish tools would be by who the target users are. The programs in derbytools.jar
seem to be aimed at the developers who write Derby-powered apps, the dbas who administer those
apps in production, and the tech support engineers who field bugs logged against those apps.
In contrast, I suspect that ControlFileReader, LogFileReader, and DataFileReader will be used
mostly by derby-dev developers, that is, us. It's possible that these tools might be used
by tech support engineers who support specific Derby-powered apps--but I think that is highly
unlikely. I don't think those engineers want to become experts in Derby's internal formats.
To me, these new tools seem most useful when the bug ends up in Derby's JIRA tracker.

Don't know if that helps push the conversation forward, but I thought it was worth saying.

MM> o I scanned the DataReader file and it looked like it did not depend on store at all,
so would also benefit from not being in the
   store file structure so that it keeps that independence.

LogFileReader imports org.apache.derby.iapi.store.raw.Loggable in order to get its hands on
some constants. It would be easy to break that dependency. Both DataFileReader and LogFileReader
depend on other machinery in the engine, chiefly code under org.apache.derby.iapi.services.

MM> o I also worry if we productize these then they could be used in unintended ways and
may cause problems by their use. The intent
   is to use single user on a copy of the database, but what happens if people start running
these against a running database either
   by choice or accidently. A lot of the existing corruptions of DERBY have come from users
manipulating the log and datafiles by hand. I
   would rather not encourage more to do so.

Don't know how these interactions would play out. The new tools merely read the files in log
and seg0. The tools never change the files though. Don't know if merely reading these files
would trip up another Derby engine.

MM> o These tools basically let anyone scan a table (sort of), how does that fit in with
SQL security? 

Right. DataFileReader lets you print out a table if you have access to the database directory
and know both the table's conglomerate number and its row signature. A moderately competent
engineer could write this tool in less than a week provided that they knew about the data
formats described here: http://db.apache.org/derby/papers/pageformats.html So, the tool costs
maybe a couple thousand dollars to write. Amortized over just a couple criminal customers,
the cost per crime could be even lower. Note also that you can view a surprising amount of
a Derby database by just cat'ing the files in seg0. I would agree that the tools slightly
increase the vulnerability of low value data.

> Create tools for browsing the files in the database log directory.
> ------------------------------------------------------------------
>                 Key: DERBY-5195
>                 URL: https://issues.apache.org/jira/browse/DERBY-5195
>             Project: Derby
>          Issue Type: Task
>    Affects Versions:
>            Reporter: Rick Hillegas
>         Attachments: ControlFileReader.java, ControlFileReader.java, LogFileReader.java,
LogFileReader.java, LogFileReader.java
> It would be nice to have some tools to examine the contents of the log directory. The
tools should be able to read the files in that directory without disturbing them.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message