WO2014061847A1

WO2014061847A1 - Apparatus and method for logging and recovering transaction of database built in mobile environment

Info

Publication number: WO2014061847A1
Application number: PCT/KR2012/008714
Authority: WO
Inventors: 김신유; 한혁; 진성일; 김재광
Original assignee: 주식회사 리얼타임테크
Priority date: 2012-10-17
Filing date: 2012-10-23
Publication date: 2014-04-24
Also published as: KR20140049327A; KR101419428B1

Abstract

The present invention relates to an apparatus and a method for logging and recovering a transaction of a database which can increase the efficiency in terms of processing speed according to logging and storage capacity, when processing a complex transaction due to a large-scale database change in a mobile environment with limited computing resources.

Description

【Specification】

[Name of invention]

Transaction logging and recovery device for database built in mobile environment, and its method

Technical Field

The present invention relates to a logging and recovery technique that satisfies the ACIlXAtomicity, Consistency, Isolation, Durability attributes of a transaction in a Database Management System (DBMS). The present invention relates to a transaction logging and recovery device for a database and a method thereof for improving efficiency in terms of processing speed and storage capacity when logging a complex transaction composed of changes.

Background technology

Write-Ahead Logging (WAL) is a transaction logging that writes REDO and UNDO information to the log before reflecting the changes to the source database when a database modification occurs by the transaction to satisfy the ACID attribute of the transaction. And recovery method.

However, according to the conventional logging method, in the case of a large-volume complex transaction consisting of tens of thousands of database change operations, the log file is stored in the changed case code unit along with LSN Log Sequence Number) information for each database change operation. The number of I / Os is very frequent and large storage space is consumed.

Most mobile devices, on the other hand, use flash memory as their primary storage medium. Frequent file I / Os can reduce flash memory life and reduce performance.

In addition, the conventional logging method adopts a random recording method, and the flash memory used in the mobile device has a very slow performance compared to the sequential recording method, which degrades the overall performance.

[Detailed Description of the Invention]

The present invention has been made to solve the above problems, by using the hash data structure and LRU algorithm to log the change transaction of the database to minimize the file I / O on the mobile terminal to prevent shortening the life of flash memory In order to compensate for the performance degradation caused by the random recording method by introducing a sequential recording method, and to manage only the last page image, the database built in the mobile environment can be used efficiently. The purpose of the present invention is to provide an apparatus and method for transaction logging and recovery. ·

In order to achieve the above object, a transaction logging and recovery device for a database built in a mobile environment according to the present invention, the database file is stored in a storage medium; A log file stored in a storage medium; A database file manager for controlling the database file using a page identifier; A log file manager controlling the log file using LSN information; Has a hash data structure that manages information about changed pages, controls access to or changes to pages that have already been changed through the log buffer manager, and access to unchanged pages through the database file manager. Is a hash manager; And a log buffer for managing some of the pages of the log file on main memory, and performing the targeting on the log buffer for access to a page that has already been changed or for page change. A log buffer manager for performing page replacement with the log file if not present; And all the pages stored in the log file using the hash data structure are controlled to record all the pages not written to the log file among the pages in the log buffer, for the Commit request from the upper models. And a recovery manager that reads and controls the data to be sequentially written to the database file, and records the state of the database file in a predetermined area.

In order to achieve the above object, a transaction logging and recovery device for a database built in a mobile environment according to the present invention, the database file is stored in a storage medium; A log file stored in a storage medium; A database file manager for controlling the database file using a page identifier; A log file manager controlling the log file using LSN information; For a Write request from a parent model, if the page is not registered in the hash data structure, the page identifier of the page and the LSN information generated by the log buffer manager are registered in the hash data structure, and the page writes to the log buffer manager. A hash manager that makes a request to write the page to the log buffer manager using the registered information if a request is made; For a write request from the hash manager, if the same page as the page exists in the log buffer, the page is written to the corresponding page, and if not, the target page is selected by a least recently used (LRU) page replacement algorithm. A log buffer manager that makes a Write request and writes the page to the log buffer; And controlling all the pages not recorded in the log file among the pages in the log buffer for the Commit request from the upper mode, and reading all the pages stored in the log file by using the hash data structure. And a recovery manager which controls to record sequentially to the database file, and records the state that has been completely progressed to the present in the predetermined area of the database file.

