Method for deallocating a log in database systems

Abstract

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. Also described is improved log deallocation methodology provided by the system which alleviates the needs to read each of the log pages to be deallocated, as was conventionally required. The operation to do the deallocation occurs at the allocation page, not at the individual pages (which are to be deallocated). In accordance with this method, the system writes a log record which includes the first page and the last page of the run (i.e., the number of those pages). The system need not, however, read any of the pages of the run, other than the first page and the last page. In a common case of a completely filled allocation unit, the system reads two pages--the first page and the last page--and writes one log record. As a result, the system reads far fewer log pages and writes but a single log record.

Claims

What is claimed is:

1. In a database system, said database system maintaining a log for recording transactions which occur in said system, an improved method for deallocating log pages during archiving of the log, the method comprising:

storing information about the transactions which occur in the system as a plurality of log records, said log records being stored together on a plurality of log pages, a number of said log pages being stored together as an allocation unit;

receiving a request to dump certain ones of said log records to an archive device;

determining which allocation units stores said certain ones of said log records to archive;

for said determined allocation units, determining first and last log pages for said certain ones of said log records to be dumped to the archive device; and

for each allocation unit determine to store said certain ones of said log records, deallocating log pages by at least performing:

if an allocation unit is completely filled with log records to be deallocated, deallocating those log records by marking the allocation unit as having deallocated log pages, the step being performed without fetching any log pages for the allocation unit.

2. The method of claim 1, further comprising:

before deallocating said certain ones of the log records, storing a new log record indicating said first and last log pages to be deallocated.

3. The method of claim 1, wherein said log records are stored sequentially by the system.

4. The method of claim 1, wherein each allocation unit stores an allocation page together with a plurality of log pages.

5. The method of claim 4, wherein each allocation unit stores 255 log pages.

6. The method of claim 4, wherein each allocation page stores flags indicating which log pages of the corresponding allocation unit are deallocated.

7. The method of claim 6, wherein said step of deallocating includes:

resetting the flag on an allocation page for indicating deallocation of corresponding log pages for a particular allocation unit.

8. The method of claim 1, wherein said request to dump certain ones of said log records comprises an SQL "dump" command.

9. The method of claim 1, wherein said certain ones of said log records comprise those log records storing information about transactions which are no longer active in the system.

10. The method of claim 1, wherein the log pages for each allocation unit are further grouped into extent groups, and wherein said deallocating step includes resetting a flag in a corresponding allocation page for indicating that a particular extent group is deallocated.

11. The method of claim 1, further comprising:

placing a lock on an allocation page for performing said deallocating step while protecting said allocation page from change by another process.

12. The method of claim 11, further comprising:

releasing said lock upon completing said deallocating step.

13. The method of claim 1, wherein said information about transactions comprises information indicating modification of data stored by the database system.

14. The method of claim 1, further comprising:

linking said allocation units together to form a chain of allocation units storing logging information for the system.

15. The method of claim 1, wherein the system inserts a checkpoint record into the log for indicating an oldest active log record, and wherein said log is dumped to archive at a point before said oldest active log record.

Description

The present application claims priority from and is a continuation-in-part of provisional application Ser. No. 60/025,880, filed Sep. 18, 1996 pending, the disclosure of which is hereby incorporated by reference.

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 (DBMS).

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.TM. clients connected to one or more Sybase SQL Server.TM. database servers. Both Powersoft.TM. and Sybase SQL Server.TM. 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 posting 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 pre-existing, 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.TM.. 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 arc 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 through the log semaphore, contention on the log semaphore is lowered. Contention alleviated by the PLC dramatically increases transaction throughput of the database server system.

Because log records can reside in a user or private log cache, the present invention also provides a mechanism for ensuring that such records are flushed (to the log page chain) before the corresponding data page is flushed. If a change which affects a data page is represented in a private log cache, a "PLC pin" for that page is instantiated to point to a corresponding PLC structure. When such a data page is written, the system first unpins the PLC pin, thus causing the corresponding PLC structure to be flushed to the log page chain. Now, the data page will get a pin to the log, for indicating where in the log records must be flushed in order to write the data page. The addition of the second pointer to the data page buffer provides a two-phase unpinning mechanism. Unpinning a page now requires that the corresponding private log cache (i.e., the one being pointed to by the pointer stored in the page) be first flushed to the log page chain. Secondly, the in-memory log itself is flushed to disk (up to the point in the log required for writing that data page).

