[
https://issues.apache.org/jira/browse/DERBY-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754811#comment-13754811
]
Mike Matrigali commented on DERBY-6327:
---------------------------------------
It should be noted that running the Derby consistency checker DOES NOT
guarantee that the database is consistent, and
we should make sure that we don't give that impression to users. It does do a
number of cross table checks, mostly
dependent on data that is indexed, but it is not a substitute for proper
database recovery and we must not give that
impression to users.
Derby as currently designed cannot support transactional and database
consistency if its request to the operating system
to guarantee data and recovery log to disk is not delivered. This is the case
with write cache enabled disks.
Some (but not all) of problems not found by the consistency checker:
o I don't think we even look at data that is not part of an index.
o blob and clob chains could be broken and we do not do any checking in this
area, and I think it would be impossible
to check consistency other than that the chains don't break.
o There is no checking for partial data from committed transactions that don't
involve index changes, and this is likely
impossible to completely implement. This is the job of the transaction
recovery log, but in the case of write caching
those algorithms do not work and the log can not be counted on.
> Give applications a way to request that Derby consistency-check crashed
> databases.
> ----------------------------------------------------------------------------------
>
> Key: DERBY-6327
> URL: https://issues.apache.org/jira/browse/DERBY-6327
> Project: Derby
> Issue Type: Improvement
> Components: SQL, Store
> Affects Versions: 10.11.0.0
> Reporter: Rick Hillegas
>
> It is common for operating systems to scan/repair the entire file system
> after a machine crash. Similarly, it may be possible/desirable for Derby to
> consistency-check conglomerates when a database is booted after coming down
> ungracefully. A couple issues are worth considering:
> 1) This could be an expensive operation on a large database.
> 2) Derby can't tell the difference between a machine crash and an application
> crash.
> The behavior change would be noticeable for complex, crash-prone applications
> with large databases. That argues against making this the default behavior.
> Applications would need to opt into this extra consistency checking.
> This enhancement request comes out of a discussion on DERBY-5221.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