In the transaction logging and recovery device for a database built in a mobile environment, the hash manager requests a read request of the page to the log buffer manager if the page is registered in the hash data structure for a read request from the parent. If it is not registered, the database file manager requests a read request of the page, and the log buffer manager reads the page from the log buffer for a read request from the hash manager, If there is no identical page, the LRU page replacement algorithm replaces the same page in the log file.

In the transaction logging and recovery device for a database built in a mobile environment, the hash data structure is a hash function consisting of a MOD operation that uses a page identifier as an input value, and specifies a starting position of a bucket corresponding to the hash key. And a bucket block including a hash table, which is a list set of hash nodes, and a page identifier and LSN information as components of a bucket. Transaction logging and recovery for databases deployed in mobile environments Wherein the log buffer manager comprises: a hash table for configuring a hash chain to access the log buffer; And a buffer control block including a hash chain for searching for a page corresponding to a page identifier, an LRU chain for an LRU page replacement algorithm, and a page pointer pointing to a corresponding page in a log buffer.

In the transaction logging and recovery device for a database built in a mobile environment, the log buffer manager generates LSN information in a sequential manner when the LSN information for a page selected as a target page is not yet set. The write request is made to the log file manager. In a transaction logging and recovery device for a database built in a mobile environment, the recovery manager, when booted after a system error, has progressed to the present state recorded in a predetermined area of the database file. Data ", and reads all pages stored in the log file and writes them to the database file, and initializes the log file when" transaction start "or" migration commit complete ".

In order to achieve the above objects, a transaction logging and recovery method for a database constructed in a mobile environment according to the present invention includes: (a) For a write request from a higher model, the page is not registered in the hash data structure. If the page identifier and LSN information is registered in the hash data structure, and the corresponding page is written to the log buffer, but the target page selected by the L _^ RULeast recently used page replacement algorithm is recorded in the log file; (b) For a Write request from a higher model, if the page is registered in the hash data structure, if the same page as the page exists in the log buffer, write to the page at that location; otherwise, replace the LRU page. Writing a target page selected by an algorithm to the log file and writing the page to the log buffer; (c) recording all pages not written in the log file among pages in the log buffer, for a Commit request from higher parents, and recording the state of the present so far in a predetermined area of the database file; And reading all the pages stored in the log file using the hash data structure and sequentially recording the pages in the database file, and recording the state of the database file up to now in a predetermined area of the database file.

In the transaction logging and leaning method for a database built in a mobile environment, in the case of a read request from (al) higher parents before step (c), the page is not included in the hash data structure. Reading a corresponding page from the database file; And (bl) for a Read request from higher parents, if the page is registered in the hash data structure, the page is read from the log buffer, and if the log buffer does not have the same page as the page, the LRU page is replaced. And replacing the same page as the corresponding page in the log file by the algorithm.

In the transaction logging and recovery method for a database built in a mobile environment, the hash data structure is a hash function consisting of a MOD operation that uses a page identifier as an input value, and specifies a starting position of a bucket for a hash key. And a bucket block including a hash table, which is a list set of hash nodes, and a page identifier and LSN information as components of a bucket. A transaction logging and recovery method for a database built in a mobile environment, the method comprising: a hash table for constructing a hash chain as a data structure for accessing the log buffer; And a buffer control block comprising a hash chain for searching for a page corresponding to a page identifier, an LRU chain for an LRU page replacement algorithm, and a page pointer pointing to a corresponding page in a log buffer.

In the transaction logging and recovery method for a database built in a mobile environment, step (a) is characterized in that the LSN information for the page selected as the target page is generated in a sequential manner.

In the method of logging and recovering a transaction for a database built in a mobile environment, (d) when the system progresses to the present state recorded in a predetermined area of the database file at boot time after the system error condition is "log commit completed". And reading all the pages stored in the log file and writing them to the database file, and initializing the log file in the case of "transaction start" or "migration commit completed".

