Low-overhead built-in timestamp column for relational database systems

Abstract

An improved automatically updated timestamp for database systems is disclosed. The automatically updated timestamp can be provided in a hidden timestamp column for a table, where the value of the timestamp column can be retrieved with a query that calls the column by name. Optionally, the timestamp column can be provided for each table in the database system to ensure its availability to applications. For cases where a timestamp for each row in a table is not desired, an automatically updated timestamp can be provided for a data page. This timestamp can be retrieved from an update timestamp recorded on disk and in the buffer pool or from a log relative byte address. Although this is a page-level timestamp, its use may be desirable for infrequently updated tables or where space on the disk and buffer pool is at a premium.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS[0001]Under 35 USC § 120, this application is a continuation application and claims the benefit of priority to U.S. patent application Ser. No. 10 / 777,604, filed Feb. 11, 2004, entitled “LOW-OVERHEAD BUILT-IN TIMESTAMP COLUMN FOR RELATIONAL DATABASE SYSTEMS”, all of which is incorporated herein by reference.FIELD OF THE INVENTION[0002]The present invention relates to database systems, and more particularly to providing timestamps in database systems.BACKGROUND OF THE INVENTION[0003]The need for data replication in a database system, particularly a distributed database system, is well known in the art. To ensure data consistency, modifications to different copies of a table must be replicated across all copies. To facilitate the updating of the table copies, timestamps are typically used to indicate which rows have been modified since the last update. Conventionally, a timestamp column that is automatically updated each time a row is modified is...

AI Technical Summary

Problems solved by technology

If the timestamp column is not the same, the disconnected update fails, and the application has to re-drive the update process using the modified data row.

First, it requires additional CPU cost to maintain the timestamp column in each data row.

Second, some tables may not be updated very frequently, so it may not be worthwhile to require the additional space for the timestamp in every row.

Third, if the timestamp column has to be explicitly added to the table by the user, shrink-wrapped client applications cannot assume that the timestamp column will necessarily be present, since the user may have chosen not to add the timestamp column.

So, client applications will be reluctant to exploit this feature of the database.

Fourth, having an explicit column for the timestamp is also inconvenient for cases where some applications need the extra column while others do not.

For example, adding the extra timestamp column for one application might cause problems for other existing applications that didn't expect this extra column to be part of the table schema.

Images