In a preferred embodiment, the system of the present invention includes an improved data backup system which is especially suited to the backup of information stored in a large transactional database. The backup system is capable of backing up data while the transactional database is still active, and is capable of utilizing multiple backup archive devices to increase the speed at which a backup takes place. Additionally, the information to be backed up is processed through a calculation to determine stripe affinity, a method for ensuring the integrity of the database backups made to multiple backup devices simultaneously, while also permitting the reloading of data from fewer devices than used to make the original backup.

In such a system, the "archiving" part of a DUMP TRANSACTION command is done by the backup server. Here, the backup server copies the information which is in the log to an archive device (e.g., tape drive). The "deallocation" part of the command is performed by the SQL database server deallocating particular log pages. In the specific commercial embodiment of Sybase SQL Server, this task is carried out as follows. The SQL database server sends a "run list" of pages to the backup server. Since the log pages, like data pages, are divided up into allocation units, the run list represents a portion of an allocation unit. In the exemplary embodiment of SQL Server, an allocation unit comprises 256 pages. Of that unit, one page is designated as an "allocation page" (of that unit). The allocation page itself stores information describing which pages of the allocation unit had been allocated and deallocated. Each allocation unit can be further divided into extents. Extents, each which typically comprises eight pages, map to different objects. Within a data segment of a database, therefore, extents can map to different objects. Here, each extent is associated with no more than one object.

According to the present invention, log deallocation methodology is provided such that the system no longer needs to read each of the log pages to be deallocated, as was conventionally required. The operation to do the deallocation occurs at the allocation page, not at the individual pages (which are to be deallocated). In accordance with this method, the system writes a log record which includes the first page and the last page of the run (i.e., the number of those pages). A new log record type--LOGDEALLOC--is provided by the system for this purpose. This new log record is associated with information describing the first and last page of a run. The system need not, however, read any of the pages of the run, other than the first page and the last page. In a common case of a completely filled allocation unit, the system reads two pages--the first page and the last page--and writes one log record. As a result, the system reads far fewer log pages and writes but a single log record. In the instance where an allocation unit is not completely filled, the method is instead adapted to deallocate one extent at a time, thus still reading fewer pages and writing fewer log records. Here, the system reads two pages of the extent and writes a single log record. In prior approaches, in contrast, a database system would have read all eight pages of the extent and written eight log records for describing deallocation of each those pages. The approach of the present invention is particularly advantageous in a multi-user environment where writing numerous log records leads to increased contention for the system log, a shared resource.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating a computer system in which the present invention may be embodied.

FIG. 1B is a block diagram illustrating a software subsystem for controlling the operation of the computer system of FIG. 1A.

FIG. 2A is a block diagram of a client/server system in which the present invention is preferably embodied.

FIG. 2B is a simplified block diagram summarizing data structures conventionally employed for logging transactions.

FIG. 2C is a simplified block diagram illustrating improved data structures employed in the system of the present invention for logging transactions.

FIG. 3A is a detailed block diagram illustrating improved data structures employed by the system of the present invention for logging transactions.

FIG. 3B is a block diagram illustrating a transaction log marker or XLRMARKER employed by the system of the present invention for tracking log records.

FIGS. 4A-E are block diagrams illustrating operation of the system of the present invention for logging a transaction which includes an INSERT operation affecting two data pages.

FIGS. 5A-E are block diagrams of the logging data structures illustrating system processing when a private log cache (PLC) reaches a state where it is full.

FIGS. 6A-E are block diagrams of the logging data structures of the present invention illustrating processing in the system for an example where a data page used by a pending transaction is written to disk (e.g., by a virtual memory manager).

FIGS. 7A-C are block diagrams of the logging data structures of the present invention illustrating system processing in the instance where a client request immediate flushing of log records.

FIG. 8 is an illustration of a typical SQL Server/Backup Server installation made in accordance with the instant invention.

FIG. 9 is a chart listing a set of suitable backup phases performed in accordance with the instant invention.

FIG. 10A is an illustration of a stripe directory based on the contents of an allocation page.