[Brief Description of Drawings]

1 illustrates the overall configuration of a transaction logging and recovery device for a database constructed in a mobile environment according to the present invention.

2 illustrates a hash data structure used by a hash manager according to the present invention;

3 shows a data structure for a log buffer manager according to the present invention to access a log buffer.

4 is for explaining a Commit step in the course of performing a transaction,

5 is a view illustrating a method of ensuring data consistency in a system error situation in a transaction logging and recovery method for a database constructed in a mobile environment according to the present invention.

EXAMPLE

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

1, a preferred embodiment of a transaction logging and recovery device for a database built in a mobile environment includes a database file 20, a log file 30, a database file manager 40, a log file manager 50, A hash manager 60, a log buffer manager 70, and a recovery manager 80.

Here, the mobile environment refers to an environment provided by a device that guarantees mobility, and is provided by various mobile terminals, including smart phones, navigation terminals, personal digital assistants (PDAs), and the like. It should be interpreted broadly.

The database file 20 and the log file 30, which are components of the present invention, are passive components, respectively, and are stored in a storage medium separate from the main memory. The storage medium used in the present invention is preferably implemented as a flash memory, but is not necessarily limited thereto.

The database file manager 40, the log file manager 50, the hash manager 60, the log buffer manager 70, and the recovery manager 80, which are components of the present invention, respectively, provide an information processing apparatus provided to a mobile environment. It is an active component that can be implemented as a complex of various hardware and software, which are described below. It is defined by the functional features it provides.

The database file manager 40 manages the database file 20 and provides a control interface to the recovery manager 80. The database file manager 40 performs the overall file control function for the database file 20 using the page identifier (ID). Where the page identifier (ID) is implemented including the file number, page size, and page number for the database file, the file number is the identification number of the database file, the page size is the page size of the database file, and the page The number represents the number of the page in the database file. Therefore, the physical offset (= page size * page number) in the database file 20 of the page can be calculated by the page identifier.

The log file manager 50 manages the log file 30 and provides a control interface to the rare manager 80. The log file manager 50 performs an overall file control function for the log file 30 by using LSNCLog Sequence Number information. Where LSN information is implemented including the file number, LSN size, and LSN number for the log file, the file number is the log file's identification number, the LSN size is the log file's page size, and the LSN number is the log file. Indicates the page number. Therefore, the physical offset (= LSN size * LSN number) in the log file 30 of the corresponding page can be calculated by the LSN identifier.

The hash manager 60 manages the information about the changed page in the hash data structure 62, and provides the recovery manager 80 with a control interface. In FIG. 1, the hash data structure 62 is shown as an external configuration of the hash manager 60, but it is obvious that the hash data structure 62 may also be set as an internal configuration of the hash manager 60. As shown in FIG.

When a read request for a page corresponding to a specific page ID is received from the parent model 10, the hash manager 60 detects whether the requested page ID exists in the hash data structure 62, and if so, the log buffer manager. The page read request is made to (70). If not, the page read request is made to the database file manager (40).

When a write request of a page corresponding to a specific page ID is received from the upper modules 10, the hash manager 60 registers the page ID and LSN information in the hash data structure 62, and the log buffer manager 70 I perform the requested page Write ¾ · ^'. Therefore, according to the present invention, all write operations occurring during the execution of the transaction are excluded from the database file 20 and are written only to the log file 30. In addition, duplicate page IDs are not registered when a page ID is registered in the hash when a write request is made using the characteristics of the hash. Therefore, only the last page image is managed, thus saving storage space. In addition, the hash manager 60 manages the logs recorded by sorting the page IDs registered in the hash data structure 62 to reflect the information logged in the log file 30 in the original database file 20 ( When migrating, you can use the sequential recording method.

