[
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
