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] [Updated] (DERBY-6328) Improve Store error messages and repair tools for corrupt index conglomerates.
Date Fri, 30 Aug 2013 15:23:51 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-6328:
---------------------------------

    Description: 
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.


  was:
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. 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.


    
> 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

Mime
View raw message