Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1996-11-08
2001-11-20
Banankhah, Majid A. (Department: 2151)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C709S241000
Reexamination Certificate
active
06321234
ABSTRACT:
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which 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
The present invention relates generally to information processing environments and, more particularly, to the process of logging transactions which are posted in a data processing system, such as a Database Management System (D)BMS).
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 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 SQL Server™ database servers. Both Powersoft™ and Sybase SQL Server™ are available from Sybase, Inc. of Emeryville, Calif. The general construction and operation of a database management system, including “client/server” relational database systems, is 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)—posting 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 SQL Server System 11, this is done by costing 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.” In System 11, the transaction log is referred to as “syslogs.” 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, database system includes subsystems 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 SQL database systems, such as Sybase SQL Server™. As a result, increasingly higher demands are being placed on server-based SQL database 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 called 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—particularly the log “semaphore”—dramatically increases, resulting in reduced system throughput. What is needed are system and methods which preserve database throughput by reducing the contention which occurs for logging resources, even when such a system is scaled up with multiple database engines. The present invention fulfills this and other needs.
SUMMARY OF THE INVENTION
A SQL database server system having an enhanced logging system is described. The logging system implements a “private log cache” (PLC) for reducing the contention on the system's “log” resource (which is protected by a log semaphore). An area of memory private to a user's task is set aside as a PLC—a cache where log records are built and stored before being posted to the log. Each PLC may hold multiple log records for a single transaction before they are flushed to the log (page chain) through the log semaphore. When a transaction commits or the memory fills with log records, the PLC associated with the transaction is flushed to the log. Because the log records for a complete transaction are immediately transferred throu
Banankhah Majid A.
Smart John A.
Sybase Inc.
LandOfFree
Database server system with improved methods for logging... 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 server system with improved methods for logging..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database server system with improved methods for logging... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2607991