Browse Prior Art Database

A system and method to provide database service with minimal inaccessible time during crash recovery

IP.com Disclosure Number: IPCOM000239362D
Publication Date: 2014-Nov-03
Document File: 5 page(s) / 172K

Publishing Venue

The IP.com Prior Art Database

Abstract

This invention proposed to a new way for database recovery, which generates a new type of lock – R-lock in the flight to protect necessary database objects and gets database available with minimal freezing time.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 01 of 5

A system and method to provide database service with minimal inaccessible time during crash recovery

Currently in all the DBMS , when a crash occurs before changes in a transaction are completed and written to disk , the database would be left in an inconsistent andunusable state. Crash recovery is the process by which the database is moved back to a consistent state. This is done by rolling back incomplete transactions and completing committed transactions that were still in memory when the crash occurred .

To prevent the in-flight data being accessed, the DBMS will not accept any connection from the application until it has completed crash recovery, which means the database

will be in unusable state during this phase. The time of the unusable is determined by the amount of the in-flight data which needs to be processed, it could be seconds, minutes, hours, or even days in some situations which have very long transactions involved in the crash recovery. The chart below demonstrated the data availability during the traditional crash recovery.

Figure 1 Data Availability During Traditional Crash Recovery

t1 is the point of the time that crash recovery finished . We can see that all the data is unavailable before the crash recovery finished and this could bea big pain point of many

users. However actually, in most of the situations the amount of the in -flight data is only a small part of the whole database .

Current database commonly resumes to provide database service until the end of transaction recovery completed. It takes much time to finish the recovery if there are many in-flight transactions.

So far, we haven't found any sound solutions to open database service promptly upon the database failure which needs to recover many in-flight transactions.

This invention proposed to a new way for database recovery, which generates a new type of lock - R-lock in the flight to protect necessary database objects and gets database available with minimal freezing time. It works in the following way:

1



Page 02 of 5


1. When the database enters recovery state due to crash, log is scanned to extract all object id information, and build up R-lock list in memory. Each of the R-lock consists of object id and the counter of how many transactions have updated this object. This scan could be extreme fast as only quite a few data needs to be extracted from log files.


2. Open database to provide service. Application is allowed to connect database to do transactions. But the transactions are not allowed to touch database objects which are protected by R-lock. When an object is to be accessed/updated, the R-lock list would be checked, If there is R-lock on that object, the transaction would be rejected.


3. Database recovery process keeps running at the same time. Whenever one transaction is recovered, the R-lock counter on the database object which the transaction affects will be decreased by 1. If the counter is equal to 0, the R-lock will be removed f...