CA2422176C - Method and apparatus for interrupting updates to a database to provide read-only access - Google Patents
Method and apparatus for interrupting updates to a database to provide read-only access Download PDFInfo
- Publication number
- CA2422176C CA2422176C CA002422176A CA2422176A CA2422176C CA 2422176 C CA2422176 C CA 2422176C CA 002422176 A CA002422176 A CA 002422176A CA 2422176 A CA2422176 A CA 2422176A CA 2422176 C CA2422176 C CA 2422176C
- Authority
- CA
- Canada
- Prior art keywords
- database
- log
- pages
- page
- consistent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 75
- 238000004590 computer program Methods 0.000 claims description 19
- 238000011084 recovery Methods 0.000 claims description 7
- 230000000977 initiatory effect Effects 0.000 claims description 6
- 230000008569 process Effects 0.000 description 15
- 230000009471 action Effects 0.000 description 9
- 230000004044 response Effects 0.000 description 9
- 238000007726 management method Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 238000005096 rolling process Methods 0.000 description 2
- 238000012550 audit Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 150000002500 ions Chemical class 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2358—Change logging, detection, and notification
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A method and system for suspending log-based updating of a database in a manner that permits its resumption without restore, to permit efficient alternation between a log-based update mode and a database access mode. Unplayed log records are protected, as re versions of database pages at a time when the log-based update was suspended. This permits log-based updating to resume where it left off. In order to ensure consistent data for access, a roll-back procedure creates consistent data pagers that are used for access, and discarded when log-based update resumes.
Description
METHOD AND APPARATUS FOR INTERRUPTING UPDATES TO A
DATABASE TO PROVIDE READ-ONLY ACCESS
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001 ] This is the first application filed for the present invention.
MICROFICHE APPENDIX
DATABASE TO PROVIDE READ-ONLY ACCESS
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001 ] This is the first application filed for the present invention.
MICROFICHE APPENDIX
[0002] Not Applicable.
TECHNICAL FIELD
TECHNICAL FIELD
[0003] The invention relates to database access techniques, and in particular, to a method for providing read-only access to content of a database by suspending a log-based update mode in a manner that enables resumption.
BACKGROUND OF THE INVENTION
BACKGROUND OF THE INVENTION
[0004] Availability of data in databases is of primary concern for database managers and users. The ability to access data for numerous purposes is becoming increasingly important, and there are increasing numbers of access techniques for retrieving useful information from databases.
[0005] Providing manor users with access to a large database, requires equipment adapted to handle a volume of data input and output (UO). The rate at which this I/O is provided and the number of concurrent access requests are major factors affecting a response time of the database system. Response time is another factor considered 2 0 important by database managers and users.
[0006] A third concern of many database managers is disaster recovery. Many large database systems have disaster recovery systems in place to handle a primary database failure, and to provide a backup in case data is corrupted by human error, etc.
Many of these disaster recovery systems require one or more backup copies of the 2 5 database to be saved. FiG. 1 schematically illustrates a primary database server l0a having a buffer pool 12a, and disk storage 14a for holding the primary data; a secondary database server lOb having similar components, for storing the backup data;
and a database management workstation 16, all interconnected by a packet network 18.
The primary database server l0a may be a very busy entity having hundreds of users concurrently updating and retrieving data.
Many of these disaster recovery systems require one or more backup copies of the 2 5 database to be saved. FiG. 1 schematically illustrates a primary database server l0a having a buffer pool 12a, and disk storage 14a for holding the primary data; a secondary database server lOb having similar components, for storing the backup data;
and a database management workstation 16, all interconnected by a packet network 18.
The primary database server l0a may be a very busy entity having hundreds of users concurrently updating and retrieving data.
[0007] Generally the procedures for copying data from the primary disk storage 14a to the backup disk storage 14b is relatively expensive in terms of 1/O, and in some cases, it requires exclusionary access to the primary database server 10a, resulting in a temporarily unavailable primary database. While known mirroring techniques greatly improve this process, duplication of the primary data is still a hardware-intensive process. Given the desire to minimise interruption of availability of the primary database server 10a, and occupation of the I/O hardware, it is therefore known to copy the data once, at a time=t, and then use logs of changes made to the primary database after time=t to update the backup database thereafter. The backup data is maintained concurrent with the primary data to within a guarded temporal lag.
After the log of transactions effected at the primary database is created, it is forwarded to the backup database server lOb, in a procedure knov~rn as log shipping.
After the log of transactions effected at the primary database is created, it is forwarded to the backup database server lOb, in a procedure knov~rn as log shipping.
(0008] Log shipping is well known in the art.. In accordance with common practice, every time the primary database is changed, the transaction is recorded in a 2 0 log, which is usually stored for audit purposes, etc. Copies are made of this log, and shipped to the backup database server 10. After a certain time delay, the logs are "replayed" at the backup database, unless processing is interrupted, as illustrated in FIG. 2.
[0009] As previously noted, each log record defines an action that has been applied to a database object at the primary database server 10a. A log record is retrieved (often in parallel with other log records), and is read (step 50).
It is subsequently determined (in step 52) if the transaction of which the log record is a part is open. If transaction is not open, a procedure for opening the transaction is executed (step 54). All pages that are included in the database object identified in the in the log record are retrieved from the default page locations to the buffer pool (unless they are currently instantiated at the buffer pool), in step _'i6. In step 58, the pages) are retrieved and updated, so that the previous changes tc~ the primary data are then made to the backup data. Once the log record replay is complete, it is determined, in step 60, whether the transaction is now ready to be committed, and if it is the transaction is completed (step 62). Actions necessary to record the affect of the log record are then effected, in step 64. In some embodiments a log sequence number (LSN) may be updated on the retrieved pages) so that the page indicates a last completed transaction applied thereto, a completion log may be updated and the status of the page may otherwise be updated. If another record exists in the update log, this procedure is repeated by returning to step 50.
It is subsequently determined (in step 52) if the transaction of which the log record is a part is open. If transaction is not open, a procedure for opening the transaction is executed (step 54). All pages that are included in the database object identified in the in the log record are retrieved from the default page locations to the buffer pool (unless they are currently instantiated at the buffer pool), in step _'i6. In step 58, the pages) are retrieved and updated, so that the previous changes tc~ the primary data are then made to the backup data. Once the log record replay is complete, it is determined, in step 60, whether the transaction is now ready to be committed, and if it is the transaction is completed (step 62). Actions necessary to record the affect of the log record are then effected, in step 64. In some embodiments a log sequence number (LSN) may be updated on the retrieved pages) so that the page indicates a last completed transaction applied thereto, a completion log may be updated and the status of the page may otherwise be updated. If another record exists in the update log, this procedure is repeated by returning to step 50.
[0010] At any time during this replay process a stop command may be issued (step 66). The stop command may be issued in response to an error condition, a failure, a user input from the management workstation 16, or a programmed response. For example, if the log is empty, or a database manager issues a stop command, the process will halt. If the log is empty, the stop command will likely be issued after step 56, or after step 50, depending on program implementation.
[0011 ] These log record updates may be made in parallel, using known concurrent processing techniques. Consequently many (active) transactions may be ongoing at any 2 0 given time. When a stop command is issued, in step 66, all active transactions are halted. Each of the active transactions is rolled-back (step 68), in a manner well known in the art. Basically, rolling back a transaction involves undoing changes to the pages that the transaction's log records affect.
[0012] As each transaction is either rolled-back or committed, the database after 2 5 the rollback procedure of :step 68, is in a consistent ;Mate. In step 70, abort logs and compensation logs are appended to the transaction log, overwriting any log records following a current log record. As will be appreciated by those skilled in the art, compensation log records are written to indicate the actions taken to undo the changes to the pages effected by the log records of active t:ransact:ions. Abort records are written to indicate which log records have been stopped.
[0013] The backup database is now taken out of update mode, and can be accessed. It will be appreciated by those skilled in thf: art that the data in a consistent state can be used for many purposes. More particularly the backup data may be used for any procedure that requires a substantial amount of I/~~ resources, and therefore cannot be performed at the primary database server l0a without incurring unacceptable performance penalties. For example, generating month-end forms often requires collation of a substantial amount of data, as does creating charts and performing data manipulation operations to generate desired output. Month end forms are much more expeditiously generated using a copy of the database than by retrieving the data piecemeal, and reassembling the data at a workstation. Copies of databases in the consistent state may also >-'e used for myriad database analysis procedures, for model and system testing and design, etc.
[0014] Once the work has been completed, or desired parts of the backup data has been copied to a third location where the work will be completed, the backup database is returned to service as the backup to the primary data. In accordance with known techniques, the current backup database is erased, and a new copy of the primary data is taken at time=t, and copied to the disk storage 14b (step 72). The records of 2 0 transactions applied to the primary data after time=t are then forwarded to the backup database. The backup database may therefore be returned to the log-based update mode (step 74), and thus receive the records of transactions, and continues replaying the data as before.
[0015] As will be appreciated by those skilled iru the art, recopying the primary 2 5 data to the backup system is a time consuming operation that requires considerable 1/O, resources (and network bandwidth when the secondary is not directly connected to the primary). Nonetheless, current highly robust methods for updating data do not terminate in a manner that permits the recommencement of the update process because versions of changed and undone pages that are needed for recovery, and the log > CA 02422176 2003-03-14 records themselves, cannot be recovered. Accordingly there exists a need for a method and system for suspending a log-based update of a database, that permits resumption of the update process.
SUMMARY OF THE INYENTION
[0016] It is therefore an object of the invention to provide a method for suspending a log-based update of a database, that permits resumption of the update process.
[0017] It is a further object of the invention to provide a database system adapted to permit alternation between a log-based update mode and a database access mode.
[001 ~] According to an aspect of the present invention, there is provided, for a database management system, a method for temporarily suspending a log-based update of a database, the method including halting all transactions being processed from an update log on receipt of a stop command, initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages and protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the tulle;d-back database pages, and the update mode resume data.
2 0 [0019] According to another aspect of the present invention, there is provided a database management system for temporarily suspending a log-based update of a database, the database management system including means for halting all transactions being processed from an update log on receipt of a stop command; means for initiating a transaction rollback to undo all uncommitted changes made to database pages in a 2 5 current state by the halted transactions, to obtain a consistent set of the halted pages;
and means for protecting the update log, current and consistent versions of the: rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
[0020] According to yet another aspect of the present invention, there is provided a computer program product having a computer readable medium tangibly embodying computer executable code for directing a database management system to temporarily suspend a log-based update of a database, the computer program product including code for halting all transactions being processed from an update log on receipt of a stop command, code for initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages, and code for protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
BRIEF DESCRIPTION OF THE DRAWINGS
(0021 ] Further features and advantages of the present invention will become apparent from the following detailed description, i:aken in combination with the appended drawings, in which:
(0022] FIG.1 is a block diagram that schematically illustrates a known 2 0 embodiment of a networked database system;
(0023] FIG. 2 illustrates principal steps involved in interrupting and restoring a log-based update mode in a known manner in the database system illustrated in FIG. 1;
[0024] FIG. 3 illustrates principal steps involved in interrupting and restoring a log-based update mode in accordance with a first embodiment of the invention;
2 5 [0025] FIG. 4 illustrates principal steps involved in interrupting and restoring a log-based update mode in accordance with a second err~bodiment of the invention;
[0026] FIG. 5 illustrates a time chart of processes effected in accordance with the first embodiment of the invention; and [0027] FIG. 6 illustrates a time chart of processes effected in accordance with the second embodiment of the invention.
[0028] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.
DETAILED DESCRIPTION OF THE PREFERR>F;D EMBODIMENT
[0029] The invention provides a method of suspending a log-based update process on a database, in order to provide access to a consistent set of pages of the database, while enabling the log-based update process to be resumed using the same log after the access is completed. The invention involves a means for stopping a log-based update process in a manner that permits the log-based update process to be resumed from where it left off. Consequently methods for alternating between the log-based update mode and an access mode are provided.
(0030] In accordance with the present invention, provides a mode of operation in which the pages (frames, blurbs, or other units of retrieval and storage of data) of the database are updated from a sequence of log records. Each log record represents an action on a database object (a record, frame, page, row, or other unit of action). A
transaction comprises a set of log records (each log record can be said to have an 2 0 associated transaction) is an autonomous task in that all of the log records can be completed or all rolled-back independently of a state of any other transaction, without introducing any inconsistency in the database. As one transaction may comprise a plurality of log records that apply changes to a plurality of pages, an imposed serial order of execution of the log records within a transaction, concurrency limits, (such as 2 5 limits on a size of the buffer pool, locks on data etc.) usually results in a period of time between when changes made to some pages have been completed, and when a corresponding transaction is committed.
[0031 ] In many embodiments, an efficient technique variously called "stealing" or "write ahead logging" is used to save changes made to a page by a transaction, before the transaction is committed. It is efficient for pages to only be retained in the buffer pool as long as they are needed. Consequently, when a transaction includes a plurality of actions affecting different pages, Lock contention or buffer space limitations (etc.), or the imposed serial ordering of processing of these log records results in some of these pages being changed before others. These charged pages may then be resaved even though the transaction has not yet been committed, in accordance with i:he write ahead logging technique. This is efficient because it reduces occupancy of the buffer pool, which enhances concurrency using the limited data storage resources.
[0032] It is further advantageous to minimize ease of busses that convey data between the buffer pool and disk storage (or other non-volatile storage medium for storing the data of the database), by keeping a version of a database page in the buffer pool after changes made by one transaction have completed, particularly if another transaction is waiting to access the database page, or it is likely that another transaction will soon require access to the page. In such embodiments, pages in the buffer pool are written to the default page locations whenever space is unavailable to download a requested database page (or other database object). This process called "victimizing".
The victimizing process ascertains which database page in the buffer pool has not been updated in a longest time. This is the page that is resaved (sent to disk) to the respective default page location, making roam for the more immediately relevant database page(s). A victimized page is sent to disk regardless of whether a transaction that has amended it has committed, and a record of thc~ state of the page is recorded in accordance with well known write ahead logging techniques. At checkpoints the 2 5 records are saved to disk so that a non-volatile store of the changes are recorded, and restart after a failure is possible, in a manner that is equally well known in the a.rt.
[0033] The following examples assume the write ahead logging method wherein pages that a transaction has finished changing may be saved to default page locations in the database, but undo information is maintained to enable the undoing of these CA9-2002-0084 g changes, in a manner known in the art. Any database system having a consistent version of pages that differs from a version needed to resume the log-based update mode, can also employ the invention, and the write ahead logging system is an illustrative embodiment of such a database system.
[0034] The access mode is, in many cases, a read-only mode. In some embodiments, "local write" access is permitted. As is well known in the ari:, a local write mode permits writing to only authorized pages, which in the present cases usually has to include only pages that are disjoint from the database pages that can be updated using the log records. If the update mode is used to keep the database in delayed synchrony with a primary database, none of the pages of the secondary database that are to be kept synchronous with primary counterparts can be changed without risk of corrupting the page data during normal operations. In such embodiments, the access mode naturally permits read-only access to these pages.
However, other pages may be accessed for the purposes of storing intermediate results and tables for generating farms, reports, etc.
[0035] FIG.3 schematically illustrates principai~ steps involved in alternating between the log-based update mode and the database access mode, in accordance with a first embodiment of the invention. The first embodiment shall be called the "quick return" embodiment herein, and is contrasted with a second embodiment that shall be 2 0 called the "quick access" embodiment.
[0036] In step 100, the database is in the log-based update mode, and accordingly is replaying log records. In accordance with one aspect of the invention, a user may issue a special connect request, and a database control system is configured to interpret. In step 102, such a special connect request is received by the database control 2 5 system. Since the database is in the log-based update mode, every active transaction log record replay is halted (step 104). The transaction s that are halted axe rolled-back to a state that is consistent with the remainder of the data. The roll-back of the transactions undoes changes made to versions of database pages during replay of respective log records that have been copied to the buffer pool, which is one embodiment of a working area where data can be stored while transactions are effected. In other embodiments, a cache memory or any other memory that can be used as a work area to facilitate data updates can be used. The versions of the database pages having undone charges are marked as "tempora.rily undone" (TU), to ensure that those versions of respective pages are not destroyed or overwritten. The TU
pages (i.e.
the versions of the database pages having undone changes) remain intact throughout the database access mode interlude, so that if a query of the respective page is made during the database access mode, the corresponding TU page is accessed to provide the response. The TU pages are marked to differentiate them from other pages that are in the buffer pool that were not affected by rolled-back transactions. Those other pages can be returned to respective default page locations with no loss of consistency during the access mode interlude, or when the log-based update mode resumes.
[0037] As rolling back transactions involves undoing changes to database pages, some of which may have already been written to disk, the roll-back requires returning the pages to the buffer pool. Of course the buffer pool is a limited resource, and the roll-back of transactions may exceed the buffer pool's capacity. Even if returning previously changed pages does not exceed the buffer pool's capacity, the capacity may be exceeded by read operations querying during the access mode.
[0038] In accordance with one embodiment of the invention (hereina ter the 2 0 "buffer pool" embodiment), the impact of the problem is reduced by selecting a time when the playback of log records is halted. The TU pages are. marked as "unflushable"
so that a TU page cannot be deleted until the system is returned to the log-based update mode. To determine when to halt the log record replay, a number of uncommitted transaction pages is monitored, and when the number is below a predefined threshold, 2 5 the playback is halted.
[0039] In accordance with a "quick return" embodiment, if the buffer pool becomes full, TU pages are saved to a separate storage (step 106), which may be database disk space that is not allocated to any database pages (i.e. separate from the default page locations). Each time a TU page is saved to disk to make space in the buffer pool, an entry in a temporary table of "victimized" TU pages is created (step 108). The entry provides all information required to identify the TU
page, including an address of the separate storage at which the undone version is saved.
[0040] In accordance with the invention, in step 110, rather than writing abort and compensation log records over records subsequent to a current record in the update log, update mode resume data is stored. The update mode resume data provides all data required for the return to the log-based update mode. One way of collecting the update mode resume data is to change an address of an active write pointer from a current location in the log file to a separate storage. The abort and compensation logs, along with any other required data from the buffer pool, are 'used to compile the update mode resume data.
[004'1 ] Once update mode resume data is compiled, and stored, and a consistent set of victimized TU pages are saved and referenced in the temporary table, the database is taken out of log-based update mode, and the access mode is entered with a response to the special connect request that indicates that a connection has been established (step 112). It is important to note that in some embodiments steps 106,108,110 are repeated during the database access mode interlude, if buffer pool space is exhausted, ire which case the update mode resume data may need to be updated, depending on the specific content and format of the update mode resume data.
2 0 [0042] Subsequently, the database receives a query, which it reads in step 114.
Database pages referenced (step 116) by the query are retrieved to the buffer pool (step 118) by first searching the buffer pool to determine if the identified pages are already present; second searching the temporary table of victimized TU pages to see if the consistent version of the page is in the separate storage; and third, retrieving the 2 5 pages from the respective default page locations if they are not found in either of the first two locations. The retrieved data is processed (as determined by applicable permissions), and returned in reply to the query (step 120). Steps 114-120 iterate until an end connection statement is received, as determined in step 122.
[0043] The database is then taken out of the database access mode, and returned to the log-based update mode, by performing an update mode restart using the update mode resume data (step 124). When restarting, the versions of the pages that are stored in the default page locations (current pages) are used and the procedure needs only redo the log records that had not already completed prior to being committed.
The log-base update mode resumes (step 126) starting with pages that were being changed when the stop command was issued, in response to the special connect message.
Thus at this point the consistent versions of the database pages are no longer of use, and so the temporary table of victimized pages, along with the TU pages rnay be deleted any time after the database access mode has been terminated.
[0044] In accordance with a "quick access" embodiment, substantially the same initial steps are performed. The database starts in a log-based update mode (step 200), receives the special connect request (step 202), and issues the stop command, marks the pages associated with aborted transactions as 7f U, and rolls back transactions accordingly (step 204). If the buffer pool becomes congested, and a TU page has to be victimized, the TU page is saved to the default page location after the default page is saved to a separate storage (step 206), such as the separate storage used to store the TU
pages in the quick return embodiment. In order to prevent successive undo actions applied to a given page from saving the currently undone version to the separate 2 0 storage, and then incorrectly saving the new undone page to the default page location, the TU page is marked. Accordingly if a next undo operation is applied to the given page, it will update the TU page in the default page location, but will not overwrite the default page saved to the separate storage.
[0045] As in the quick return embodiment, the compensation and abort :logs are 2 5 not written over current log records, but are rather suspended or written to a separate storage (step 208). The reply indicating that the connection is established, is likewise sent (step 210). In this embodiment, a temporary table of victimized TU pages is not required. This is because the database pages are all accessed in the usual manner, because the consistent versions (TU pages) are stored in respective default page locations. This is what expedites access.
[0046] The database control system processes and replies to queries in sequence while in the database access mode. It therefore receives and reads query statements (step 212), identifies pages) that are to be retrieved (step 224), retrieves the pages in a manner well known in the art, and returns the responses (step 216). If another command is received, the procedure of replying is iterated; otherwise it is determined in step 218, that the special connection has been terminated. As will be appreciated by those skilled in the art, it may be desirable to permit multiple concurrent special request connections. If so, once the database has been. placed in a consistent state, the stop, redo and undo commands are not applied when a second or subsequent special connect request is received. Instead, concurrent access is granted, and the return to the log-based update mode is delayed until all special connect request connections have been terminated.
[0047] When all special connect request connections have been terminated, the update mode is restarted (step 220). The update mode restart procedure in accordance with the present invention uses the update mode resume data to identify a set of operations required to return to the log-based update mode, including information about aborted transactions, states of completion of transactions, states of particular 2 0 pages in the buffer pool, and those in the separate storage. Particular to the quick-access embodiment is the requirement to return each of the versions of the pages in the separate storage to respective default page locations from which they were copied.
This step is not required in the quick-return embodiment, and consequently the quick-access embodiment is slower to return to the log-based update mode than is the quick-2 5 return embodiment. The rolled-back transactions are restarted where the changes were interrupted using the versions of pages (step 222) that are now in the default page locations.
[0048] FIG. 5 schematically illustrates timing of a sequence of events that occur when suspending a log-based update mode in accordance with the quick-access embodiment of the invention discussed above with reference to FIG. 3. In accordance with the quick-access embodiment, three data stores are used, a buffer pool 12 (generalized from FIG. 1), default page locations section 30 of a disk storage (generalized from FIG. 1), and separate storage 32 that rnay occupy a portion of disk storage 14 that is not used for the default page locations section 30. It will be appreciated by those skilled in the art that in normal operation, the database data is normally stored in the default page locations section 30, and that there is normally extra space on the disk storage 14 that can be used fon various other purposes known in the art.
[0049] As noted above, numerous transactions can be performed concurrently by many of today's database systems. This concurrency requires complex procedures for committing or rolling-back transactions when consistency must be restored by database control systems that control the processing of these transactions. In the example shown in FIG. S, multiple concurrent transactions are performed on respective pages. ~nly one of the transactions is illustrated however. The illustrated transaction includes4 log records (Log Rec A, B, C, D, referenced by numerals 250, 252, 254, 256, respectively). Further the database stores pages 1, 2, 3, ~4 in respective default page locations.
[0050] Log record A (250), requires a retrieved of page 1 from the default page 2 0 location 260. Log records B (252) and C (254) arE; both started before log record A (250) is completed. When log record A (250) has teen replayed, the amended page 1 (260') remains in the buffer pool. After some time page 1 (260') is victimized, despite the fact that the transaction it is associated with is still uncommitted. Log Record B (252) requires a change to page 2 (262) that was in the buffer pool when the log 2 5 record B was played. Log record B (252) places a request for a lock on a content of page 2 (262), which is currently being used by a log record of another transaction (not shown). Consequently log record B (252) is forced to wait until the page 2 (262) becomes available. After the lock is effective, replaying of the log record commences, but does not complete before a stop redo command 265 is received.
[0051 ) The replay of log record C (254) requires access to page 3 (264) that currently resides in the buffer pool. A status of such a page is not determined by the transaction. The page may have been chaaiged any number of times previously.
It could have been saved to disk and returned, and still have locks applied by ongoing uncommitted transactions, or it could have been bl~~ck copied and not yet modified since retrieval. Log record C (254) is replayed completes before the stop redo command 265 is issued. The replay of log record D (256) results in modifications to page 4 (266), which is retrieved from the default page location 30. When a stop redo command 265 is received, and the associated procedure is executed, the replay of log record D (256) is still modifying page 4 (266).
[0052] The stop redo command (265) halts all active transactions. In this example the current transaction is halted because log records B (262), and D (266) have not completed. Halting the transaction requires halting the replay of those two log records.
When in progress transactions are halted, the database pages stored at default page locations are inconsistent. The replay of some log records has updated some of the database pages before the replay of the other log records associated with respective transactions are completed or started. Some that have been changed by uncommitted transactions, for example page 1 (260') may have been saved in default page locations.
All of the active transactions must be undone in order to ensure consistent versions 2 0 (TU pages) of all database pages. Thus rollback of transactions is effected pursuant to an undo command 266. IJndoing log record A requires first retrieving page 1 (260) from its default page location. Log record C (254) is the first to be completely undone, followed by log records A, and B. In this example, log record B takes longest to be completely undone, and before it is undone, a page in the buffer pool 12 needs to be 2 5 victimized and it is saved to separate storage, as explained above with reference to FI(i. 3. Once undone, the undone pages are marked as TU. In accordance with the quick return embodiment, the consistent version of page 3 (264) i.e. page 3c (264*) is victimized, and accordingly the page 3c (264*) is saved to the separate storage 32. As described above, the temporary table of victimized TU pages is updated to enable access to their content during database access mode. At the end of the tine illustrated, TU pages of pages 1, 2 and 4 all remain in the buffer :pool 12.
[0053] As described above with reference to FIG.3, in embodiments where the buffer pool 12 is large enough to support all of the pages of alI of the active transactions, and still provide space required to permit access during the database access mode, the TU pages are marked as "unflushable" to prevent them from being over-written, and identifying a place in the logs required to restart the log-based update mode with the existing log may be all that is required to practice the invention.
However, the undo command 275 may cause more I>ages to be returned to the buffer pool 12 than the buffer pool 12 can store. Consequently, in accordance with the quick-return embodiment, once the buffer pool 12 is full, TU pages that are cleared from the buffer pool 12 are saved to the separate storage 32.
[0054] FIG. 6 schematically illustrates timing of actions involved in suspending a log-based update mode in substantially the same environment as illustrated in FIG. 5, but in accordance with the quick-access embodiment described above with reference to FIG. 14. The replay of log record E (300) retrieves page 1 (260), performs a set of actions, completes and the transaction associated with Log record E (:300) i.e.
transaction X commits, yielding a modified page 1 (260'). Page 1 (260°) is then locked by log record F 302, which does not complete before the stop redo command is 2 0 received. Log records F (302), G (304) and H (306) are all associated with a common transaction. The replay of log record G (304) retrieves page 2 (262), replays to completion, yielding page 2 (262'). i~Vhile replay of the log record H (306) is updating the page 3 (264) which was already in the buffer pool, the stop redo 265 command is received. The undo algorithm 266 is then executed and all log records of the 2 5 interrupted transaction axe rolled back, marked as TU, and stored in the buffer pool 12.
In this example, pages in the buffer pool have to be victimised. Log records F, G and H are completely undone, returning the page 1 to the condition of page 1 (260'). Pages 2 and 3 are also undone. Each undone page is marked as TU.
[0055] Subsequently, in accordance with the quick-access embodiment, TU pages 1 (260*) and 3 (264*) are resaved to respective default page locations, after the corresponding pages in the default page locations are saved to the separate storage 32.
As was described above the TU pages 1 and 3 are identifiable as undone pages so that if other log records that affect pages 1 and 3 are undone, then the procedure for undoing retrieves the pages) from the default page Location, changes and resave the pages) to the default page location, without over-writing the original saved in the separate storage 32.
[0056] Determining at least an estimate of an amount of memory required to store database pages associated with currently replaying log records can be useful for determining when to respond to a stop redo command in any of the above-described embodiments of the inventions. There are many different values that can be monitored or examined to obtain an estimate of the free memory required to halt replay at any given moment. Responding to a stop command when the estimate is determined to conform with a predefined constraint can improve performance but generally results in a time lag in the response to the special connection request.
[0057] Although the invention has been described with reference to rollforward processing used in database systems employing the write ahead logging, and having locks at sub-page granularity, the invention is in no way limited to database systems of 2 0 this type.
[0058] The embodiments of the invention described above are therefore intended to be exemplary only, and the scope of the invention is intended to be limited solely by the scope of the appended claims.
[0011 ] These log record updates may be made in parallel, using known concurrent processing techniques. Consequently many (active) transactions may be ongoing at any 2 0 given time. When a stop command is issued, in step 66, all active transactions are halted. Each of the active transactions is rolled-back (step 68), in a manner well known in the art. Basically, rolling back a transaction involves undoing changes to the pages that the transaction's log records affect.
[0012] As each transaction is either rolled-back or committed, the database after 2 5 the rollback procedure of :step 68, is in a consistent ;Mate. In step 70, abort logs and compensation logs are appended to the transaction log, overwriting any log records following a current log record. As will be appreciated by those skilled in the art, compensation log records are written to indicate the actions taken to undo the changes to the pages effected by the log records of active t:ransact:ions. Abort records are written to indicate which log records have been stopped.
[0013] The backup database is now taken out of update mode, and can be accessed. It will be appreciated by those skilled in thf: art that the data in a consistent state can be used for many purposes. More particularly the backup data may be used for any procedure that requires a substantial amount of I/~~ resources, and therefore cannot be performed at the primary database server l0a without incurring unacceptable performance penalties. For example, generating month-end forms often requires collation of a substantial amount of data, as does creating charts and performing data manipulation operations to generate desired output. Month end forms are much more expeditiously generated using a copy of the database than by retrieving the data piecemeal, and reassembling the data at a workstation. Copies of databases in the consistent state may also >-'e used for myriad database analysis procedures, for model and system testing and design, etc.
[0014] Once the work has been completed, or desired parts of the backup data has been copied to a third location where the work will be completed, the backup database is returned to service as the backup to the primary data. In accordance with known techniques, the current backup database is erased, and a new copy of the primary data is taken at time=t, and copied to the disk storage 14b (step 72). The records of 2 0 transactions applied to the primary data after time=t are then forwarded to the backup database. The backup database may therefore be returned to the log-based update mode (step 74), and thus receive the records of transactions, and continues replaying the data as before.
[0015] As will be appreciated by those skilled iru the art, recopying the primary 2 5 data to the backup system is a time consuming operation that requires considerable 1/O, resources (and network bandwidth when the secondary is not directly connected to the primary). Nonetheless, current highly robust methods for updating data do not terminate in a manner that permits the recommencement of the update process because versions of changed and undone pages that are needed for recovery, and the log > CA 02422176 2003-03-14 records themselves, cannot be recovered. Accordingly there exists a need for a method and system for suspending a log-based update of a database, that permits resumption of the update process.
SUMMARY OF THE INYENTION
[0016] It is therefore an object of the invention to provide a method for suspending a log-based update of a database, that permits resumption of the update process.
[0017] It is a further object of the invention to provide a database system adapted to permit alternation between a log-based update mode and a database access mode.
[001 ~] According to an aspect of the present invention, there is provided, for a database management system, a method for temporarily suspending a log-based update of a database, the method including halting all transactions being processed from an update log on receipt of a stop command, initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages and protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the tulle;d-back database pages, and the update mode resume data.
2 0 [0019] According to another aspect of the present invention, there is provided a database management system for temporarily suspending a log-based update of a database, the database management system including means for halting all transactions being processed from an update log on receipt of a stop command; means for initiating a transaction rollback to undo all uncommitted changes made to database pages in a 2 5 current state by the halted transactions, to obtain a consistent set of the halted pages;
and means for protecting the update log, current and consistent versions of the: rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
[0020] According to yet another aspect of the present invention, there is provided a computer program product having a computer readable medium tangibly embodying computer executable code for directing a database management system to temporarily suspend a log-based update of a database, the computer program product including code for halting all transactions being processed from an update log on receipt of a stop command, code for initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages, and code for protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
BRIEF DESCRIPTION OF THE DRAWINGS
(0021 ] Further features and advantages of the present invention will become apparent from the following detailed description, i:aken in combination with the appended drawings, in which:
(0022] FIG.1 is a block diagram that schematically illustrates a known 2 0 embodiment of a networked database system;
(0023] FIG. 2 illustrates principal steps involved in interrupting and restoring a log-based update mode in a known manner in the database system illustrated in FIG. 1;
[0024] FIG. 3 illustrates principal steps involved in interrupting and restoring a log-based update mode in accordance with a first embodiment of the invention;
2 5 [0025] FIG. 4 illustrates principal steps involved in interrupting and restoring a log-based update mode in accordance with a second err~bodiment of the invention;
[0026] FIG. 5 illustrates a time chart of processes effected in accordance with the first embodiment of the invention; and [0027] FIG. 6 illustrates a time chart of processes effected in accordance with the second embodiment of the invention.
[0028] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.
DETAILED DESCRIPTION OF THE PREFERR>F;D EMBODIMENT
[0029] The invention provides a method of suspending a log-based update process on a database, in order to provide access to a consistent set of pages of the database, while enabling the log-based update process to be resumed using the same log after the access is completed. The invention involves a means for stopping a log-based update process in a manner that permits the log-based update process to be resumed from where it left off. Consequently methods for alternating between the log-based update mode and an access mode are provided.
(0030] In accordance with the present invention, provides a mode of operation in which the pages (frames, blurbs, or other units of retrieval and storage of data) of the database are updated from a sequence of log records. Each log record represents an action on a database object (a record, frame, page, row, or other unit of action). A
transaction comprises a set of log records (each log record can be said to have an 2 0 associated transaction) is an autonomous task in that all of the log records can be completed or all rolled-back independently of a state of any other transaction, without introducing any inconsistency in the database. As one transaction may comprise a plurality of log records that apply changes to a plurality of pages, an imposed serial order of execution of the log records within a transaction, concurrency limits, (such as 2 5 limits on a size of the buffer pool, locks on data etc.) usually results in a period of time between when changes made to some pages have been completed, and when a corresponding transaction is committed.
[0031 ] In many embodiments, an efficient technique variously called "stealing" or "write ahead logging" is used to save changes made to a page by a transaction, before the transaction is committed. It is efficient for pages to only be retained in the buffer pool as long as they are needed. Consequently, when a transaction includes a plurality of actions affecting different pages, Lock contention or buffer space limitations (etc.), or the imposed serial ordering of processing of these log records results in some of these pages being changed before others. These charged pages may then be resaved even though the transaction has not yet been committed, in accordance with i:he write ahead logging technique. This is efficient because it reduces occupancy of the buffer pool, which enhances concurrency using the limited data storage resources.
[0032] It is further advantageous to minimize ease of busses that convey data between the buffer pool and disk storage (or other non-volatile storage medium for storing the data of the database), by keeping a version of a database page in the buffer pool after changes made by one transaction have completed, particularly if another transaction is waiting to access the database page, or it is likely that another transaction will soon require access to the page. In such embodiments, pages in the buffer pool are written to the default page locations whenever space is unavailable to download a requested database page (or other database object). This process called "victimizing".
The victimizing process ascertains which database page in the buffer pool has not been updated in a longest time. This is the page that is resaved (sent to disk) to the respective default page location, making roam for the more immediately relevant database page(s). A victimized page is sent to disk regardless of whether a transaction that has amended it has committed, and a record of thc~ state of the page is recorded in accordance with well known write ahead logging techniques. At checkpoints the 2 5 records are saved to disk so that a non-volatile store of the changes are recorded, and restart after a failure is possible, in a manner that is equally well known in the a.rt.
[0033] The following examples assume the write ahead logging method wherein pages that a transaction has finished changing may be saved to default page locations in the database, but undo information is maintained to enable the undoing of these CA9-2002-0084 g changes, in a manner known in the art. Any database system having a consistent version of pages that differs from a version needed to resume the log-based update mode, can also employ the invention, and the write ahead logging system is an illustrative embodiment of such a database system.
[0034] The access mode is, in many cases, a read-only mode. In some embodiments, "local write" access is permitted. As is well known in the ari:, a local write mode permits writing to only authorized pages, which in the present cases usually has to include only pages that are disjoint from the database pages that can be updated using the log records. If the update mode is used to keep the database in delayed synchrony with a primary database, none of the pages of the secondary database that are to be kept synchronous with primary counterparts can be changed without risk of corrupting the page data during normal operations. In such embodiments, the access mode naturally permits read-only access to these pages.
However, other pages may be accessed for the purposes of storing intermediate results and tables for generating farms, reports, etc.
[0035] FIG.3 schematically illustrates principai~ steps involved in alternating between the log-based update mode and the database access mode, in accordance with a first embodiment of the invention. The first embodiment shall be called the "quick return" embodiment herein, and is contrasted with a second embodiment that shall be 2 0 called the "quick access" embodiment.
[0036] In step 100, the database is in the log-based update mode, and accordingly is replaying log records. In accordance with one aspect of the invention, a user may issue a special connect request, and a database control system is configured to interpret. In step 102, such a special connect request is received by the database control 2 5 system. Since the database is in the log-based update mode, every active transaction log record replay is halted (step 104). The transaction s that are halted axe rolled-back to a state that is consistent with the remainder of the data. The roll-back of the transactions undoes changes made to versions of database pages during replay of respective log records that have been copied to the buffer pool, which is one embodiment of a working area where data can be stored while transactions are effected. In other embodiments, a cache memory or any other memory that can be used as a work area to facilitate data updates can be used. The versions of the database pages having undone charges are marked as "tempora.rily undone" (TU), to ensure that those versions of respective pages are not destroyed or overwritten. The TU
pages (i.e.
the versions of the database pages having undone changes) remain intact throughout the database access mode interlude, so that if a query of the respective page is made during the database access mode, the corresponding TU page is accessed to provide the response. The TU pages are marked to differentiate them from other pages that are in the buffer pool that were not affected by rolled-back transactions. Those other pages can be returned to respective default page locations with no loss of consistency during the access mode interlude, or when the log-based update mode resumes.
[0037] As rolling back transactions involves undoing changes to database pages, some of which may have already been written to disk, the roll-back requires returning the pages to the buffer pool. Of course the buffer pool is a limited resource, and the roll-back of transactions may exceed the buffer pool's capacity. Even if returning previously changed pages does not exceed the buffer pool's capacity, the capacity may be exceeded by read operations querying during the access mode.
[0038] In accordance with one embodiment of the invention (hereina ter the 2 0 "buffer pool" embodiment), the impact of the problem is reduced by selecting a time when the playback of log records is halted. The TU pages are. marked as "unflushable"
so that a TU page cannot be deleted until the system is returned to the log-based update mode. To determine when to halt the log record replay, a number of uncommitted transaction pages is monitored, and when the number is below a predefined threshold, 2 5 the playback is halted.
[0039] In accordance with a "quick return" embodiment, if the buffer pool becomes full, TU pages are saved to a separate storage (step 106), which may be database disk space that is not allocated to any database pages (i.e. separate from the default page locations). Each time a TU page is saved to disk to make space in the buffer pool, an entry in a temporary table of "victimized" TU pages is created (step 108). The entry provides all information required to identify the TU
page, including an address of the separate storage at which the undone version is saved.
[0040] In accordance with the invention, in step 110, rather than writing abort and compensation log records over records subsequent to a current record in the update log, update mode resume data is stored. The update mode resume data provides all data required for the return to the log-based update mode. One way of collecting the update mode resume data is to change an address of an active write pointer from a current location in the log file to a separate storage. The abort and compensation logs, along with any other required data from the buffer pool, are 'used to compile the update mode resume data.
[004'1 ] Once update mode resume data is compiled, and stored, and a consistent set of victimized TU pages are saved and referenced in the temporary table, the database is taken out of log-based update mode, and the access mode is entered with a response to the special connect request that indicates that a connection has been established (step 112). It is important to note that in some embodiments steps 106,108,110 are repeated during the database access mode interlude, if buffer pool space is exhausted, ire which case the update mode resume data may need to be updated, depending on the specific content and format of the update mode resume data.
2 0 [0042] Subsequently, the database receives a query, which it reads in step 114.
Database pages referenced (step 116) by the query are retrieved to the buffer pool (step 118) by first searching the buffer pool to determine if the identified pages are already present; second searching the temporary table of victimized TU pages to see if the consistent version of the page is in the separate storage; and third, retrieving the 2 5 pages from the respective default page locations if they are not found in either of the first two locations. The retrieved data is processed (as determined by applicable permissions), and returned in reply to the query (step 120). Steps 114-120 iterate until an end connection statement is received, as determined in step 122.
[0043] The database is then taken out of the database access mode, and returned to the log-based update mode, by performing an update mode restart using the update mode resume data (step 124). When restarting, the versions of the pages that are stored in the default page locations (current pages) are used and the procedure needs only redo the log records that had not already completed prior to being committed.
The log-base update mode resumes (step 126) starting with pages that were being changed when the stop command was issued, in response to the special connect message.
Thus at this point the consistent versions of the database pages are no longer of use, and so the temporary table of victimized pages, along with the TU pages rnay be deleted any time after the database access mode has been terminated.
[0044] In accordance with a "quick access" embodiment, substantially the same initial steps are performed. The database starts in a log-based update mode (step 200), receives the special connect request (step 202), and issues the stop command, marks the pages associated with aborted transactions as 7f U, and rolls back transactions accordingly (step 204). If the buffer pool becomes congested, and a TU page has to be victimized, the TU page is saved to the default page location after the default page is saved to a separate storage (step 206), such as the separate storage used to store the TU
pages in the quick return embodiment. In order to prevent successive undo actions applied to a given page from saving the currently undone version to the separate 2 0 storage, and then incorrectly saving the new undone page to the default page location, the TU page is marked. Accordingly if a next undo operation is applied to the given page, it will update the TU page in the default page location, but will not overwrite the default page saved to the separate storage.
[0045] As in the quick return embodiment, the compensation and abort :logs are 2 5 not written over current log records, but are rather suspended or written to a separate storage (step 208). The reply indicating that the connection is established, is likewise sent (step 210). In this embodiment, a temporary table of victimized TU pages is not required. This is because the database pages are all accessed in the usual manner, because the consistent versions (TU pages) are stored in respective default page locations. This is what expedites access.
[0046] The database control system processes and replies to queries in sequence while in the database access mode. It therefore receives and reads query statements (step 212), identifies pages) that are to be retrieved (step 224), retrieves the pages in a manner well known in the art, and returns the responses (step 216). If another command is received, the procedure of replying is iterated; otherwise it is determined in step 218, that the special connection has been terminated. As will be appreciated by those skilled in the art, it may be desirable to permit multiple concurrent special request connections. If so, once the database has been. placed in a consistent state, the stop, redo and undo commands are not applied when a second or subsequent special connect request is received. Instead, concurrent access is granted, and the return to the log-based update mode is delayed until all special connect request connections have been terminated.
[0047] When all special connect request connections have been terminated, the update mode is restarted (step 220). The update mode restart procedure in accordance with the present invention uses the update mode resume data to identify a set of operations required to return to the log-based update mode, including information about aborted transactions, states of completion of transactions, states of particular 2 0 pages in the buffer pool, and those in the separate storage. Particular to the quick-access embodiment is the requirement to return each of the versions of the pages in the separate storage to respective default page locations from which they were copied.
This step is not required in the quick-return embodiment, and consequently the quick-access embodiment is slower to return to the log-based update mode than is the quick-2 5 return embodiment. The rolled-back transactions are restarted where the changes were interrupted using the versions of pages (step 222) that are now in the default page locations.
[0048] FIG. 5 schematically illustrates timing of a sequence of events that occur when suspending a log-based update mode in accordance with the quick-access embodiment of the invention discussed above with reference to FIG. 3. In accordance with the quick-access embodiment, three data stores are used, a buffer pool 12 (generalized from FIG. 1), default page locations section 30 of a disk storage (generalized from FIG. 1), and separate storage 32 that rnay occupy a portion of disk storage 14 that is not used for the default page locations section 30. It will be appreciated by those skilled in the art that in normal operation, the database data is normally stored in the default page locations section 30, and that there is normally extra space on the disk storage 14 that can be used fon various other purposes known in the art.
[0049] As noted above, numerous transactions can be performed concurrently by many of today's database systems. This concurrency requires complex procedures for committing or rolling-back transactions when consistency must be restored by database control systems that control the processing of these transactions. In the example shown in FIG. S, multiple concurrent transactions are performed on respective pages. ~nly one of the transactions is illustrated however. The illustrated transaction includes4 log records (Log Rec A, B, C, D, referenced by numerals 250, 252, 254, 256, respectively). Further the database stores pages 1, 2, 3, ~4 in respective default page locations.
[0050] Log record A (250), requires a retrieved of page 1 from the default page 2 0 location 260. Log records B (252) and C (254) arE; both started before log record A (250) is completed. When log record A (250) has teen replayed, the amended page 1 (260') remains in the buffer pool. After some time page 1 (260') is victimized, despite the fact that the transaction it is associated with is still uncommitted. Log Record B (252) requires a change to page 2 (262) that was in the buffer pool when the log 2 5 record B was played. Log record B (252) places a request for a lock on a content of page 2 (262), which is currently being used by a log record of another transaction (not shown). Consequently log record B (252) is forced to wait until the page 2 (262) becomes available. After the lock is effective, replaying of the log record commences, but does not complete before a stop redo command 265 is received.
[0051 ) The replay of log record C (254) requires access to page 3 (264) that currently resides in the buffer pool. A status of such a page is not determined by the transaction. The page may have been chaaiged any number of times previously.
It could have been saved to disk and returned, and still have locks applied by ongoing uncommitted transactions, or it could have been bl~~ck copied and not yet modified since retrieval. Log record C (254) is replayed completes before the stop redo command 265 is issued. The replay of log record D (256) results in modifications to page 4 (266), which is retrieved from the default page location 30. When a stop redo command 265 is received, and the associated procedure is executed, the replay of log record D (256) is still modifying page 4 (266).
[0052] The stop redo command (265) halts all active transactions. In this example the current transaction is halted because log records B (262), and D (266) have not completed. Halting the transaction requires halting the replay of those two log records.
When in progress transactions are halted, the database pages stored at default page locations are inconsistent. The replay of some log records has updated some of the database pages before the replay of the other log records associated with respective transactions are completed or started. Some that have been changed by uncommitted transactions, for example page 1 (260') may have been saved in default page locations.
All of the active transactions must be undone in order to ensure consistent versions 2 0 (TU pages) of all database pages. Thus rollback of transactions is effected pursuant to an undo command 266. IJndoing log record A requires first retrieving page 1 (260) from its default page location. Log record C (254) is the first to be completely undone, followed by log records A, and B. In this example, log record B takes longest to be completely undone, and before it is undone, a page in the buffer pool 12 needs to be 2 5 victimized and it is saved to separate storage, as explained above with reference to FI(i. 3. Once undone, the undone pages are marked as TU. In accordance with the quick return embodiment, the consistent version of page 3 (264) i.e. page 3c (264*) is victimized, and accordingly the page 3c (264*) is saved to the separate storage 32. As described above, the temporary table of victimized TU pages is updated to enable access to their content during database access mode. At the end of the tine illustrated, TU pages of pages 1, 2 and 4 all remain in the buffer :pool 12.
[0053] As described above with reference to FIG.3, in embodiments where the buffer pool 12 is large enough to support all of the pages of alI of the active transactions, and still provide space required to permit access during the database access mode, the TU pages are marked as "unflushable" to prevent them from being over-written, and identifying a place in the logs required to restart the log-based update mode with the existing log may be all that is required to practice the invention.
However, the undo command 275 may cause more I>ages to be returned to the buffer pool 12 than the buffer pool 12 can store. Consequently, in accordance with the quick-return embodiment, once the buffer pool 12 is full, TU pages that are cleared from the buffer pool 12 are saved to the separate storage 32.
[0054] FIG. 6 schematically illustrates timing of actions involved in suspending a log-based update mode in substantially the same environment as illustrated in FIG. 5, but in accordance with the quick-access embodiment described above with reference to FIG. 14. The replay of log record E (300) retrieves page 1 (260), performs a set of actions, completes and the transaction associated with Log record E (:300) i.e.
transaction X commits, yielding a modified page 1 (260'). Page 1 (260°) is then locked by log record F 302, which does not complete before the stop redo command is 2 0 received. Log records F (302), G (304) and H (306) are all associated with a common transaction. The replay of log record G (304) retrieves page 2 (262), replays to completion, yielding page 2 (262'). i~Vhile replay of the log record H (306) is updating the page 3 (264) which was already in the buffer pool, the stop redo 265 command is received. The undo algorithm 266 is then executed and all log records of the 2 5 interrupted transaction axe rolled back, marked as TU, and stored in the buffer pool 12.
In this example, pages in the buffer pool have to be victimised. Log records F, G and H are completely undone, returning the page 1 to the condition of page 1 (260'). Pages 2 and 3 are also undone. Each undone page is marked as TU.
[0055] Subsequently, in accordance with the quick-access embodiment, TU pages 1 (260*) and 3 (264*) are resaved to respective default page locations, after the corresponding pages in the default page locations are saved to the separate storage 32.
As was described above the TU pages 1 and 3 are identifiable as undone pages so that if other log records that affect pages 1 and 3 are undone, then the procedure for undoing retrieves the pages) from the default page Location, changes and resave the pages) to the default page location, without over-writing the original saved in the separate storage 32.
[0056] Determining at least an estimate of an amount of memory required to store database pages associated with currently replaying log records can be useful for determining when to respond to a stop redo command in any of the above-described embodiments of the inventions. There are many different values that can be monitored or examined to obtain an estimate of the free memory required to halt replay at any given moment. Responding to a stop command when the estimate is determined to conform with a predefined constraint can improve performance but generally results in a time lag in the response to the special connection request.
[0057] Although the invention has been described with reference to rollforward processing used in database systems employing the write ahead logging, and having locks at sub-page granularity, the invention is in no way limited to database systems of 2 0 this type.
[0058] The embodiments of the invention described above are therefore intended to be exemplary only, and the scope of the invention is intended to be limited solely by the scope of the appended claims.
Claims (48)
1. For a database management system, a method for temporarily suspending a log-based update of a database, the method comprising:
halting all transactions being processed from an update log on receipt of a stop command;
initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages; and protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
halting all transactions being processed from an update log on receipt of a stop command;
initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages; and protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
2. The method as claimed in claim 1 wherein the step of protecting the update log includes precluding compensation and abort logs from being written over unprocessed records in the update log file.
3. The method as claimed in claim 2 wherein the compensation and abort log records are saved to a storage separate from a storage where the update log is stored to ensure that the update log is not overwritten.
4. The method as claimed in claim 3 wherein data retrieved from the abort and compensation logs is used to assemble the update mode resume data, to provide state of page and transaction information.
5. The method as claimed in claim 3 further comprising the step of changing an address of an active write pointer to point to the separate storage prior to saving the compensation and abort log records.
6. The method as claimed in claim 2 wherein the step of protecting the consistent versions of the database pages further includes marking the consistent versions of database pages having undone changes as temporarily undone.
7. The method as claimed in claim 6 wherein the step of protecting the consistent versions of the database pages further includes ensuring that no consistent version of a protected page is victimized.
8. The method as claimed in claim 6 wherein the step of protecting the consistent versions of the database pages further includes the step of ensuring that if a consistent version of a protected page has to be victimized, the consistent version is saved to a storage that is separate from a default page location associated with the database page.
9. The method as claimed in claim 8 wherein the step of ensuring includes adding an entry to a temporary table of victimized pages that have been saved to the separate storage, the entry including an identifier of the database page associated with the consistent version, and a pointer to its location in the separate storage, so that the table provides an expedited lookup index for the consistent version, until the database is returned to a log-based update mode.
10. The method as claimed in claim 6 wherein the step of protecting further includes ensuring that if a consistent page needs to be victimized, the current version of the corresponding database page is copied from a corresponding default page location of the corresponding database page to a separate storage, and the consistent version is saved to the corresponding default page location.
11. The method as claimed in claim 10 wherein the step of ensuring includes inserting an identifier into the consistent version at the corresponding default page location to prevent the current version from being over-written.
12. The method as claimed in claim 10 further comprising ensuring that the current version of the victimized database page is returned to a respective default page location after the database access mode is completed, and the log-based update mode is resumed.
13. The method as claimed in claim 1 wherein the step of halting includes executing a stop redo procedure to halt a forward recovery of log records from a primary database.
14. The method as claimed in claim 13 wherein the step of halting further includes receiving a specified constraint defining a condition for executing the stop redo procedure.
15. The method as claimed in claim 14 further comprising:
determining an estimate of an amount of memory required to store database pages associated with currently active transactions; and performing the stop redo procedure when the estimate is determined to conform with specified constraint.
determining an estimate of an amount of memory required to store database pages associated with currently active transactions; and performing the stop redo procedure when the estimate is determined to conform with specified constraint.
16. The method as claimed in claim 13 wherein the step of halting further includes receiving a special connect request message from a management workstation.
17. A database management system for temporarily suspending a log-based update of a database, the database management system comprising:
means for halting all transactions being processed from an update log on receipt of a stop command;
means for initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages; and means for protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
means for halting all transactions being processed from an update log on receipt of a stop command;
means for initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages; and means for protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
18. The database management system as claimed in claim 17 wherein the means for protecting the update log includes precluding compensation and abort logs from being written over unprocessed records in the update log file.
19. The database management system as claimed in claim 18 wherein the compensation and abort log records are saved to a storage separate from a storage where the update log is stored to ensure that the update log is not overwritten.
20. The database management system as claimed in claim 19 wherein data retrieved from the abort and compensation logs is used to assemble the update mode resume data, to provide state of page and transaction information.
21. The database management system as claimed in claim 19 further comprising means for changing an address of an active write pointer to point to the separate storage prior to saving the compensation and abort log records.
22. The database management system as claimed in claim 18 wherein the means for protecting the consistent versions of the database pages further includes marking the consistent versions of database pages having undone changes as temporarily undone.
23. The database management system as claimed in claim 22 wherein the means for protecting the consistent versions of the database pages further includes ensuring that no consistent version of a protected page is victimized.
24. The database management system as claimed in claim 22 wherein the means for protecting the consistent versions of the database pages further includes the step of ensuring that if a consistent version of a protected page has to be victimized, the consistent version is saved to a storage that is separate from a default page location associated with the database page.
25. The database management system as claimed in claim 24 wherein the means for ensuring includes adding an entry to a temporary table of victimized pages that have been saved to the separate storage, the entry including an identifier of the database page associated with the consistent version, and a pointer to its location in the separate storage, so that the table provides an expedited lookup index for the consistent version, until the database is returned to a log-based update mode.
26. The database management system as claimed in claim 22 wherein the means for protecting further includes ensuring that if a consistent page needs to be victimized, the current version of the corresponding database page is copied from a corresponding default page location of the corresponding database page to a separate storage, and the consistent version is saved to the corresponding default page location.
27. The database management system as claimed in claim 26 wherein the means for ensuring includes inserting an identifier into the consistent version at the corresponding default page location to prevent the current version from being over-written.
28. The database management system as claimed in claim 26 further comprising means for ensuring that the current version of the victimized database page is returned to a respective default page location after the database access mode is completed, and the log-based update mode is resumed.
29. The database management system as claimed in claim 17 wherein the means for halting includes executing a stop redo procedure to halt a forward recovery of log records from a primary database.
30. The database management system as claimed in claim 29 wherein the means for halting further includes receiving a specified constraint defining a condition for executing the stop redo procedure.
31. The database management system as claimed in claim 30 further comprising:
means for determining an estimate of an amount of memory required to store database pages associated with currently active transactions; and means for performing the stop redo procedure when the estimate is determined to conform with specified constraint.
means for determining an estimate of an amount of memory required to store database pages associated with currently active transactions; and means for performing the stop redo procedure when the estimate is determined to conform with specified constraint.
32. The database management system as claimed in claim 29 wherein the means for halting further includes receiving a special connect request message from a management workstation.
33. A computer program product having a computer readable medium tangibly embodying computer executable code for directing a database management system to temporarily suspend a log-based update of a database, the computer program product comprising:
code for halting all transactions being processed from an update log on receipt of a stop command;
code for initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages; and code for protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
code for halting all transactions being processed from an update log on receipt of a stop command;
code for initiating a transaction rollback to undo all uncommitted changes made to database pages in a current state by the halted transactions, to obtain a consistent set of the halted pages; and code for protecting the update log, current and consistent versions of the rolled-back database pages, and update mode resume data from being overwritten, to permit the log-based updating to resume using the update log, the current versions of the rolled-back database pages, and the update mode resume data.
34. The computer program product as claimed in claim 33 wherein the code for protecting the update log includes precluding compensation and abort logs from being written over unprocessed records in the update log file.
35. The computer program product as claimed in claim 34 wherein the compensation and abort log records are saved to a storage separate from a storage where the update log is stored to ensure that the update log is not overwritten.
36. The computer program product as claimed in claim 35 wherein data retrieved from the abort and compensation logs is used to assemble the update mode resume data, to provide state of page and transaction information.
37. The computer program product as claimed in claim 35 further comprising code for changing an address of an active write pointer to point to the separate storage prior to saving the compensation and abort log records.
38. The computer program product as claimed in claim 34 wherein the code for protecting the consistent versions of the database pages further includes marking the consistent versions of database pages having undone changes as temporarily undone.
39. The computer program product as claimed in claim 38 wherein the code for protecting the consistent versions of the database pages further includes ensuring that no consistent version of a protected page is victimized.
40. The computer program product as claimed in claim 38 wherein the code for protecting the consistent versions of the database pages further includes the step of ensuring that if a consistent version of a protected page has to be victimized, the consistent version is saved to a storage that is separate from a default page location associated with the database page
41. The computer program product as claimed in claim 40 wherein the code for ensuring includes adding an entry to a temporary table of victimized pages that have been saved to the separate storage, the entry including an identifier of the database page associated with the consistent version, and a pointer to its location in the separate storage, so that the table provides an expedited lookup index for the consistent version, until the database is returned to a log-based update mode.
42. The computer program product as claimed in claim 38 wherein the code for protecting further includes ensuring that if a consistent page needs to be victimized, the current version of the corresponding database page is copied from a corresponding default page location of the corresponding database page to a separate storage, and the consistent version is saved to the corresponding default page location.
43. The computer program product as claimed in claim 42 wherein the code for ensuring includes inserting an identifier into the consistent version at the corresponding default page location to prevent the current version from being over-written.
44. The computer program product as claimed in claim 42 further comprising code for ensuring that the current version of the victimized database page is returned to a respective default page location after the database access mode is completed, and the log-based update mode is resumed.
45. The computer program product as claimed in claim 33 wherein the code for halting includes executing a stop redo procedure to halt a forward recovery of log records from a primary database.
46. The computer program product as claimed in claim 45 wherein the code for halting further includes receiving a specified constraint defining a condition for executing the stop redo procedure.
47. The computer program product as claimed in claim 46 further comprising:
code for determining an estimate of an amount of memory required to store database pages associated with currently active transactions; and code for performing the stop redo procedure when the estimate is determined to conform with specified constraint.
code for determining an estimate of an amount of memory required to store database pages associated with currently active transactions; and code for performing the stop redo procedure when the estimate is determined to conform with specified constraint.
48. The computer program product as claimed in claim 45 wherein the code for halting further includes receiving a special connect request message from a management workstation.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002422176A CA2422176C (en) | 2003-03-14 | 2003-03-14 | Method and apparatus for interrupting updates to a database to provide read-only access |
| US10/752,026 US7107294B2 (en) | 2003-03-14 | 2004-01-07 | Method and apparatus for interrupting updates to a database to provide read-only access |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002422176A CA2422176C (en) | 2003-03-14 | 2003-03-14 | Method and apparatus for interrupting updates to a database to provide read-only access |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2422176A1 CA2422176A1 (en) | 2004-09-14 |
| CA2422176C true CA2422176C (en) | 2009-07-21 |
Family
ID=32932266
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002422176A Expired - Lifetime CA2422176C (en) | 2003-03-14 | 2003-03-14 | Method and apparatus for interrupting updates to a database to provide read-only access |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7107294B2 (en) |
| CA (1) | CA2422176C (en) |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050160087A1 (en) * | 2002-08-29 | 2005-07-21 | Fujitsu Limited | Data extractor and method of data extraction |
| CA2433254A1 (en) * | 2003-06-25 | 2004-12-25 | Ibm Canada Limited - Ibm Canada Limitee | System and method for warm shutdown and restart of a buffer pool |
| US7552171B2 (en) * | 2003-08-14 | 2009-06-23 | Oracle International Corporation | Incremental run-time session balancing in a multi-node system |
| US7441033B2 (en) * | 2003-08-14 | 2008-10-21 | Oracle International Corporation | On demand node and server instance allocation and de-allocation |
| CN100547583C (en) * | 2003-08-14 | 2009-10-07 | 甲骨文国际公司 | Database automatically and the method that dynamically provides |
| US7516221B2 (en) * | 2003-08-14 | 2009-04-07 | Oracle International Corporation | Hierarchical management of the dynamic allocation of resources in a multi-node system |
| US7266711B2 (en) * | 2003-11-17 | 2007-09-04 | Intel Corporation | System for storing data within a raid system indicating a change in configuration during a suspend mode of a device connected to the raid system |
| US7188375B2 (en) * | 2004-06-21 | 2007-03-13 | Norman Richard Harrington | Infant protective head covering |
| US20060010130A1 (en) * | 2004-07-09 | 2006-01-12 | Avraham Leff | Method and apparatus for synchronizing client transactions executed by an autonomous client |
| US7502824B2 (en) * | 2004-08-12 | 2009-03-10 | Oracle International Corporation | Database shutdown with session migration |
| US7415470B2 (en) * | 2004-08-12 | 2008-08-19 | Oracle International Corporation | Capturing and re-creating the state of a queue when migrating a session |
| US9176772B2 (en) * | 2005-02-11 | 2015-11-03 | Oracle International Corporation | Suspending and resuming of sessions |
| US8112394B2 (en) * | 2005-10-14 | 2012-02-07 | Oracle International Corporation | Long-lived data transactions |
| US7681133B2 (en) * | 2005-10-14 | 2010-03-16 | Oracle International Corporation | Declarative task-based user interfaces |
| US8296727B2 (en) | 2005-10-14 | 2012-10-23 | Oracle Corporation | Sub-task mechanism for development of task-based user interfaces |
| US8423564B1 (en) * | 2006-10-31 | 2013-04-16 | Ncr Corporation | Methods and apparatus for managing and updating stored information |
| US20080142249A1 (en) * | 2006-12-13 | 2008-06-19 | International Business Machines Corporation | Selective surface roughness for high speed signaling |
| US8069141B2 (en) * | 2007-03-12 | 2011-11-29 | Microsoft Corporation | Interfaces for high availability systems and log shipping |
| US8671076B2 (en) * | 2007-05-08 | 2014-03-11 | Bmc Software, Inc. | Database recovery using logs applied to consistent copies |
| US7899794B2 (en) * | 2008-03-20 | 2011-03-01 | Sybase, Inc. | Optimizing lock acquisition on transaction logs |
| US7882173B2 (en) * | 2008-06-30 | 2011-02-01 | International Business Machines Corporation | Interactive remote command execution over a stateless client/server network protocol |
| US8433680B2 (en) | 2008-07-01 | 2013-04-30 | Oracle International Corporation | Capturing and restoring database session state |
| US8209603B2 (en) * | 2009-04-29 | 2012-06-26 | Microsoft Corporation | Maintaining undo and redo capability across metadata merges |
| JP5377175B2 (en) * | 2009-09-08 | 2013-12-25 | 株式会社東芝 | Controller and data storage device |
| US9053231B2 (en) * | 2010-06-07 | 2015-06-09 | Salesforce.Com, Inc. | Systems and methods for analyzing operations in a multi-tenant database system environment |
| US10733151B2 (en) | 2011-10-27 | 2020-08-04 | Microsoft Technology Licensing, Llc | Techniques to share media files |
| US9053079B2 (en) * | 2011-12-12 | 2015-06-09 | Microsoft Technology Licensing, Llc | Techniques to manage collaborative documents |
| US9672237B2 (en) * | 2013-03-15 | 2017-06-06 | Amazon Technologies, Inc. | System-wide checkpoint avoidance for distributed database systems |
| JP6401866B2 (en) * | 2014-12-24 | 2018-10-10 | 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． | Transaction processing method and apparatus, and computer system |
| US9952933B1 (en) * | 2014-12-31 | 2018-04-24 | Veritas Technologies Llc | Fingerprint change during data operations |
| US10002082B2 (en) * | 2016-02-19 | 2018-06-19 | Ford Global Technologies, Llc | Method and apparatus for cyclical key-off file replacement |
| US10303678B2 (en) * | 2016-06-29 | 2019-05-28 | International Business Machines Corporation | Application resiliency management using a database driver |
| US10387275B2 (en) | 2016-07-26 | 2019-08-20 | Hewlett Packard Enterprise Development Lp | Resume host access based on transaction logs |
| CN109144994B (en) | 2017-06-19 | 2022-04-29 | 华为技术有限公司 | Index updating method, system and related device |
| US20190102401A1 (en) | 2017-09-29 | 2019-04-04 | Oracle International Corporation | Session state tracking |
| US11936739B2 (en) | 2019-09-12 | 2024-03-19 | Oracle International Corporation | Automated reset of session state |
| US11435930B2 (en) * | 2020-09-17 | 2022-09-06 | EMC IP Holding Company LLC | Intelligent recovery from multiple clouds copies |
| CN113741938A (en) * | 2021-09-06 | 2021-12-03 | 联想(北京)有限公司 | Updating method and electronic equipment |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69126067T2 (en) * | 1990-06-29 | 1997-10-02 | Oracle Corp | Method and device for managing condition identifiers for efficient recovery |
| DE69126066T2 (en) * | 1990-06-29 | 1997-09-25 | Oracle Corp | Method and device for optimizing logbook usage |
| JPH0827755B2 (en) * | 1991-02-15 | 1996-03-21 | インターナショナル・ビジネス・マシーンズ・コーポレイション | How to access data units at high speed |
| US5317731A (en) * | 1991-02-25 | 1994-05-31 | International Business Machines Corporation | Intelligent page store for concurrent and consistent access to a database by a transaction processor and a query processor |
| US5287501A (en) * | 1991-07-11 | 1994-02-15 | Digital Equipment Corporation | Multilevel transaction recovery in a database system which loss parent transaction undo operation upon commit of child transaction |
| US5495601A (en) * | 1992-12-11 | 1996-02-27 | International Business Machines Corporation | Method to off-load host-based DBMS predicate evaluation to a disk controller |
| US5455944A (en) * | 1993-03-16 | 1995-10-03 | International Business Machines Corporation | Method for managing logging and locking of page free space information in a transaction processing system |
| US5455946A (en) * | 1993-05-21 | 1995-10-03 | International Business Machines Corporation | Method and means for archiving modifiable pages in a log based transaction management system |
| GB2281644A (en) * | 1993-09-02 | 1995-03-08 | Ibm | Fault tolerant transaction-oriented data processing. |
| US5850507A (en) * | 1996-03-19 | 1998-12-15 | Oracle Corporation | Method and apparatus for improved transaction recovery |
| US6092066A (en) * | 1996-05-31 | 2000-07-18 | Emc Corporation | Method and apparatus for independent operation of a remote data facility |
| US5845292A (en) * | 1996-12-16 | 1998-12-01 | Lucent Technologies Inc. | System and method for restoring a distributed checkpointed database |
| US6205449B1 (en) * | 1998-03-20 | 2001-03-20 | Lucent Technologies, Inc. | System and method for providing hot spare redundancy and recovery for a very large database management system |
| US6226651B1 (en) * | 1998-03-27 | 2001-05-01 | International Business Machines Corporation | Database disaster remote site recovery |
| US6295610B1 (en) * | 1998-09-17 | 2001-09-25 | Oracle Corporation | Recovering resources in parallel |
| CA2302981C (en) * | 2000-03-29 | 2004-06-01 | Ibm Canada Limited-Ibm Canada Limitee | Online database table reorganization |
| US6567928B1 (en) * | 2000-05-23 | 2003-05-20 | International Business Machines Corporation | Method and apparatus for efficiently recovering from a failure in a database that includes unlogged objects |
| US6651073B1 (en) * | 2000-05-23 | 2003-11-18 | International Business Machines Corporation | Method and apparatus for insuring database data integrity without data recovery logging |
| KR100390853B1 (en) * | 2000-06-07 | 2003-07-10 | 차상균 | A Logging Method and System for Highly Parallel Recovery Operation in Main-Memory Transaction Processing Systems |
| US7031974B1 (en) * | 2002-08-01 | 2006-04-18 | Oracle International Corporation | Replicating DDL changes using streams |
| US6976022B2 (en) * | 2002-09-16 | 2005-12-13 | Oracle International Corporation | Method and mechanism for batch processing transaction logging records |
| US6981004B2 (en) * | 2002-09-16 | 2005-12-27 | Oracle International Corporation | Method and mechanism for implementing in-memory transaction logging records |
-
2003
- 2003-03-14 CA CA002422176A patent/CA2422176C/en not_active Expired - Lifetime
-
2004
- 2004-01-07 US US10/752,026 patent/US7107294B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20040181560A1 (en) | 2004-09-16 |
| CA2422176A1 (en) | 2004-09-14 |
| US7107294B2 (en) | 2006-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2422176C (en) | Method and apparatus for interrupting updates to a database to provide read-only access | |
| US6185699B1 (en) | Method and apparatus providing system availability during DBMS restart recovery | |
| US5561795A (en) | Method and apparatus for audit trail logging and data base recovery | |
| EP1618475B1 (en) | Flashback database | |
| US6578041B1 (en) | High speed on-line backup when using logical log operations | |
| US5724581A (en) | Data base management system for recovering from an abnormal condition | |
| JP4321705B2 (en) | Apparatus and storage system for controlling acquisition of snapshot | |
| US5884328A (en) | System and method for sychronizing a large database and its replica | |
| JP4324616B2 (en) | Data processing method in storage system | |
| JP5021929B2 (en) | Computer system, storage system, management computer, and backup management method | |
| US7349927B2 (en) | Transactional file system for realizing atomic update of plural files by transactions | |
| US7398422B2 (en) | Method and apparatus for data recovery system using storage based journaling | |
| US6938056B2 (en) | System and method for restoring a file system from backups in the presence of deletions | |
| US6732123B1 (en) | Database recovery to any point in time in an online environment utilizing disaster recovery technology | |
| EP0501180A2 (en) | Dynamic, finite versioning for concurrent transaction and query processing | |
| US20060224639A1 (en) | Backup system, program and backup method | |
| US20050262170A1 (en) | Real-time apply mechanism in standby database environments | |
| JPH06318165A (en) | Method for making data available in transaction adaptive system in restart after trouble | |
| JPH0823841B2 (en) | Data processing system and method | |
| CA2504322A1 (en) | Apparatus and method for hardware-based file system | |
| JPH0812631B2 (en) | Database transaction and query processing system | |
| US7225206B2 (en) | System and method for reorganizing stored data | |
| JP2003242010A (en) | Optimizing log usage for temporary object | |
| JPH09244933A (en) | Method and device for backing up data base | |
| Lomet | High speed on-line backup when using logical log operations |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20230314 |
|
| MKEX | Expiry |
Effective date: 20230314 |