The log buffer manager 70 includes a log buffer 72 to cache the changed page image and provide a control interface to the hash manager 60 and the recovery manager 80. That is, the log buffer manager 70 stores some of the page images to be stored in the log file 30 in order to minimize file I / O. Cache function is performed on (Log buffer). Although the log buffer 72 is shown as an external configuration of the log buffer manager 70 in FIG. 1, it is obvious that the log buffer 72 may also be set as an internal configuration of the log buffer manager 70.

When a read or write request is received from the hash manager 60, the log buffer manager 70 means that the same page as the corresponding page (not the page content but the page ID is the same in the log buffer 72), even in the following description. If there is, read or write the page at the location, if not, select the target page (Victim) by LRU Least recently used) page replacement algorithm and request Read or Write to the log file manager 50. do. In particular, when the log buffer manager 70 makes a write request to the log file manager 50, when the LSN information of the page selected as Victim in the hash data structure is initialized, logging is performed by generating sequential LSN information. Sequential recording can also be used. The LSN information generated by the log file manager 50 is reflected in the hash data structure 62 in which an initialization value is set when it is registered, and is then used when the page is recorded again in the log file 30.

The recovery manager 80 collectively manages the database file manager 40, the log file manager 50, the hash manager 60, and the log buffer manager 70, and performs a system error situation (operating system down, When the database management system is restarted due to power down, user program down, etc.), it plays a role of ensuring the consistency of the original database file 20. In addition, the recovery manager 80 hides the four managers from view in the upper module 10 and serves as an interface to the upper modules 10. Among the interfaces, the APKApplication Program Interface for Commit, in particular, defines Commit in two stages: LogCommit and MigrationCommit. In FIG. 1, the recovery manager 80 includes a database file manager 40, a log file manager 50, a hash manager 60, and a log buffer manager 70 therein. Of course, it is meant to emphasize functionality and may actually be implemented as separate modules.

Accordingly, the recovery manager 80 controls to log all the pages in the log buffer that are not written to the log file 30 for the Commit request from the upper module 10 (LogCommit), Using the hash data structure 62, all pages stored in the log file 30 are read and sequentially recorded in the database file 20 (MigrationCommit), and a predetermined area of the database file 20 is read. Record the complete progress to date.

2 illustrates a hash data structure 62 used by the hash manager 60 according to the present invention.

The hash data structure 62 used in the present invention is composed of a hash function, a hash table 64 and a bucket block 66. Hash table 64 is a set of hash nodes that specify the starting position of the bucket against the hash key. Bucket block 66 is a means to avoid the hash stratification that occurs when having the same hash function value for different input values, a number of buckets (68) connected by the pointer of the hash node (68) ).

The input value of the hash function used by the hash manager 60 is a page ID, and the hash function may be implemented by a mod operation.

The components of bucket 68 that are stored in bucket block 66 are page ID and LSN definitions. show. The page ID is an ID managed by the upper models 10 and is a value transmitted through the interface of the recovery manager 80 and has information for accessing the database file 20. The LSN information is an ID generated by the log buffer manager 70 and has information for accessing the log file 30. These IDs can be used to calculate the physical location where the page is stored on the storage medium during read or write.

Since the hash manager 60 does not allow duplicate values for the page ID during the insert operation, only the last version of the page image can be managed. Therefore, in the present invention, the storage space for logging can be efficiently used.

At the time of Commit, pages corresponding to all page IDs registered in the hash data structure (62) are changed pages immediately. After logging is completed (LogCommit), all changed pages are recorded as the image of the last version. Will be. Therefore, if all buckets registered in the hash data structure (62) are sorted in page ID order and used during migration, the effect of sequentially recording can be obtained.

3 shows a data structure for log buffer manager 70 to access log buffer 72.

The data structure managed by the log buffer manager 70 includes a log buffer 72, a buffer control block 74, and a hash table 76.

Log buffer 72 is a space in main memory where pages to be actually cached are stored.

The buffer control block 74 includes a hash chain 741 for quickly retrieving a page corresponding to a page ID, an LRU chain 743 for an LRU-based page replacement algorithm, and a page pointer pointing to a corresponding page in a log buffer. 745). The hash chain 741 and the LRU chain 743 are each composed of pointers pointing from one buffer control block to another.