FIG. 10B is an illustration showing the interface between the Session Handler and the Service Tasks.

FIG. 10C is an illustration showing the assignment of extents to run lists depicted in FIG. 10A.

FIG. 11A is an illustration of the allocation of extent groups to stripes when the number of database disks being dumped is greater than or equals the number of stripes.

FIG. 11B is an illustration of the allocation of extent groups to stripes when the number of database disks is fewer than the number of stripes.

FIG. 12 is a graph illustrating the number of directory bits required to record stripe affinity for up to 32 stripes.

FIG. 13 is an illustration of the restoration of data from fewer archive devices than used during backup, in accordance with the instant invention.

FIG. 14 is a block diagram illustrating diagrammatically how a log file is deallocated in the system of the present invention.

FIG. 15 is a block diagram illustrating division of labor for log file deallocation, for the system previously illustrated in FIG. 8.

FIG. 16 is a block diagram illustrating an "allocation unit" for storing a plurality of pages, including log pages.

FIG. 17 is a block diagram illustrating run time storage of log pages using a plurality of allocation units, where some of the allocation units are fully allocated for the log.

FIG. 18 is a flow chart illustrating a method of the present invention for log deallocation, which includes method steps for deallocating log pages without requiring fetching of those individual pages.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The following description will focus on the presently preferred embodiment of the present invention, which is operative in a network environment executing client/server database applications. The present invention, however, is not limited to any particular application or environment. Instead, those skilled in the art will find that the present invention may be advantageously applied to any application or environment where optimization of logging performance is desirable, including non-SQL database management systems and the like. The description of the exemplary embodiments which follows is, therefore, for the purpose of illustration and not limitation.

Standalone System Hardware

The invention may be embodied on a computer system such as the system 100 of FIG. 1A, which comprises a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a screen display device 106, and a persistent or mass storage 107 (e.g., hard or fixed disk, removable or floppy disk, optical disk, magneto-optical disk, and/or flash memory). Processor 101 includes or is coupled to a cache memory 109 for storing frequently accessed information; memory 109 may be an on-chip cache or external cache (as shown). Additional output device(s) 108, such as a printing device, may be included in the system 100 as desired. As shown, the various components of the system 100 communicate through a system bus 110 or similar architecture. In a preferred embodiment, the system 100 includes an IBM-compatible personal computer system, available from a variety of vendors (including IBM of Armonk, N.Y.).

Standalone System Software

Illustrated in FIG. 1B, a computer software system 150 is provided for directing the operation of the computer system 100. Software system 150, which is stored in system memory 102 and on disk memory 107, includes a kernel or operating system (OS) 140 and a GUI (graphical user interface) shell 145. One or more application programs, such as application software 155, may be "loaded" (i.e., transferred from storage 107 into memory 102) for execution by the system 100. The system also includes a UI (user interface) 160 for receiving user commands as input and displaying user data as output. Although shown as a separate component, the UI 160 is typically provided by the GUI operating under the control of the OS 140, program(s) 155, and Relational Database Management System (RDBMS) client 170. The RDBMS client or "front-end" 170 itself may comprise any one of a number of database front-ends, including PowerBuilder.TM., dBASE.RTM., Paradox.RTM., Microsoft.RTM. Access, or the like. In an exemplary embodiment, the front-end will include SQL access drivers (e.g., Borland SQL Links, or Microsoft ODBC drivers) for accessing SQL database server tables in a Client/Server environment.

Client/Server Database Management System

While the present invention may operate within a single (standalone) computer (e.g., system 100 of FIG. 1A), the present invention is preferably embodied in a multi-user computer system, such as a client/server system. FIG. 2A illustrates the general structure of a Client/Server Database System 200 which is preferred for implementing the present invention. As shown, the system 200 comprises one or more Client(s) 210 connected to a Server 230 via a Network 220. Specifically, the Client(s) 210 comprise one or more standalone Terminals 211 connected to a Database Server System 240 using a conventional network. In an exemplary embodiment, the Terminals 211 may themselves comprise a plurality of standalone workstations, dumb terminals, or the like, or comprise personal computers (PCs) such as the above-described system 100. Typically, such units would operate under a client operating system, such as Microsoft Windows/MS-DOS for PC clients.

