Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2002-07-02
2004-04-13
Mizrahi, Diane D. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06721765
ABSTRACT:
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to information processing environments and, more particularly, to improved methods for logging of transactions which are posted in a data processing system, such as a database management system (DBMS).
2. Description of the Background Art
Computers are very powerful tools for storing and providing access to vast amounts of information. Computer databases are a common mechanism for storing information on computer systems while providing easy access to users. A typical database is an organized collection of related information stored as “records” having “fields” of information. As an example, a database of employees may have a record for each employee where each record contains fields designating specifics about the employee, such as name, home address, salary, and the like.
Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, a database management system or DBMS is typically provided as a software cushion or layer. In essence, the DBMS shields the database user from knowing or even caring about underlying hardware-level details. Typically, all requests from users for access to the data are processed by the DBMS. For example, information may be added or removed from data files, information retrieved from or updated in such files, and so forth, all without user knowledge of the underlying system implementation. In this manner, the DBMS provides users with a conceptual view of the database that is removed from the hardware level.
DBMS systems have long since moved from a centralized mainframe environment to a de-centralized or distributed environment. Today, one generally finds database systems implemented as one or more PC “client” systems, for instance, connected via a network to one or more server-based database systems (SQL database server). Commercial examples of these “client/server” systems include Powersoft® clients connected to one or more Sybase® Adaptive Server® Enterprise database servers. Both Powersoft® and Sybase® Adaptive Server® Enterprise (formerly Sybase® SQL Server®) are available from Sybase, Inc. of Dublin, Calif. The general construction and operation of database management systems, including “client/server” relational database systems, is well known in the art. See e.g., Date, C., “An Introduction to Database Systems, Volume I and II,” Addison Wesley, 1990; the disclosure of which is hereby incorporated by reference.
Traditionally, database management systems (e.g., the above-described client/server database systems) have been employed for on-line transaction processing (OLTP) involving the posting of data from “transactions” to a database table. As part of this process, OLTP systems typically employ a logging system to log changes which occur to the system. In a commercial embodiment such as Sybase Adaptive Server Enterprise, this is done by copying log records to a transaction log. Every transactional operation, including inserts, updates, and deletes, causes a log record to be written to the transaction log or simply “log.” Each particular log record characterizes the change which has occurred to the database during processing of a transaction. This information can be used, for instance, in error recovery, to restore the database to a preexisting, consistent state.
Consider a scenario where a transaction performs updates to a table but then the transaction “rolls back”—that is, aborts. In such a case, the system will undo the updates by reading backwards from the log and reversing the changes which were made (as a result of the updates). The recovery system of databases, therefore, employs the logging system and log records when performing the work of rolling back a transaction. In a similar fashion, the log can be used in the face of a failure, such as when a machine “crashes.” As the log is read during recovery, some transactions are re-done on the one hand, while incomplete transactions are undone on the other. In addition to rolling back transactions and supporting error recovery, the log also provides an archive for the database, which documents the specific actions which have led to the current state of the database. All told, the log plays a critical part in the design and implementation of present-day relational database systems.
The logging system itself permits reading from and writing to the log. Write access is typically performed by “access methods” within a relational database system (i.e., a database system which presents data as tables or “relations”). In particular, these methods generate log records which describe actions occurring which affect the database. Read access, on the other hand, is generally provided by a recovery system within the database. In general, therefore, a database system includes systems for writing log records into the log and, if needed, reading back those records.
A general description of the design and implementation of a logging system in a relational database is provided by Gray, J. and Reuter, A., “Transaction Processing: Concepts and Techniques,” Morgan Kaufmann Publishers, 1993, the disclosure of which is hereby incorporated by reference. For an overview of relational database systems, see the abovementioned “An Introduction to Database Systems,” the disclosure of which has been previously incorporated by reference.
Each day more and more businesses are run from mission-critical systems which store information on server-based database systems, such as Sybase Adaptive Server Enterprise. As a result, increasingly higher demands are being placed on server-based database management systems to “scale” with increased hardware resources—that is, as more sophisticated hardware (e.g., multi-processor units) becomes available, these systems should provide greater throughput.
The logging system of a database system presents a bottleneck to system scalability, however. This is because every insert, update, and delete operation must make a log entry to protect the database from corruption if a system failure or transaction rollback occurs. Most relational databases process a log entry for each update, insert, or delete statement, and each log entry is processed one at a time. When a log entry is written, the logging system must navigate through a synchronization point referred to as the “log semaphore” which controls concurrent access to the log by multiple database transactions. Because every transaction involves the logging system, its efficiency is paramount to transaction throughput. As scalability increases in a database system and transaction volume increases, the contention for logging resources dramatically increases, resulting in reduced system throughput.
One way for reducing contention for logging resources in a transaction processing system is to provide a private log cache which provides an area of memory where log records relating to a user's task are built and stored before being posted to the log. Each private log cache may hold multiple log records for a transaction. The private log cache is only written to the log when a transaction commits or when memory fills with log records, thereby reducing steady state contention on the logging system. For further description of a database server system having a private log cache see commonly-owned U.S. Pat. No. 6,321,234, “Database Server System with Improved Methods for Logging Transactions.” The disclosure of the foregoing is hereby incorporated by reference for all purposes.
Although use of a private logging cache reduces steady state contention on logging resources, several problems remain in logging systems of c
Bhatt Vadiraja
Ghosh Prasanta
Vaitheeswaran Girish
Mizrahi Diane D.
Riddle G. Maok
Smart John A.
Sybase Inc.
Wu Yicun
LandOfFree
Database system with improved methods for asynchronous... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Database system with improved methods for asynchronous..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database system with improved methods for asynchronous... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3192093