[
https://issues.apache.org/jira/browse/DERBY-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754959#comment-13754959
]
Mike Matrigali commented on DERBY-6328:
---------------------------------------
i agree it would good for these errors to at least provide a conglomerate
number, and maybe for a nested language level error to provide the table/index
name. Especially with write cache enabled corrupted db's it is hard for store
to know what it might see on a page.
For instance in error case I think the page it is trying to read in just has
never been formatted, store likely requested a formated version of the page be
forced to disk but it was not. Part of the page is the format id telling what
object the page is, and if we can't identify
that object it is a serious error that is completely unexpected by store.
> Improve Store error messages and repair tools for corrupt index conglomerates.
> ------------------------------------------------------------------------------
>
> Key: DERBY-6328
> URL: https://issues.apache.org/jira/browse/DERBY-6328
> Project: Derby
> Issue Type: Improvement
> Components: SQL, Store
> Affects Versions: 10.11.0.0
> Reporter: Rick Hillegas
>
> If file system write-caching is enabled and the machine crashes, Derby
> conglomerates can be corrupted. By default, write-caching is usually enabled.
> For performance reasons, applications often leave it on despite our warning
> that this can lead to data corruption. Even if an application vendor
> recommends the disabling of the write-cache, the end user may still choose to
> leave it on. To reduce the tech-support burden for these applications, we
> could do the following:
> o Improve Store error messages for errors caused by corrupt conglomerates. If
> the Store knows that a conglomerate is corrupt, the error message ought to be
> able to indicate which conglomerate needs repair. XBM0U is an example of an
> error message which could carry this extra information.
> o We could provide a system procedure which takes an index conglomerate
> number as an argument and then drops and re-creates that conglomerate. This
> may result in a cascading series of conglomerate recreations if foreign keys
> are involved. This could be cheaper than compressing all of the tables in a
> big database after one conglomerate becomes corrupt.
> This enhancement request was suggested by 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