The Database Server System 240, which comprises Sybase SQL Server.TM. (Sybase, Inc. of Emeryville, Calif.) in an exemplary embodiment, generally operates as an independent process(es) (i.e., independently of the clients) running under a server operating system such as Microsoft Windows NT (Microsoft Corp. of Redmond, Wash.), NetWare (Novell of Provo, Utah), or UNIX (Novell). The Network 220 may be any one of a number of conventional network systems, including a Local Area Network (LAN) or Wide Area Network (WAN), as is known in the art (e.g., using Ethernet, IBM Token Ring, or the like). The Network includes functionality for packaging client SQL calls and its parameters into a format (of one or more packets) suitable for transmission across a cable or wire, for delivery to the Database Server 240.

Client/server environments, database servers, and networks are well documented in the technical, trade, and patent literature. For a general discussion of database servers and client/server environments, see, e.g., Nath, A., The Guide to SQL Server, Second Edition, Addison-Wesley Publishing Company, 1995. Additional documentation of SQL Server.TM. is available from Sybase, Inc. as SQL Server Documentation Set (Catalog No. 49600). For a discussion of a computer network employing Microsoft Networks/OpenNet File Sharing Protocol, see METHOD AND SYSTEM FOR OPPORTUNISTIC LOCKING IN A NETWORKED COMPUTER SYSTEM, Intl. Application No. PCT/US90/04570, Intl. Publication No. WO 91/03024, Intl. Publication Date Mar. 7, 1991. For a general introduction to a Local Area Network operating under NetWare, see Freed, L. et al., PC Magazine Guide to Using NetWare, Ziff-Davis Press, 1991. A more detailed discussion is available in NetWare 3.x and 4.x and accompanying documentation, which is available from Novell of Provo, Utah. The disclosures of each of the foregoing are hereby incorporated by reference.

In operation, the Client(s) 210 store data in or retrieve data from one or more database tables 250, shown in FIG. 2A. Typically resident on the Server 230, each table itself comprises one or more horizontal rows or "records" (tuples) together with vertical columns or "fields." A database record includes information which is most conveniently represented as a single unit. A record for an employee, for example, may include information about the employee's ID Number, Last Name and First Initial, Position, Date Hired, Social Security Number, and Salary. Thus, a typical record includes several categories of information about an individual person, place, or thing. Each of these categories, in turn, represents a database field. In the foregoing employee table, for example, Position is one field, Date Hired is another, and so on. With this format, tables are easy for users to understand and use. Moreover, the flexibility of tables permits a user to define relationships between various items of data, as needed.

During a database session or "connection" with the Server, each Client issues one or more SQL commands to the Server. SQL commands may specify, for instance, a query for retrieving particular data (i.e., data records meeting the query condition) from the table 250. The syntax of SQL (Structured Query Language) is well documented; see, e.g., the abovementioned An Introduction to Database Systems. In addition to retrieving the data from Database Server tables, the Clients also include the ability to insert new rows of data records into the table; Clients can also modify and/or delete existing records in the table.

During system operation, the SQL statements received from one or more Clients 210 (via Network 220) are processed by Engine 260 of the Database Server System 240. The Engine 260 itself comprises a Parser 261, Normalizer 263, Compiler 265, Execution Unit 268, Access Methods 269, and Logging System 270. Specifically, the SQL statements are passed to the Parser 261 which converts the statements into a query tree--a binary tree data structure which represents the components of the query in a format selected for the convenience of the system. In this regard, the Parser 261 employs conventional parsing methodology (e.g., recursive descent parsing).

The query tree is normalized by the Normalizer 263. Normalization includes, for example, the elimination of redundant data. Additionally, the Normalizer performs error checking, such as confirming that table names and column names which appear in the query are valid (e.g., are available and belong together). Finally, the Normalizer can also look up any referential integrity constraints which exist and add those to the query.

After normalization, the query tree is passed to the Compiler 265, which includes an Optimizer 266 and a Code Generator 267. The Optimizer is responsible for optimizing the query tree. The Optimizer performs a cost-based analysis for formulating a query execution plan. The Optimizer will, for instance, select the join order of tables (e.g., when working with more than one table); it will select relevant indexes (e.g., when indexes are available). The Optimizer, therefore, performs an analysis of the query and picks the best execution plan, which in turn results in particular ones of the Access Methods being invoked during query execution.