Hash table 76 is a table for constructing hash chain 741.

Here, the hash chain 741 is updated when the target page is selected by the LRU page replacement algorithm.

The LRU chain 743 is updated on every read or write. At this time, the LRU chain 743 is updated so that the buffer control block 74 indicating the recently accessed page is located at the top, and the page indicated by the buffer control block 74 located at the bottom is selected as the target page (Victim). do.

Hereinafter, referring to FIGS. 1 to 3, the logging equivalent according to the present invention will be described in detail.

In the case of a transaction performed in a database built on a mobile terminal such as a navigation system, tens of thousands of reads or writes may be combined in one transaction. The present invention can be usefully applied in such an environment.

If there is a Write request from the upper models 10, it is executed as follows.

The hash manager 60 generates a page identifier of the page and the log buffer manager 70 if the page is not registered in the hash data structure 62 through a search (a) on the hash data structure 62. LSN Information Hash Data Structures (62) (B), and write request of the page to the log buffer manager 70. (In the initial registration, the hash information of the page in the hash data structure 62 has an initialized value. When the page is selected as Victim and written to the log file 30, it is updated with the LSN information generated by the log buffer manager 70). Subsequently, the log buffer manager 70 records the corresponding page in the log buffer 72 (c), and selects a target page using a least recently used (LRU) page replacement algorithm to select a log page manager (50). ), The log file manager 50 writes the write requested page to the log file 30 (d).

When the log buffer manager 70 makes a write request to the log file manager 50, when the LSN information of the page selected as Victim in the hash data structure 62 is an initialized value, the log buffer manager 70 sequentially LSN information is generated. The LSN information generated by the log file manager 50 is reflected in the hash data structure 62 in which an initialization value is set when it is registered, and is then used when writing the corresponding page back to the log file 30.

The hash manager 60, through the search (a) of the hash data structure 62, if the page is registered in the hash data structure 62, corresponds to the log buffer manager 70 using the registered information. Write request of the page. Thereafter, if the log buffer 72 has the same page as the page in the log buffer 72, the log buffer manager 70 selects the target page by the LRU page replacement algorithm. Write to the log file manager 50 and write the page to the log buffer 72 (d). The log file manager 50 writes the write requested page to the log file 30.

If there is a Read request from the upper models 10, it is executed as follows.

Hash manager 60, via search (a) on hash data structure 62, requests a page that has not been changed in the hash data structure 62 (i.e., has not changed in a transaction). The read request of the page to the database file manager 40 (e).

Hash manager (60) performs a search (a) on hash data structure (62), if the page is registered in hash data structure (62) (i.e. if the page has already changed more than once in a transaction). Read request of the page to the log buffer manager (70). Log buffer manager 70 reads the page from log buffer 72

(f) If the log buffer 72 does not have the same page as the page, the LRU page replacement algorithm replaces the same page in the log file 30 with the page.

(g).

Referring to FIG. 4, the Commit step in the process of executing a transaction is performed as follows.

First, in the transaction start phase, the hash data structure 62 and the log buffer 72 managed by the recovery manager are initialized, and the transaction status is stored in a specific area (header page) of the original database file 20. Write as "Start transaction" (S100), and perform a flush (Sync) operation so that the buffered portion is completely written to the file at the system level.

Subsequently, in the DMLCdata manipulation language) Query step, the logging operation such as «]-is performed.

Finally, the Commit phase is phase 2 (LogCommit phase and MigrationCommit phase). Step).

Step 1 is the LogCommit step, which writes changed pages that have been used by the upper parents (10) and have not yet been saved (SI 10), and are not recorded in the log file 30 among the pages in the log buffer 72. All logging operations are completed only when all pages (which can be distinguished from pages which have not been used by using the Dirty bit or are already recorded in the log file 30) are recorded (S120).

However, because of the system-wide file caching technique, there is still no guarantee that the file will be written completely. Therefore, the system flushes the buffered part to the file completely. In the specified area (header page) of the original database file 20, the transaction status ("log commit completed") that has been completed so far is recorded (S130), and Flush (Sync) operation is performed once again.

