db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6327) Give applications a way to request that Derby consistency-check crashed databases.
Date Fri, 30 Aug 2013 19:19:51 GMT

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

Mike Matrigali commented on DERBY-6327:
---------------------------------------

On 8/30/2013 11:02 AM, Rick Hillegas (JIRA) wrote:> As a philosophical aside, I don't think
that any complex data manager can "guarantee" that the data is consistent and correct. At
best, a complex data manager can merely assert that it can't detect any defects. For Derby
and other RDBMSes, it's also true that:
> 
My not exact definition of "guarantee that the data is consistent and correct" is that the
database reflects correctly all database operations performed by the user and has enforced
all constraints defined by sql standard (there is probably more here).  It also guarantees
that all updates that are part of a committed transaction remain and all those of uncommitted
transaction do not.  By that definition I believe that Derby and RDMS's do in fact meet that
"guarantee" and also when running on supported hardware guarantee 
it through system and machine crashes.
> 1) The risk that your data is defective goes up every time the database crashes.
There can always be bugs, but Derby is designed to not make your data defective in this case,
if it is running on supported hardware and configurations.   I guess I could add that the
risk of your data is defective goes up every time you make any change to database also.
> 
> 2) The risk that your data is defective goes up further if the RDBMS can't complete crash
recovery successfully.
agreed.  My argument is that derby does not currently even have a complete set of tools for
looking "logical" problems.  And Derby as currently designed will never have the ability in
this case to check for transactional issues (like half of committed transaction).
> 
> After a disaster, the end-user has 2 options:
> 
> i) Carry on with the latest dataset even though the risk of defects has gone up.
> 
> ii) Throw away the most recent changes and go back to an older snapshot whose risk of
defects is lower.
This is currently the only supported option.  Note also that Derby also supports a backup
that allows recovery up the current set of log files on disk.  This will not help if current
log files are preventing booting.
> 
The option we recommend for critical applications if they can not do ii is as follows:
1) do whatever hacking/magic to get current data readable - while making them aware that data
may be bad.
2) create a new database and export from corrupted db and import into new db.  This eliminates
the possiblity of running into more error later
due to some unseen corruption with existing consistency tools.  
> In my experience, most end-users go for option (i). They want a data manager which maximizes
support for that option.
I agree, I just want to not pretend that Derby is designed to function correctly in this case
currently.  I welcome continued discussion on more ways to help here.  
> 
> Thanks,
> -Rick
                
> 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

Mime
View raw message