The Code Generator 267, on the other hand, converts the query tree into a set of instructions suitable for satisfying the query. These instructions are passed to the Execution Unit 268. Operating under the control of these instructions, the Execution Unit 268 generates calls into lower-level routines, such as the Access Methods 269, for carrying out the query-specified operation, such as fetching relevant information (e.g., row 255) from the database table 250. After the plan has been executed by the Execution Unit, the Server returns a query result or answer table back to the Client(s).

For enhancing the speed in which the Database Server stores, retrieves, and presents particular data records, the Server maintains one or more database indexes 245 on the table. A database index, typically maintained as a B-Tree data structure, allows the records of a table to be organized in many different ways, depending on a particular user's needs. An index may be constructed as a single disk file storing index key values together with unique record numbers. The former is a data quantity composed of one or more fields from a record; the values are used to arrange (logically) the database file records by some desired order (index expression). The latter are unique pointers or identifiers to the actual storage location of each record in the database file. Both are referred to internally by the system for locating and displaying records in a database file. As clients insert more and more data into a particular one of the table(s) 250, a corresponding one of the index(es) 245 continues to grow.

As transactions are processed by the system, Logging System 270 is used to log changes which occur to the system. In the commercial embodiment of Sybase SQL Server System 11, this is done by posting log records to a transaction log. Every transactional update to an object, including inserts, updates, and deletes, causes a log record to be written to the transaction log or simply "log." In SQL Server, 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 pre-existing, consistent state.

The Logging System 270 will now be described in further detail. In particular, the description will focus on improved methods of the present invention for logging transactions.

Improved transaction logging

A. Introduction

Since a log is a shared resource in a multi-user database system, much contention exists for the log, as multiple users desire concurrent access to the log for performing transactions. At the same time, a system must control access to the log for preventing one user from overwriting the results of another user.

The semaphore is employed for controlling access to the log. Often, a dedicated semaphore--a "log semaphore"--is employed for this purpose. The semaphore locks access to the system log table(s) so that a particular task can post log entries, as necessary, without interference from another concurrent task. Such an approach, however, presents a pronounced bottleneck to scalability. Each transaction which wants to write a log record must build the record on its stack, take out the log semaphore, and copy the log record into the page chain (where the log is currently being appended to).

The log itself exists in two versions: an in-memory version and a disk version. The in-memory version of the log exists as a page chain in system memory. Here, data pages storing log records are linked together in memory to form a chain of pages. The in-memory log is flushed, at appropriate times, to disk, for creating the disk version of the log. In typical operation, when a transaction "commits," the log records must first be written to disk before the database system proceeds with actually committing the transaction. "Write-ahead logging" is a rule in the database server governing how a data page (buffer) and its corresponding log records are written to disk. Succinctly stated, the rule dictates that a data page cannot be written to disk until the log records describing the change to that page have been (previously) written to disk. A given transaction will even "sleep" while waiting for its log records to be written to disk. Therefore, the log records must go to disk before the data pages.

Write-ahead logging is implemented by using a "pinning" mechanism. Each data page is associated with a context buffer storing housekeeping information for a data page, including a "log pin." The log pin is a pointer which points to the place in the log indicating up to where in the log the log must be flushed to disk before the data page itself can be written to disk. Until these log records are written to disk, the data page is "pinned" to the in-memory log (i.e., log page chain).

Complementing the notion of pinning is "unpinning." Consider a scenario where a database server's buffer manager desires to write a pinned buffer to disk (e.g., write the page to disk, according to a least-recently used scheme). Before the buffer manager can write that page to disk it should preferably "unpin" the page. As dictated by the write-ahead logging rule, this "unpinning" causes part of the log to be flushed to disk.

FIG. 2B provide a simplified diagram summarizing the data structures employed for logging. As shown in FIG. 2B, the system log or "syslogs" comprises an in-memory page chain 280 including, for instance, log page 281 and log page 283. To post log records to the syslogs, a task must take out the log semaphore 287. In particular, as each record is appended to the syslogs, at log page 281, the log semaphore 287 is held. Without further improvement to the logging system, much contention would exist among the various tasks for the log. To provide improved scalability, therefore, one must solve the problem of contention for the log semaphore.

