Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <528577338.1136331181910.JavaMail.jira@ajax.apache.org>
Date: Wed, 4 Jan 2006 00:33:01 +0100 (CET)
From: "Suresh Thalamati (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-239) Need a online backup feature  that does
 not block update operations   when online backup is in progress.
In-Reply-To: <131892714.1114538125243.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12361686 ] 

Suresh Thalamati commented on DERBY-239:
----------------------------------------

inplace-compress with online backup problem:

I was scanning through the code to find out any issues with online backup and in-place compress and came across the following code that does a checkpoint before truncating the container. 
 
FileContainer.java:
protected void compressContainer(
....
// make sure we don't execute redo recovery on any page
// which is getting truncated.  At this point we have an exclusive
// table lock on the table, so after checkpoint no page change
// can happen between checkpoint log record and compress of space.
dataFactory.getRawStoreFactory().checkpoint();


Above code assumes that redo will only start after the checkpoint 
done by the compress, that is true in crash-recovery. But  
restore from backup can start redo from a checkpoint that is taken when backup was started, which can be before the checkpoint done by compress. if compress is run in parallel to the backup, restore from the backup can FAIL because it can not find the pages needed by the redo if a container gets backed up after it is truncate by the compress. 

I could not think of an easy way to avoid the need for the compress to perform checkpoint while truncating a container. 

One way to make good online backup when in-place compress is 
in progress seems to be by enforcing the following restrictions similar to the way unlogged operations are handled:

1) Block in-place compress operation if backup is in progress and 
2) Make backup operation wait/fail until compress is done. 


I don't like to add restrictions, but I guess compress is an infrequent operation, so it may be ok. 


Any comments/suggestions ?

Thanks
-suresht


> Need a online backup feature  that does not block update operations   when online backup is in progress.
> --------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-239
>          URL: http://issues.apache.org/jira/browse/DERBY-239
>      Project: Derby
>         Type: New Feature
>   Components: Store
>     Versions: 10.1.1.0
>     Reporter: Suresh Thalamati
>     Assignee: Suresh Thalamati
>  Attachments: obtest_customer.jar, onlinebackup.html, onlinebackup1.html, onlinebackup_1.diff, onlinebackup_2.diff, onlinebackup_3.diff, onlinebackup_4.diff, onlinebackup_5.diff, onlinebackup_6.diff
>
> Currently Derby allows users to perfoms  online backups using SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure,  but while the backup is in progress, update operations are temporarily blocked, but read operations can still proceed.
> Blocking update operations can be real issue specifically in client server environments, because user requests will be blocked for a long time if a 
> backup is in the progress on the server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira