Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 30 Aug 2013 18:02:52 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12666339.1377874825379.61620.1377885772053@arcas>
In-Reply-To: <JIRA.12666339.1377874825379@arcas>
References: <JIRA.12666339.1377874825379@arcas>
Subject: [jira] [Commented] (DERBY-6327) Give applications a way to request
 that Derby consistency-check crashed databases.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Rick Hillegas commented on DERBY-6327:
--------------------------------------

Thanks for listing those other areas where we could improve our consistency checking, Mike.

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:

1) The risk that your data is defective goes up every time the database crashes.

2) The risk that your data is defective goes up further if the RDBMS can't complete crash recovery successfully.

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.

In my experience, most end-users go for option (i). They want a data manager which maximizes support for that option.

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