db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: [jira] Commented: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
Date Fri, 22 Jul 2005 19:07:17 GMT
Daniel John Debrunner wrote:

>Suresh Thalamati (JIRA) wrote:
>
>  
>
>>    [ http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12316434
] 
>>
>>Suresh Thalamati commented on DERBY-239:
>>----------------------------------------
>>    
>>
>
>[comments just on this issue]
>
>  
>
>>b) read each pages in to the page cache first and then  latch  the
>>   page in the cache until a  temporary copy of it is made. This approach
>>   does not have extra overhead of extra latches on the page keys during writes ,
but 
>>   will pollute the page cache with the pages that are only required by the 
>>   backup; this  might have  impact on user operations because active user pages may

>>   have been replaced by the backup pages in the page cache. 
>>
>>or 
>>
>>c) read pages into buffer pool and latch them while making a copy  similar to
>>the above approach,  but some how make sure that user pages are not kicked out 
>>of the buffer pool.
>>    
>>
>
>I think b) is the correct approach, but what is 'buffer pool' in c)?
>
>  
>
>I think modifications to the cache would be useful for b), so that
>entries in the cache (through generic apis, not specific to store) could
>mark how "useful/valuable" they are. Just a simple scheme, lower numbers
>less valuable, higher numbers more valuable, and if it makes it easier
>to fix a range, e.g. 0-100, then that would be ok. Then the store could
>added pages to the cache with this weighting, e.g. (to get the general idea)
>
>     pages for backup - weight 0
>     overflow column pages - weight 10
>     regular pages - weight 20
>     leaf index pages - weight 30
>      root index pages 80
>
>This weight would then be factored into the decision to throw pages out
>or not.
>
>This project could be independent of the online backup and could have
>benfits elsewhere.
>
>Dan.
>
>
>
>  
>


"buffer pool"  is  hangover  from my old job,  I meant "page cache"  in  
option c).   I also think  b)  is the correct   approach,
if  the cache  can be   enhanced as you  described.


Thanks
-suresht
 


Mime
View raw message