Step 2 is the MigrationCommit step, which uses a hash data structure (more precisely, a log written by sorting the hash data structure (62)) to read pages from the log file (30) and convert them to the original database file (20). Migrate them (S140). After that, execute Flush (Sync) operation so that the original database file is completely recorded. In the specified area (header page) of the original database file 20, the state of progress ("Migration commit completed") that has been completed so far is recorded (S150), and Flush (Sync) is performed once again.

If so far, the transaction has completed successfully.

The rollback operation does not change the original database file (20), so you only need to clean up the log file (30) that has been recorded. In addition, since there may be modified pages cached in the upper models 10, all cached pages used in the upper modules 10 should be cleaned up. Referring to FIG. 5, a method of ensuring data consistency in a system error situation (operating system down, power down, application down, etc.) will be described below.

By recording the last state value of the transaction in the header page of the original database file 10, it is possible to guarantee the consistency of data in the event of a system error. If an error occurs after the successful start of the transaction but before the first phase commit is complete (if the last status of the transaction is "Start transaction") (S200), the utility informs the master that the previous transaction was back at reboot. After cleaning up the log file 30 (S240), the normal booting process is continued (S250).

If an error occurs after the transaction has been successfully completed by two-phase commit and completed normally (if the last status of the transaction is "Migration commit completed") (S210), all log files (30) are cleaned up on reboot. After (S240), you can continue the normal booting process (S250).

On the contrary, if the first stage commit is completed and an error occurs during the second stage migration (when the final status value of the transaction is "log commit completed") (S220), the migration is performed again on reboot. After (S230), to clean up all log files (30) (S240), the normal booting process continues (S250). 【Industrial Availability】

As described above, according to the present invention, the DBMS can efficiently use the storage space for logging when performing transactions in the DBMS, minimize file I / O, and improve performance by sequentially recording when writing to a file. Can be.

In particular, on a mobile terminal, minimizing file I / O not only improves performance but also prevents shortening the life of flash memory.

Claims

[Claim]

[Claim 1]

A database file stored in a storage medium;

A log file stored in a storage medium;

A database file manager for controlling the database file using a page identifier;

A log file manager controlling the log file using LSN information; Has a hash data structure to manage information about changed pages, controls access to or changes to pages that have already been changed through the log buffer manager, and access to unchanged pages through the database file manager. A hash manager;

And a log buffer for managing some of the pages of the log file on main memory, and performing the targeting on the log buffer in response to a page change or an access to a page which has already been changed. A log buffer manager for performing page replacement of the log file with a least recently used (LRU) method if not present; And

In response to a Commit request from upper layers, control to record all pages not written to the log file among pages in the log buffer, and read all pages stored in the log file using the hash data structure to read the database. And a recovery manager that controls to record sequentially to a file and records the state of the database in a predetermined area of the database file. .

[Claim 2]

A database file stored in a storage medium;

A log file stored in a storage medium;

A log file manager controlling the log file using LSN information; For a write request from a parent model, if the page is not registered in the hash data structure, the page identifier of the page and the LSN information generated by the log buffer manager are registered in the hash data structure, and the page writes to the log buffer manager. A hash manager that makes a request to write a corresponding page to the log buffer manager using the registered information if the request is registered;

For a write request from the hash manager, if the same page as the page exists in the log buffer, the page is written to the page, and if not, the target page is selected by the page replacement algorithm and written to the log file manager. A log buffer manager that makes requests and writes those pages to the log buffer; And

In response to a Commit request from a higher model, control to record all pages not written to the log file among pages in the log buffer, and read all pages stored in the log file using the hash data structure to read the database. And a recovery manager which controls to write sequentially to the file, and records the state of the state which has been completely progressed up to now in a predetermined area of the database file.

Echo waves for transaction logging and recovery.

【Hagi Jack Station Claim 3】

Solidified Essence

The hash manager of claim 2, wherein the hash manager is

For a read request from the parent model, if the page is registered in the hash data structure, the read request of the page is made to the log buffer manager. If not, the read request of the page is made to the database file manager.

The log buffer manager