One approach to solving contention for a resource is to split up the resource. For a logging system, for instance, it is possible to employ multiple semaphores guarding different parts of the log. In general, however, a log is a structure where log records are appended to one end. Protecting the log structure with multiple semaphores would require multiple insertion points into the log. As readers of the log, such as recovery systems, rely on the log being sequential (e.g., for "playback" of log records), adding multiple insertion points leads to greater complexity in processing and maintaining the log. Quite simply, destroying the sequential nature of the log would convert it from a simple, easy-to-maintain structure to one which is far more complicated--one requiring complex processing at multiple subsystem levels other than that of the logging system (e.g., such as in the error recovery system). Since the sequential nature of the log is a fundamental property which is highly desirable to preserve, therefore, an approach employing multiple log semaphores is not attractive.

Another approach would be for a task to take out a log semaphore but not, at that point, copy the log record into the log. Instead, the task would simply reserve a space in the log structure, which would eventually receive a copy of the log record. Here, the semaphore is not held while copying but, instead, is only held for reserving a space--typically, a much shorter time period. The approach is not without problems, however. In particular, the approach creates "holes" in the log structure. Each hole represents a reserved space in the log which has yet to receive a log record. The approach leads to increased complexity in design and maintenance of the log since additional processing is required for correct treatment of "holes," for instance, during transaction roll back or error recovery.

B. "Private Log Caches"

1. Overview

A logging system, constructed in accordance with the present invention, provides a plurality of user or "private" log caches (PLCs). Instead of a task writing log records into the log page chain, the task instead buffers the log records in system memory. When the task needs to either flush that cache or commit the transaction, the system flushes the log records to the log page chain. At that instance, the task takes out the log semaphore and copies all the log records from the private log cache into the system log. Using this approach, each task requires the log semaphore much less frequently, since the semaphore is only needed at the point where log records are flushed from the private log cache to the log page chain.

FIG. 2C provide a simplified diagram illustrating the improved data structures employed for logging in the system of the present invention. As shown, each task writes a generated log record to its own "private log cache"--a region of memory reserved for the particular database connection or "user." For instance, the task first writes its log records to private log cache 291. The log semaphore, shown as 291, is not held by the task during this process. Only when the private log cache for a task needs to be flushed to the actual log is the log semaphore taken out by a task. In instances where a page can be concurrently updated without a transactional lock (e.g., OAM (Object Allocation Map) pages in Sybase SQL Server), the PLC containing log record(s) describing a change to such a page are flushed before the end of the transaction. In either instance, the approach of the present invention greatly reduces contention for the log semaphore.

A consequence of this approach is that log records tend to be much more grouped together. In other words, the log records for a given task or connection will tend to be grouped together as they are flushed as a group from the private log cache of a task to the log page chain. What is important to note, however, is that the sequence of the log records is preserved on a per transaction basis.

2. Improved Logging Data Structures

Before describing internal methods of operation for the system, it is first helpful to examine in further detail the core data structures employed by the system. FIG. 3A illustrates logging data structures 300, which interact during system operation. The data structures include a syslogs page chain 310--a representation of the log in system memory. The page chain itself is comprised of individual pages, such as pages 311, 312, 313, and 314. As shown, each page includes a page header (e.g., page header 321 for page 311) which stores housekeeping information for its page. Also shown, each page stores forward and backward pointers for referencing previous and next neighbors in the page chain. Each page also includes a directory or row lookup 323 for locating the particular offset in the page where a given record (identified by row number) is located. Access to the page chain, which is globally shared, is provided through log semaphore 330. By reducing contention for the log semaphore 330, system scalability improves.

The right hand side of FIG. 3A illustrates two data pages: data page 1 (340) and data page 2 (350). Each data page is associated with a buffer data structure which stores information for supporting the in-memory image of the page. Although shown together, a data page image and its corresponding buffer data structure do not necessarily reside in contiguous portions of memory. The information stored by the buffer structure is relevant only when the data page resides in-memory (as opposed to on-disk). Information which is relevant includes, for instance, a PLC pinning flag (e.g., pin 341) as well as a log pinning flag (e.g., pin 342).

