Browse Prior Art Database

Mechanisms for Bounding Recovery Time in a Data Sharing Environment using a Shared Buffer

IP.com Disclosure Number: IPCOM000106656D
Original Publication Date: 1993-Dec-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 2 page(s) / 100K

Publishing Venue

IBM

Related People

Dan, A: AUTHOR [+3]

Abstract

Disclosed is an efficient approach for bounding recovery time in a transaction processing system using deferred write policy on a data sharing environment with shared buffer, assuming a single point of failure (node or shared buffer). Solutions are proposed for two environments -- one where all page transfers must be through the shared buffer, and the other where direct node to node page transfer can take place.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Mechanisms for Bounding Recovery Time in a Data Sharing Environment using a Shared Buffer

      Disclosed is an efficient approach for bounding recovery time
in a transaction processing system using deferred write policy on a
data sharing environment with shared buffer, assuming a single point
of failure (node or shared buffer).  Solutions are proposed for two
environments -- one where all page transfers must be through the
shared buffer, and the other where direct node to node page transfer
can take place.

      In a data sharing environment, where multiple nodes share a
global buffer and updated pages are propagated to the shared buffer
at the transaction commit points, failure of a node or the shared
buffer requires database recovery.  This recovery time can be large
if the number of pending updates (i.e., the number of log entries
that need to be redone to recover) is large.  The requirement
therefore is to propose an efficient solution that bounds recovery
times in these scenarios without requiring disk writes to be
synchronous.

      In this invention disclosure, we describe how the recovery time
under a single failure (node or shared store) can be bounded by
limiting the number of log entries that need to be applied.

      After a failure, database recovery attempts to recreate the
database state by starting with the latest image that is available
(on the disk, in the shared memory, or in a non-failed node) and
reapplying all the logs that are applicable since this version.  Now
if the number of logs that need to be applied is large, then database
recovery time could be large.  Consequently, we want to maintain a
condition that if a crash were to happen at any random instant, the
number of logs that need to be applied to a page is bounded.  Let us
call this limit as U, the pending update count on a page.

      In order to maintain the above condition, the following
requirements must be met in our environment:

1.  We could maintain multiple current (dirty) copies of a page, so
    that under our single failure assumptions, the latest copy is
    always available from either the shared memory or some node.

2.  If a dirty page has only one in-memory copy, then we must make
    sure that the disk version of the page is not too stale (i.e. the
    disk and the in-memory versions do not differ by more than U
    updates).  Consequently, if the number of pending updates exceeds
    U, we must force the page to the disk.

      The operating environment is such that if the disk image of a
page is different from the current version in a node, then the shared
memory must also have the current version.  This is because of two
reasons:

1.  Nodes go to the shared memory before they go to the disk, and
    with this mechanism, they are guaranteed to get the latest page
    image.

...