For a Read request from the hash manager, if a corresponding page is read from the log buffer and there is no same page as the corresponding page in the log buffer, the same page as the corresponding page is replaced in the log file by an LRU page replacement algorithm. Transaction logging and recovery device for a database built in a mobile environment.

[Claim 4]

4. The hash data structure of claim 2 or 3, wherein the hash data structure

A hash function consisting of a MOD operation that uses a page identifier as input,

A hash table that is a list of hash nodes that specify the starting position of the bucket against the hash key;

A transaction logging and retrieval device for a database built in a mobile environment, comprising a bucket block having page identifiers and LSN information as components of a bucket.

[Claim 5]

According to claim 2 or 3, wherein the log buffer manager to access the log buffer,

A hash table for hash chain construction; And

And a buffer control block comprising a hash chain for retrieving a page corresponding to a page identifier, an LRU chain for an LRU page replacement algorithm, and a page pointer pointing to a corresponding page in a log buffer. Logging and retrieval device for partitioned databases.

[Claim 6]

The method according to claim 12 or 3, wherein the log buffer manager

If the LSN information for the page selected as the target page is not yet set, transaction logging for the database built in the mobile environment, which generates the LSN information in a sequential manner and writes to the log file manager And recovery device.

[Claim 7]

The method of claim 2 or 3, wherein the recovery manager

Upon booting after a system error condition, if the progress to the predetermined recorded present time of the database file is "log commit completed", the "start transaction" to read all the pages stored in the log and write them to the database file. Device for logging and recovery for a database built in a mobile environment, characterized in that said log file when "Migration commit complete".

[Claim 8]

(a) For a Write request from a parent model, if the page is not registered in the hash data structure, write the page identifier and LSN information into the hash data structure, and write the page to the log buffer, but use LRUCLeast recently used. Writing the target page selected by the page replacement algorithm to a log file;

(b) For a Write request from a higher model, if the page is registered in the hash data structure, if the same page as the page exists in the log buffer, the page is written to that page; Writing a target page selected by a algorithm in the log file and writing the page to the log buffer;

(c) recording a page in the log buffer for a Commit request from higher parents, recording all pages not recorded in the log file, and recording the status so far in a predetermined area of the database file; And reading all the pages stored in the log file using the hash data structure and sequentially recording the pages in the database file, and recording the status of the database file up to date in a predetermined area of the database file. Transaction logging and recovery methods for databases deployed in mobile environments.

[Claim 9]

The method according to claim 8, wherein before step (c)

(al) in response to a Read request from an upper module, reading the page from the database file if the page is not registered in the hash data structure; And

(bl) For a Read request from higher parents, if the page is registered in the hash data structure, the page is read from the log buffer, and if there is no page identical to the page in the log buffer, the LRU page replacement algorithm And replacing the same page as the corresponding page in the log file by the transaction method.

[Claim 10]

10. The method of claim 8 or 9, wherein the hash data structure

A hash table, which is a list of hash nodes that specify the starting position of the bucket against the hash key,

A transaction logging and retrieval method for a database built in a mobile environment, comprising a bucket block having page identifiers and LSN information as components of a bucket.

[Claim 11]

The method according to claim 8 or 9,

To a data structure for accessing the log buffer

A hash table for hash chain construction; And

And a buffer control block comprising a hash chain for retrieving a page corresponding to a page identifier, an LRU chain for an LRU page replacement algorithm, and a page pointer pointing to a corresponding page in a log buffer. Transaction logging and recovery methods for databases deployed in mobile environments.

[Claim 12]

The method of claim 8 or 9, wherein step (a)

A transaction logging and recovery method for a database built in a mobile environment, characterized by generating LSN information for a page selected as a target page in a sequential manner.

[Claim 13]

The method according to claim 8 or 9,

(d) When booting after a system error condition, if the progress progressed so far recorded in a predetermined area of the database file is "log commit completed", all pages stored in the log file are read and written to the database file. And initializing the log file when “transaction start” or “migration commit is completed”. 8. The method of claim 2, further comprising: initializing the log file.