The logging data structures 300 also include a transaction logging descriptor (XXS) 360. In an exemplary embodiment, this data structure is linked (via a pointer) to a transaction descriptor (xdes) data structure which completely characterizes a transaction. Implementation of an xdes data structure is described in commonly-owned, co-pending application Ser. No. 08/537,020, filed Oct. 2, 1995, the disclosure of which is hereby incorporated by reference. The XXS data structure, on the other hand, may be constructed as follows (using the C programming language).

    __________________________________________________________________________
    /*
    ** XXS - XLS Session descriptor
    */
    typedef struct xxs
    /* Link for active transaction list - MUST BE FIRST */
    LINK  xxs.sub.-- activelist;
    /* External data to XLS - none */
    /* Internal data */
    /*
    ** This set remain constant once the XXS object
    ** is attached to the XDES object.
    */
    struct xdes
            *xxs.sub.-- xdes;
                  /* Pointer to attached XDES */
    struct pss
            *xxs.sub.-- pss;
                  /* Pointer to task's PSS
                  ** (housekeeping)
    PLCSTATE
            *xxs.sub.-- plc;
                  /* Pointer to task's PLC */
    /*
    ** This set remain constant during a transaction.
    */
    struct dbtable  *xxs.sub.-- dbt;  /* Database for transaction */
    /*
    ** This set varies over the life of a transaction.
    */
    struct sdes
             *xxs.sub.-- syslogs.sub.-- xact; /* SDES for SYSLOGS for xacts
             */
    uint32     xxs.sub.-- state; /* State of XLS session */
    int      xxs.sub.-- plclrn; /* LRN id of first lr in PLC */
    int      xxs.sub.-- count; /* Total number of lr's written */
    circ.sub.-- long
             xxs.sub.-- flushseq; /* Current dirty seq. for flush */
    int      xxs.sub.-- error; /* Error for last failure */
    struct sdes
             *xxs.sub.-- syslogs.sub.-- scan; /* SDES for SYSLOGS for SCANs
             */
    XLSCAN     *xxs.sub.-- scan; /* Current scan structure */
    uint32     xxs.sub.-- reqmarkers;
    uint32     xxs.sub.-- nlreqmarkers;
    XLRMARKER
             xxs.sub.-- markers ›XLSM.sub.-- NUM.sub.-- MARKERS!;
    }XXS;
    __________________________________________________________________________

    __________________________________________________________________________
    /*
    **
      PLCSTATE - PLC object
    **
    **
      The PLCSTATE holds the state information for the PLC itself.
    **
      Each PLCSTATE owns one PLC.sub.-- DATA object, which is where log
      records are
    **
      actually cached.
    **
    **
      XXS <-> PLC synchronisation
    **
    ** plc.sub.-- xkeeper -
              Identifies the the XLS session (via the internal
    **        descriptor (XXS *)) that keeps the PLC. This field
    **        may only be changed by the task that owns
    **        the XLS session and only when holding the PLC
    **        lock.
    **
    **        This means that the keeper of the PLC can read
    **        this field without any synchronisation. All other
    **        tasks must grab the PLC lock to see a stable value for
    **        this field.
    **
    **        The PLC at any time is kept by at most one XLS session.
    **        If an XLS session does not have the PLC kept
    **        (plc.sub.-- xkeeper is NULL), then there can be
    **        no log records in the PLC. The thread owning
    **        the PLC may avoid locking the PLC if the current XLS
    **        session does not have the PLC kept. The assumption
    **        is that other threads have no interest in the PLC
    **        when it is empty.
    **
    ** plc.sub.-- lockcount Can only be read and modified under the PLC
       spinlock.
    */
    typedef struct plcstate
    /* External data to XLS - none */
    /* Internal data */
    /*
    ** This set remain constant once the PLCSTATE object
    ** is attached to the PLC.sub.-- DATA object.
    */
    struct  spinlock  *plc.sub.-- spinlock;  /* Spinlock for PLC */
    BYTE   *plc.sub.-- start;
                    /* Start of PLC.sub.-- DATA */
    BYTE   *plc.sub.-- end;
                    /* End of PLC.sub.-- DATA */
    int    plc.sub.-- maxpagecount;
                    /* Maximum number of
                    ** log pages required
                    ** to flush the PLC.
                    */
    /*
    ** This set is variable during the life of the PLCSTATE
    */
    int    plc.sub.-- lockcount;
                     /* PLC semaphore count */
    int    plc.sub.-- waiters;
                     /* # of waiters for PLC lock */
    int    plc.sub.-- maxlength;
                     /* max len of next log rec */
    int    plc.sub.-- count;
                    /* # of log records in PLC */
    int    plc.sub.-- logspace.sub.-- free;
                     /* number of bytes still
                    ** reserved in log through
                    ** the threshold manager.
                    */
    /*
    ** plc.sub.-- offset
    **
    ** if the PLC is not being flushed then plc.sub.-- offset is the
    ** address where the next log record will be placed in the PLC.
    **
    ** Otherwise plc.sub.-- offset is the address of the next log record
    ** to be removed from the PLC.
    */
    BYTE    *plc.sub.-- offset;
    struct xxs
            *plc.sub.-- xkeeper;
                    /* Current XXS keeper of PLC */
    struct pss
            *plc.sub.-- locker;
                    /* Pss of task locking the PLC */
    struct syb.sub.-- buf  *plc.sub.-- bufhead;  /* Header of pinned buffer
    chain
    */
    }PCSTATE;
    __________________________________________________________________________

    __________________________________________________________________________
    /*
    **
      XLRMARKER - Log Record Marker - OPAQUE to XLS clients.
    **
    **
      Clients of the XLS must not assume or have knowledge of
    **
      any of the below.
    **
    **
      Internally a XLRMARKER has two formats, non-permanent and permanent.
    **
    **
      In the non-permanent form the marker is the numeric
    **
      order of the log record with the first being XXS.sub.-- LRN.sub.--
      FIRST (==1)
    **
      This is stored in u.sub.-- xlr.sub.-- marker.
    **
    **
      In the permanent form the marker is the RID of the log record
    **
      (ie. once it has made it to the log page chain). This is stored
    **
      in u.sub.-- xlr.sub.-- rid.
    */
    typedef  struct xlrmarker
    union
    {
    struct
    {
    pgid.sub.-- t  fakepage;
    int32 u.sub.-- xlr.sub.-- marker;
    }s;
    RID u.sub.-- xlr rid;
    }u;
    } XLRMARKER;
    /* Markers stored in XXS */
    #define
        XLSM.sub.-- FIRST 0
                   /* First log record of transaction */
    #define
        XLSM.sub.-- LAST 1
                   /* Last log record of transaction */
    #define
        XLSM.sub.-- CMDSTART
                   2  /* Client defined CMDSTART */
    #define
        XLSM.sub.-- ABORTMARK
                   3  /* Client defined ABORTMARK i.e.
                  ** a place in log to rollback to
                  */
    #define
        XLSM.sub.-- LASTSAVE
                   4  /* Client define LASTSAVE
                  ** i.e. a savepoint in log to rollback to
                  */
    #define
        XLSM.sub.-- LASTINPAGECHAIN
                       5  /* Last log record added to page
    chain */
    #define
        XLSM.sub.-- NUM.sub.-- MARKERS 6
                      /* Number stored in XXS */
    /* Markers not stored in XXS */
    #define
        XLSM.sub.-- SCAN (-1)
                   /* Current log record of log scan
    #define
        XLSM.sub.-- OLDESTXACT
                   (-2) /* Oldest active transaction */
    #define
        XLSM.sub.-- LOGLAST
                   (-3) /* Last log record in log page chain */
    #define
        XLSM.sub.-- LOGFIRST
                   (-4) /* First log record inlog page chain
    */
    __________________________________________________________________________

• Inventors
  Sherman, Andrew P.; McCargar, Scott E.;
• Assignee
  Sybase, Inc. (Emeryville, CA)
• Published
  Nov-3-1998
• Current US Classes:
  707/200
• Application #
  748941
• International Classes
  G06F 017/30
• Field of Search
  707/1 707/2 707/3 707/7 707/8 707/9 707/10 707/100 707/101 707/102 707/103 707/104 707/200 707/201 707/202 707/203 707/204 707/205 707/206 1/1 711/130 711/141 711/162 711/209 395/182.13
• Examiner
  Black; Thomas G.
• Agent
  Smart; John A.
• US Patent References:
  4961134
  5008786
  5155678
  5455946
  5493668
  5537574
  5717919