Browse Prior Art Database

Safe Update based on partial knowledge and available evidence Disclosure Number: IPCOM000020579D
Original Publication Date: 2003-Nov-28
Included in the Prior Art Database: 2003-Nov-28
Document File: 2 page(s) / 50K

Publishing Venue



Generally databases must read data to be updated for validation and other reasons before performing the update. Unlike writing, which can be performed lazily, this reading must be completed before operation continues. This can severely limit throughput, particularly in serial use of the database. There may often be sufficient data already available in memory buffers to validate the update. This may for example be held in buffered indices or automated summary tables (materialized views). The database may use such data to avoid the need to read of the full data record before validating the update, and thus the read may be lazy and throughput improved.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Safe Update based on partial knowledge and available evidence

The throughput of updates in a database system is sometimes limited by the need to read 'old' values before the update can be safely applied. Database writes (other than log writes) may safely be 'lazy', and log writes are concentrated and may be coattailed or serially batched. Reads may not be lazy, as the result of read is required before processing can continue. They may be sometimes be batched by the use of parallelism in the reading application.

    A particularly severe example is in database replication, where a stream of incoming updates must be applied in the right order, and parallelism becomes difficult to manage.

    In some cases, there will be sufficient evidence in memory to guarantee that the update is valid, even though the full record to be updated is not available.

    This evidence may be in the form of 'Automated Summary Table' or 'Index' records held in the buffer pool, or in an 'Intelligent Structured Cache'.

    In this case the update may be logged and processed based on that evidence without waiting for recovery of the full affected data record. The data record may be read and updated asynchronously.

  Current sequence of operations for a database update: user update request

log update of record [forward and optional backward logging; may be deferred but

force update from buffer pool [asynchronous, may happen at any time]

    There are many detailed variations to this basic sequence, eg we do not show backout scenarios. These do not affect the overall proposal.

  Proposed sequence: user update request

check for availability of evidence of correctness of update; return error if not

correct (partial) log update of record [forward logging; may be deferred but must happen

complete 'deferred' log update of record [if necessary]

force update from buffer pool [asynchronous, may happen at any time]

    Until the full update has been applied (including recovering the data page, updating it, and writing it back), the update will be remembered in database memory (step 4) to ensure that any queries between the 'logical' update time (when the log record is written and transaction committed) and the 'physical' update time (when the base record is retrieved, checked, updated and saved) see the correct updated data.