WO2017082520A1

WO2017082520A1 - Database management system, and data modification and recovery method thereof

Info

Publication number: WO2017082520A1
Application number: PCT/KR2016/008849
Authority: WO
Inventors: 장용일; 김효성; 박상현; 신민철; 이준희
Original assignee: 엘지전자 주식회사; 연세대학교 산학협력단
Priority date: 2015-11-10
Filing date: 2016-08-11
Publication date: 2017-05-18
Also published as: KR20170054767A

Abstract

The present invention relates to a database management system which enables data to be modified and recovered, and a data modification and recovery method thereof. The database management system comprises: a database for storing a database file configured in units of pages; a log file generation unit for generating a log file of a database file for which transaction has been performed; a transaction performance unit for performing transaction of a database file; and a control unit for controlling the database, the log file generation unit, and the transaction performance unit, wherein the control unit can control the transaction performance unit to perform transaction of a database file when transaction of the database file is requested, and control the log file generation unit to generate a log record of modification details of each dirty page, a content of which has been modified, among pages of the database file when transaction of the database file is performed, and to store the entire generated log record in a log file when the transaction is committed to the database.

Description

Database management system and its data change and recovery method

The present invention relates to a database management system and a method for altering and recovering data thereof, which enable to change and recover data.

In general, a database management system recovers data through its own logging method and log to maintain data consistency in the event of power failure or system failure. Can support the method.

Accordingly, the database management system may include a mechanism for recovering data when data is lost due to a failure of a transaction, a program, a system, or the like.

The data recovery method of the database management system has various methods. In particular, various applications used in the mobile terminal use a rollback journal (RWB) method or a write ahead log (WAL) method.

Here, the RBJ method is a method of backing up original data and applying it to a database when a write operation occurs, and the WAL method is a method of maintaining original data in a database file and storing changed pages in a WAL file.

However, the RBJ method and the WAL method have a problem of backing up data that does not change.

For example, in the RBJ and WAL schemes, only a part of changed data is stored in the page, but the entire page including the changed data must be stored.

In addition, the WAL method has a problem that a log file must be searched every time a read operation is performed.

For example, in the WAL method, since the latest modification exists in the WAL file, when a read operation is performed, the WAL file must be searched once.

In addition, the WAL method has a problem that the checkpoint operation is delayed.

For example, the WAL method may not perform a checkpoint operation when a read lock is applied to data, and thus a WAL file may be tens or hundreds of times larger than a database file.

As described above, the conventional data recovery method has a problem that data recovery is too slow and takes a lot of time, and data recovery is unstable.

It is an object of the present invention to solve the above and other problems. Another object is to provide a database management system and its data change and recovery method that can reduce the size of log files and lower the overall I / O load.

Another object is to provide a database management system capable of improving checkpoint speed and a method of data change and recovery thereof.

Another object is to provide a database management system and its data alteration and recovery method which can lower the cost of retrieval.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.

A database management system according to an embodiment of the present invention includes a database storing a database file configured in units of pages, a log file generating unit generating a log file for a database file on which a transaction is performed, and a database file. And a control unit for controlling a transaction, and a control unit for controlling a database, a log file generation unit, and a transaction execution unit, wherein the control unit controls the transaction execution unit to perform a transaction of the database file when a transaction of the database file is requested. When a transaction of a database file is performed, a log record of the change history is generated for each dirty page of contents of the database file, and when a transaction is committed to the database. , Generated full log levels The log file generator can be controlled to store code in a log file.

A data change method of a database management system according to an embodiment of the present invention includes receiving a change request of a database file, performing a transaction of a change requested database file, and dirty pages of a database file on which a transaction is performed. Checking the dirty page, for each dirty page whose contents have been changed, generating a log record of the change history, and when a transaction commit is requested, the generated whole log record is stored in the log file. Saving to a log page and committing the transaction to the database.

A data recovery method of a database management system according to an embodiment of the present invention includes the steps of receiving a data recovery request, checking the existence of a log file for a database file to be restored, and if the log file exists, Searching from the last log record in the file to the last commit log record in reverse order to determine if the original page exists for the database file to be recovered; if the original page exists, storing the original page in the database file; Retrieving log records that exist between them from the last checkpoint log record in the log file to the last commit log record, and deleting the log records that existed since the last commit log record in the log file. May include All.

The effects of the database management system and the data change and recovery method thereof according to the present invention will be described below.

According to at least one of the embodiments of the present invention, by logging only the operation for changing the database file for each page without logging the entire changed page, it is possible to reduce the size of the log file and lower the overall input / output load.

According to at least one of the embodiments of the present invention, since only a sync operation is performed on the database file at the checkpoint, the checkpoint speed may be improved as compared to the WAL method requiring an additional migration cost. In this way, it is possible to solve the problem of ANR (Application Not Responding).

According to at least one of the embodiments of the present invention, in the case of the WAL method, at the time of reading, the WAL file must be searched once unconditionally, but it is disadvantageous to the select operation. Search costs can be lowered further.

Further scope of the applicability of the present invention will become apparent from the following detailed description. However, various changes and modifications within the spirit and scope of the present invention can be clearly understood by those skilled in the art, and therefore, specific embodiments, such as the detailed description and the preferred embodiments of the present invention, should be understood as given by way of example only.

1 is a block diagram showing a database management system according to an embodiment of the present invention.

2 is a diagram illustrating contents stored in a database.

3 is a diagram showing the structure of a database file.

4 is a diagram illustrating a dirty page according to a change of a database file.

5 is a diagram illustrating a log record generation method according to the dirty page of FIG. 4.

6 is a view for explaining a logging mode change process according to the size of a log record.

7 is a diagram showing the structure of a log record.

8 is a diagram illustrating the structure of a log file into which the log record of FIG. 7 is inserted.

9 is a change command list showing change commands of a database file.

10 and 11 are diagrams for explaining the position of a log record inserted into a log page.

12 is a diagram for describing a tone page of a log file.

FIG. 13 is a diagram illustrating a bitmap index for checking a change history of a dirty page. FIG.

14 illustrates a log file according to a change history of a dirty page.

15 illustrates a log page in which a checksum is stored.

16 is a flowchart illustrating a data recovery method of a database management system according to an embodiment of the present invention.

17 to 20 are diagrams illustrating a recovery performance of a database management system according to an embodiment of the present invention.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings, and the same or similar components are denoted by the same reference numerals regardless of the reference numerals, and redundant description thereof will be omitted. The suffixes "module" and "unit" for components used in the following description are given or used in consideration of ease of specification, and do not have distinct meanings or roles from each other. In addition, in describing the embodiments disclosed herein, when it is determined that the detailed description of the related known technology may obscure the gist of the embodiments disclosed herein, the detailed description thereof will be omitted. In addition, the accompanying drawings are intended to facilitate understanding of the embodiments disclosed herein, but are not limited to the technical spirit disclosed herein by the accompanying drawings, all changes included in the spirit and scope of the present invention. It should be understood to include equivalents and substitutes.

Terms including ordinal numbers such as first and second may be used to describe various components, but the components are not limited by the terms. The terms are used only for the purpose of distinguishing one component from another.

When a component is referred to as being "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between.

Singular expressions include plural expressions unless the context clearly indicates otherwise.

In this application, the terms "comprises" or "having" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

As shown in FIG. 1, the database management system of the present invention may include a database 100, a log file generator 200, a transaction performer 300, and a controller 400. Can be.

Here, the database 100 may store a database file (DB file) configured in units of pages.

The database 100 may include a database file in which data is stored as a file.

The database file is composed of pages, and each page may store a record, which is information stored in an actual database.

Thus, in one page of the database file, multiple records can be stored.

The log file generation unit 200 may generate a log file for a database file on which a transaction is performed.

Here, the log file generating unit 200 may generate a log file in which information on the changed contents is stored when the database file is changed by performing a transaction.

Therefore, the system of the present invention can recover damaged data by using a log file when recovering a database file.

The log file generating unit 200 generates a log record including the changed contents every time the contents of the database file are changed according to the execution of the transaction, accumulates the generated log records in the buffer memory, and then executes the transaction. After the completion of the commit command, the log records accumulated in the buffer memory may be inserted into the log page of the log file.

Therefore, the system of the present invention can store the log file into which the log records are inserted in the database 100, and store the database file whose contents have been changed by the transaction.

Next, the transaction execution unit 300 may perform a transaction of the database file.

Here, the transaction execution unit 300 may select a page of the database file to be changed, perform a transaction on the page of the selected database file, and change the contents of the database file.

Subsequently, the controller 400 may control the database 100, the log file generation unit 200, and the transaction execution unit 300.

Herein, when the transaction of the database file is requested, the controller 400 may control the transaction execution unit 300 to perform the transaction of the database file.

When the transaction of the database file is performed, the controller 400 checks a dirty page of the pages of the database file, and logs a record of the change history for each dirty page whose content has changed. When the transaction is committed to the database 100, the log file generator 200 may be controlled to store the generated entire log record in a log file.

Here, the dirty page of the database file may mean a page whose contents are changed by performing a transaction.

That is, the controller 400 generates a log record for the change history every time a page of the database file is changed, accumulates the log record generated in the buffer memory, and then executes a commit command. You can save all accumulated log records at one time to a log file.

Therefore, the present invention does not store the entire change page every time the page of the database file is changed, and generates only the log record for the change history and stores it in the log file, so that the change and recovery of the database file is quick and fast, You can reduce the size of log files.

In addition, the present invention can compress the log record and store it in the log file, thereby further reducing the size of the log file.

Next, when storing the generated full log record in the log file, the controller 400 may compare the size of the generated full log record and the size of the dirty page.

For example, if the size of the generated total log record is smaller than the size of the dirty page, store the generated total log record in the log file.If the size of the generated total log record is larger than the size of the dirty page, the dirty page The log file generator 200 may be controlled to store the data in the log file.

For example, if there are many changes to one dirty page, the number of log records for the dirty pages also increases, so that the total accumulated log record size may be larger than the dirty pages.

In this case, the first logging method for storing a log record having a size larger than the dirty pages in the log file may be lowered in speed or efficiency than the second logging method for storing dirty pages in the log file.

Accordingly, the present invention compares the size of the generated total log record with the size of the dirty page, and if the size of the generated total log record is smaller than the size of the dirty page, the present invention records the entire log record generated by the first logging method. If the size of the generated total log record is larger than the size of the dirty page, the second page may store the dirty page in the log file.

Therefore, the present invention can improve the logging speed and efficiency by selecting the first logging method or the second logging method according to the result of comparing the size of the entire log record and the size of the dirty page.

In addition, the controller 400 generates a new additional log page and adds an overflow flag in the log page header when the number of log records inserted in the log page exceeds the free space size of the log page. The generation unit 200 may be controlled.

Therefore, even if the number of log records exceeds the log page, the present invention can reflect all the generated log records in the log file without losing the log records.

When the dirty page of the database file is checked, the controller 400 checks the change history of the dirty page, and if a change history exists in the dirty page, generates a log record of the change history of the dirty page. The stored log file in the log file, and if there is no change history on the dirty page, the log file generator 200 to store the entire dirty page in the log file without generating a log record for the change history of the dirty page. Can be controlled.

In this case, when the change history on the dirty page is checked, the controller 400 may check the change history by using a bitmap index.

For example, when a log file is stored in a database, some log records of the pages in the log file may be lost or corrupted.

Therefore, the present invention checks the change history of the dirty page of the database file, and if there is no change history, stores the entire dirty page on which the transaction is performed in a log file without generating a log record of the current change history, and the change history. If present, you can create a log record of the current change history and save it to a log file.

That is, according to the present invention, if there is no change history, the entire contents of the dirty pages changed by the transaction are stored in the log file without generating the log record, so that the data of the database file can be recovered even if the log record is lost later.

In addition, according to the present invention, if there is a change history, since the entire contents of the dirty pages are previously stored in the log file, the process of storing the entire contents of the dirty pages can be omitted.

Therefore, in the present invention, even if there is a log file including a ton page in which some log records are lost, the original page on which the initial transaction is performed exists in the log file, thereby enabling data recovery of the database file. .

Next, when the transaction is committed, the controller 400 may store a checksum in a commit log record of the log file.

Herein, the control unit 400 stores the first checksum at the last point of the first log page when a plurality of log records generated by the specific transaction are passed from the first log page to the second log page, and A second checksum can be stored in the commit log record.

The checksum may be performed on a log record and a log pointer indicating the log record.

Subsequently, the controller 400 compares the contents of the checksum and the log record at the time of restoring the database file. If the contents of the checksum and the log record are different, the controller 400 determines that the corresponding transaction has failed, and in the redo process. You can exclude log records.

As described above, according to the present invention, a checksum is stored in a commit log record at the time of committing a transaction, so that a corruption of the log record can be confirmed in a data recovery process, thereby preventing a recovery error.

In addition, when the generated full log record is stored in the log file, the controller 400 may compress the entire log record at once and store the compressed full log record in the log file.

As another case, the controller 400 may compress each log record individually when storing the generated full log record in the log file, and store the individually compressed full log record in the log file.

As described above, the present invention can reduce the size of the log file by compressing the log record, so that the change and recovery speed is fast and the efficiency is excellent.

FIG. 2 is a diagram showing contents stored in a database, and FIG. 3 is a diagram showing the structure of a database file.

As illustrated in FIGS. 2 and 3, a database stores a database file 120, and the database file 120 may be configured in units of pages.

Each page of the database file 120 may store a record, which is information stored in an actual database.

Thus, a number of records 122 may be stored in one page of the database file 120.

For example, as shown in FIG. 2, when information called the customer information list 110 is stored in a database, the customer information list 110 may include customer information 112 such as the name, age, and gender of the customer. have.

Here, the customer information 112 may be sequentially stored in each page of the database file 120, as shown in FIG.

Each customer information 112 may be stored in a record 122 in a corresponding page.

3 shows the structure of a database file 120 in which three records 122 are stored in one page.

4 is a diagram illustrating a dirty page according to a change of a database file, and FIG. 5 is a diagram illustrating a log record generation method according to the dirty page of FIG. 4.

As shown in FIG. 4, in the system of the present invention, when a command to add a table t1 is received within page 1 of a database file, the system inserts the table t1 into page 1 of the database file according to the received command. You can change the file.

Here, the table t1 is inserted into page 1 of the database file, and the existing data on page 1 of the database file can be moved to page 2 of the database file.

Therefore, the database file may generate two dirty pages whose contents are changed as a result of the change command.

Next, as shown in FIG. 5, log records for two dirty pages whose contents are changed may be generated.

For example, since the WAL logging method stores all the contents of two changed dirty pages in a log file, the log file may be very large.

In addition, since the logical logging method stores only the type of modification operation and the log record itself in a log file, there are problems that the entire query must be executed again when performing data recovery.

For example, in the logical logging method, only the fact that the table t1 is inserted into page 1 of the database file is stored in the log file.

Next, the logging method according to the system of the present invention is a page-oriented logical logging method, in which a change history is stored for each page along with each change type, and the size of a log file In addition, when performing data recovery, independent recovery for each page is possible and the recovery speed is fast.

For example, in the page-oriented logical logging method of the present invention, a table t1 is inserted into page 1 of a database file, and the existing data of page 1 is inserted into page 2 of the database file into a log file for each page. Can be.

The system of the present invention may generate a log record of a change history of each dirty page for each dirty page whose content has changed.

Here, the system of the present invention may compare the size of the generated total log record and the size of the dirty page when storing the generated total log record in the log file.

And, if the size of the generated total log record is smaller than the size of the dirty page, the system stores the generated total log record in the log file, and if the size of the generated total log record is larger than the size of the dirty page, You can save dirty pages to a log file.

As shown in FIG. 6, if there are dirty pages 13 and dirty pages 17 among the pages of the database file whose contents have been changed, log records for the change history of the

dirty pages

13 and 17 may be generated.

Here, when the total size of the log records is five log pages, the total size of the log records may be larger than the size of the dirty pages.

In this case, the logging speed and efficiency can be improved by changing the logging mode to a second logging method that stores log pages in a log file rather than a first logging method that stores log records in a log file.

For example, if there are many changes to one dirty page, the number of log records for the dirty page is also increased, so that the size of the accumulated total log records may be larger than the dirty pages.

Accordingly, the system of the present invention compares the size of the generated total log record with the size of the dirty page, and if the size of the generated total log record is smaller than the size of the dirty page, the entire log generated by the first logging method If the record is stored in the log file, and the size of the generated total log record is larger than the size of the dirty page, the second logging method may store the dirty page in the log file.

7 is a view showing the structure of a log record, FIG. 8 is a view showing the structure of a log file into which the log record of FIG. 7 is inserted, and FIG. 9 is a change command list showing change commands of a database file.

As illustrated in FIGS. 7 and 8, the log file 500 is configured in log page units, and may include a log file header 510 and a plurality of log pages 520.

Each log page 520 may include a log page header 610 including log page information, a log pointer 620 including position and length information of each log record, and a log. It may be configured as a log record 630 including log data.

Here, the log page header 610 may include at least one of a log page number, the number of log records in the log page, available space, and a flag.

Subsequently, the log pointer 620 may include a first unit 622 for storing location information of the log record 630 and a second unit 624 for storing length information of the log record 630. .

The log record 630 includes data necessary to redo a command for changing a database file.

Here, when the log record 630 is compressed, the system of the present invention can achieve a greater performance improvement in terms of processing speed and processing efficiency.

For example, the log record 630 may include a first unit 632 for storing work instruction information, a second unit 634 for storing a dirty page number of the database file 120 on which the work is performed, and a dirty page. The third unit 636 may store a cell number in which a work is performed, and the fourth unit 638 may store log data according to a work command.

Next, the log pointer 620 and the log record 630 may be arranged in a one-to-one correspondence with each other.

Here, the number of log pointers 620 and the number of log records 630 may be the same.

Log pointer 620 may be generated when log record 630 is inserted into log page 520.

In some cases, the log pointer 620 may be generated when the log record 630 is generated before the log record 630 is inserted into the log page 520.

As such, the log pointer 620 is generated when the log record 630 is created or when the log record 630 is inserted into the log page, so that for each log record 630, the corresponding log pointer 620 is used. May be present.

Since the system of the present invention performs logical logging for each page, a logical operation needs to be defined similarly to logical logging.

Accordingly, the present invention can perform a logical operation satisfying the two conditions as shown in FIG. 9.

First, one logical operation must correspond to one operation for changing a database file.

Second, changing the database file must be able to be represented as a logical operation that can generate log records.

Logical tasks of the present invention are operations related to cells in a page (Cell_Insert, Cell_Drop), operations related to the page itself (Page_alloc, Page_empty, Page_erase, Page_ stressed), operations related to B-tree balancing (Copy_Cells, Assemble_Page), and database. It can be divided into header operations, commits, and checkpoints.

Among these, Page_stressed has a unique feature that does not appear in other work, which is closely related to the buffer management policy of the present invention.

The buffer manager of the present invention basically does not reflect dirty pages of a database file modified by a specific transaction to the database file until the transaction is committed.

However, if the number of exceptionally modified pages increases and the memory they occupy exceeds the limits defined by the present invention, the pages modified by the PagerStress function of the present invention can be written to a database file before the transaction is committed.

Therefore, in transaction rollback and data recovery, a separate log can be stored for processing.

In addition, the present invention, when the logical operation to change the database file is performed by the system, generates a log record and inserts it into the log page of the log file.

The log record 630 is data required to redo one logical task and may be configured as shown in FIG. 7.

As shown in FIG. 7, the opcode of the log record 630 indicates which of the tasks defined in FIG. 9 is performed.

Page Number indicates the page number of the database changed by this operation, and Cell index indicates the number of cells in the page.

Next, Data after the cell index stores necessary data according to the characteristics of the opcode.

In most cases, it stores the parameters necessary to call the function specified in Fig. 9, but for the aforementioned Page_stressed and Whole_page, the database page is stored as a whole.

Since the present invention does not reflect the work of uncommitted transactions in the database file, there is no need to undo the log when performing logical log-based recovery.

However, for Pager Stress only, changed pages can be reflected in the database file before committing, and if the transaction is rolled back afterwards, the prewritten pages must be returned to before the transaction begins.

Since it is inefficient to undo all operations related to the page, in order to prevent this, the invention stores the original page in the Data field of the log record 630 before the modification when the PagerStress function is called.

The log file 500 is made up of several pages together like a database file.

Each log page 520 may be implemented in a slotted-page structure.

As shown in FIG. 8, the log page header exists in the foremost portion of the log page 520.

The log page header stores the page number, the number of log entries in the page, available space (lower, upper), other flags, and the like.

Pointers after the page header store the start address and size (offset, length) of the log entry stored from the end of the page.

Therefore, the nth log entry can be accessed by getting the corresponding byte from the address pointed to by Pointer n.

Similarly, when the log record 630 is inserted into the log page 520, a new pointer is made at the end of the pop point pointer, and the log entry to be inserted is stored before the address where the last log entry is stored.

In addition, the present invention supports overflow records to minimize internal fragmentation of log pages.

If the log record to be inserted is larger than the free space of the log page, it can be stored over two or more log pages, and managed through the overflow flag of the page header.

FIG. 8 illustrates a process of inserting a log record of a log file when a record is inserted into a 'address book' table to change a database file.

First, the system of the present invention may change a database file by a transaction, generate a log record of a change history of the database file, and insert the generated log record into a log page of the log file.

The log file including the log page resides in the buffer memory, and when a commit command for a transaction is performed, a log file corresponding to a database may be stored.

10 and 11, the log file of the present invention can use log pages having various structures.

The log page of FIG. 10 is a slotted-page structure, in which an array of pointers storing the position and length of each log record is stored from one end of the log page, and the log record is stored in the log page. The other way is to save it.

In addition, the log page of FIG. 11 is an append-only log page structure that stores a log header having a length of a log record and a location of a previous log record, and sequentially stores log records. That's the way.

As shown in FIG. 10, in the log page 700 of the slot page structure, a log page header 710 may be stored at a start point of the log page 700.

The log pointer 720 may be sequentially stored from the log page header 720 toward the end point of the log page 700 according to the order in which the log record 730 is inserted into the log page 700.

Here, the log pointer 720 may include length information and position information of a corresponding current log record.

For example, the log pointer 720 may include flag 722, length 724, and offset 726 information.

Next, the log record 730 may be sequentially stored from the end point of the log page 700 in the direction of the start point according to the order in which the log record 730 is inserted into the log page 700.

As illustrated in FIG. 11, in the log page 800 of the append only log page structure, a log page header 810 may be stored at a start point of the log page 800.

The log pointer 820 and the log record 830 are moved from the log page header 810 to the end point of the log page 800 according to the order in which the log record 830 is inserted into the log page 800. Can be stored sequentially.

Here, the log pointer 820 may include length information of a corresponding current log record and position information of a previous log record.

For example, the log pointer 820 may include flag 822, length 824, and previous offset 826 information.

Meanwhile, the system may generate a new additional log page and add an overflow flag in the log page header when the number of log records inserted into the log page exceeds the free space size of the log page.

The system of the present invention can compress the entire log record at once and store the compressed whole log record in the log file when storing the generated whole log record in the log file.

In addition, the system of the present invention may compress each log record individually when storing the generated full log record in a log file, and store the individually compressed full log record in a log file.

The reason for storing in this way is that the recovery speed and recovery efficiency can be greatly improved during data recovery.

FIG. 12 illustrates a tone page of a log file, FIG. 13 illustrates a bitmap index for checking a change history of a dirty page, and FIG. 14 illustrates a log according to a change history of a dirty page. The figure shows a file.

As shown in FIG. 12, the system of the present invention may generate a log record every time a command to change a database file is performed.

The log record may be sequentially stored in the log page of the log file in the buffer memory.

For example, first, second, and

third log records

1021, 1022, and 1023 are sequentially stored in the first log page 1010 of the log file in the buffer memory. The first log page 1010 may be stored in a database.

Here, when the first log page 1010 is stored in the database, the second and

third log records

1022 and 1023 may be lost due to a failure in execution.

Accordingly, the first log page 1010 becomes the tone page 1020 in which the second and

third log records

1022 and 1023 are lost, and the first log page 1010 which is the tone page 1020 at the time of data recovery. ) Cannot be used.

In order to solve this tone page problem, the system of the present invention checks the change history for the dirty page of the database file when executing the change command of the database file, and if the change history exists in the dirty page, By creating a log record of the change history, you can save the entire log record created in a log file.

If the change history does not exist in the dirty page, the system may store the entire dirty page in a log file without generating a log record of the change history of the dirty page.

Here, when checking the change history of the dirty page of the database file, the system of the present invention can check the change history using a bitmap index 1030 as shown in FIG. 13.

Here, since the bitmap index 1030 consumes only 1 bit per page of the database file, the bitmap index 1030 can cover 32768 pages with only 4 KB.

If there are more than 32768 pages of the database file, the system of the present invention can expand the bitmap.

Bitmaps are also implemented as shared memory files, which can be used to access a database file from multiple processes.

As such, if the change history exists in the dirty page, the system of the present invention generates a log record of the change history of the dirty page, stores the entire log record generated in the log file, and the change history does not exist in the dirty page. Otherwise, the entire dirty page can be stored in a log file without generating a log record of the change history of the dirty page.

Therefore, as shown in FIG. 14, since the original page of the database file is always stored for each page, even if a tone page is generated in the database, the original page exists in the log file 1040 so that data recovery is possible. It is possible.

According to the present invention, whenever a command to change a database file is performed, a log entry corresponding thereto is generated and stored in a log page, and upon recovery, a log record of a log page is redoed.

However, only a part of the pages of the database file may be stored in the database due to sudden power off.

This is called a ton-page problem, and since a device may not support auto-write, a recovery system is one of the problems to be solved.

In order to solve this tone page problem, the present invention stores the log differently according to the page state of the changed database file.

For example, if a page of a database file that is currently changed has a change history due to a previously committed transaction, a log entry is generated and stored in the log page.

However, if a page in the database file that is currently changed has no history of changes in the past, log entries are not generated, and when the subsequent transaction is committed, the entire changed page (execution command Opcode: Whole_Page) is stored in the log page. do.

Therefore, since the entire changed page is stored in the log file once for each page of each database file, the original page can be recovered through the data recovery.

In order to check the modification history for each page of the database file, a bitmap, which is a dirty experience bit, may be used.

Here, since the bitmap requires only 1 bit per page (0 or 1), 32768 DB pages can be represented by only 4 KB.

In addition, the bitmap is implemented as a shared memory file to support access to a DB file from multiple processes and may be stored in the form of “<DB filename> -shm”.

For example, as shown in FIG. 13, when a page of a database file is modified by a previous transaction and the page exists in the log file, the bitmap is stored as 1, otherwise, as 0, and the bitmap is 1 Log entries are only generated for in-page translations.

15 illustrates a log page in which a checksum is stored.

As shown in FIG. 15, the system of the present invention may store a checksum 1052 in a commit log record 1050 of a log file when a transaction is committed.

Here, the system of the present invention stores the first checksum 1054 at the last point of the first log page when a plurality of log records generated by a particular transaction follow from the first log page to the second log page, The second checksum 1056 may be stored in a commit log record of a specific transaction.

In this case, the checksum may be performed on a log record and a log pointer indicating the log record.

Therefore, the system of the present invention compares the contents of the checksum and the log record at the time of restoring the database file, and if the contents of the checksum and the log record are different, determines the corresponding transaction as a failure, and in the redo process. You can exclude log records.

As described above, the data change method of the database management system according to the present invention configured as follows.

First, the system of the present invention can receive a change request of a database file.

The system may then perform a transaction of the database file for which change is requested.

Here, the system may extract a database file requested for change from the database, perform a transaction, and change a page of the database file.

Next, the system checks the dirty pages of the database file whose contents are changed by performing a transaction, and generates a log record of the change history for each dirty page whose contents have been changed.

The system then stores the generated full log record in the log page of the log file when a commit of the transaction is requested.

The system can then commit the transaction to the database, store the changed database file in the database, and store the corresponding log file in the database.

Here, the system can create a commit log record when committing a transaction to the database.

The system may insert the generated commit log record into the log page in which the log record is stored and store the log page in the log file.

Here, the log page may be stored in the buffer memory.

At this time, when the log pages stored in the buffer memory are stored in the log file, the log pages stored in the buffer memory may be deleted.

The system then retrieves the remaining log pages that are not stored in the log file.

The system may then store the remaining log pages in the log file and commit the transaction to the database if there are remaining log pages that are not stored in the log file.

In addition, the system may generate a checkpoint log record when storing the generated full log record in a log file.

The system may insert the generated checkpoint log record into a log page in which the log record is stored and store the log page in a log file.

Here, the log page may be stored in the buffer memory.

In this case, when the log pages stored in the buffer memory are stored in the log file, the log pages stored in the buffer memory may be deleted.

Next, the system retrieves the remaining log pages that are not stored in the log file, if there are any remaining log pages that are not stored in the log file, the system stores the remaining log pages in the log file, and logs the entire log record generated. You can save it to a file.

As shown in FIG. 16, the system of the present invention may receive a data recovery request.

In addition, the system of the present invention checks the existence of a log file for the database file to be restored. (S20)

Then, if a log file exists, the system searches for the reverse log from the last log record of the log file to the last commit log record (S30), and checks whether the original page for the database file to be recovered exists. S40)

Next, if the original page exists, the system stores the original page in the database file (S50).

Then, the system of the present invention searches in order from the last checkpoint log record of the log file to the last commit log record (S60), and checks whether log records exist between them (S70).

Next, the system of the present invention re-executes the log record if the log record exists between them as a result of the confirmation. (S80)

Next, the system of the present invention searches the log record of the log file (S90) and checks whether the log record exists after the last commit log record of the log file (S100).

If the log record exists after the last commit log record of the log file, the system deletes the corresponding log record (S110).

As described above, the present invention can log only the operation for changing the DB file for each page without logging the entire changed page, thereby reducing the size of the log file and lowering the overall I / O load.

In addition, since the present invention performs only a sync operation on a DB file at checkpoint, a checkpoint speed is faster than that of a WAL method requiring an additional migration cost, and thus, an ANR (Appplication Not Responding) You can solve the problem.

In addition, the WAL method is disadvantageous in the selection operation because the WAL file is unconditionally searched at the time of reading, but in the present invention, the search cost is lower because only the DB file is searched.

Subsequently, the present invention shows superior performance than other methods, and can solve the problems of the existing methods.

Meanwhile, the present invention can perform data recovery in various situations.

First, the present invention enables data recovery in a transaction failure situation.

If a running transaction can no longer be executed for some reason, a transaction failure occurs.

Transaction failures are caused by overflows, resource shortages, deadlocks, etc. In this case, the transaction must be rolled back and returned to the state just before the start of the transaction.

The present invention reverses the search from the last record stored in the log page to the previous commit record when the transaction is rolled back.

During a search, if a Pager_stressed log record is encountered, the original page is overwritten with the database page.

Log records other than Pager_stressed log records are ignored before they are reflected in the database.

Then, when a commit record is reached, all log records after the commit record are deleted.

Secondly, the present invention enables data recovery in a system crash situation.

A system crash is a data malfunction of a volatile storage device due to a hardware malfunction, a bug in a database software or an operating system, etc., and interrupts execution of a transaction.

However, it is assumed that database files and log files of the nonvolatile storage device are not lost.

Since the state of database files and log files are different depending on when a system crash occurs, recovery techniques must be able to handle each situation flexibly.

The present invention can cope with the following situations caused by a system crash.

For example, if there is no commit log of the transaction being executed when the system crashed in the log file, there is no commit log before the page modified by the transaction is reflected in the database file. I have to go back.

Accordingly, the present invention processes the Pager_stressed log record and deletes the log record associated with the transaction.

As another example, if a log file contains a commit log of a transaction in the event of a system crash, the log file contains all the data for redoing the transaction, but the database file contains all the changes made by the transaction. It is not known whether it is reflected.

Accordingly, the present invention may redo all log records associated with the transaction while performing a recovery algorithm.

Third, the present invention enables data recovery in a disk failure situation.

Due to the damage of the disc itself, the data of the disc block may be lost.

Therefore, in the present invention, since the database file and the log file are stored in the same path, they are stored on the same disk.

Even if a disk failure occurs and a particular DB page is damaged, the log file stores the page so that data can be recovered.

FIG. 17 is a graph comparing execution times according to the number of checkpoints using RL benchmarks.

As shown in FIG. 17, as a result of comparing the execution time according to the number of checkpoints, the DWAL method of the present invention shows that the execution time is reduced by about 13.4-22.85% compared to the conventional WAL method.

Therefore, it can be seen that the recovery method of the present invention can reduce the recovery time as compared to the existing method.

18 is a graph comparing the time taken to insert 1000 log records into a log file at one time without performing an initial commit.

Here, 50, 1000, and 1000000 of the horizontal axis mean the range of execution of the checkpoint.

As shown in FIG. 18, as a result of comparing the time taken to insert 1000 log records into a log file at a time, it can be seen that the DWAL method of the present invention has a faster execution processing time than the conventional WAL method. have.

Therefore, it can be seen that the recovery method of the present invention has about 2 to about 6 times better performance than the conventional method.

19 is a graph comparing the time taken to insert 25000 log records into a log file at a time when a plurality of transactions are performed.

Here, 5, 10, 20, 50, and 100 on the horizontal axis mean the number of log records inserted per single transaction.

As shown in FIG. 19, as a result of comparing the time taken to insert 25000 log records into a log file at a time, it can be seen that the DWAL method of the present invention has a faster execution processing time than the conventional WAL method. have.

Therefore, it can be seen that the recovery method of the present invention shows better performance than the existing method.

20 is a table in which the size of the log file generated is measured using an RL benchmark.

The present invention compares the size of a dirty page with the size of an entire log record, and if the size of the generated total log record is smaller than the size of the dirty page, a first logging method for storing the generated total log record in a log file If the size of the generated total log record is larger than the size of the dirty page, the second logging method of storing the dirty page in the log file may be performed.

That is, the first logging method is a page-oriented logging only method for logging only the change history, and the second logging method is based on a result of comparing the size of the dirty page with the size of the entire log record. Bimodal logging method selects small logs among logs.

As shown in FIG. 20, when the logging is performed in the second logging method, it can be seen that the size of the log file is reduced more than the conventional method.

As described above, the present invention can reduce the size of the log file and lower the overall input / output load by logging only an operation for changing the database file for each page without logging the entire changed page.

In addition, since the present invention performs only a sync operation on the database file at the checkpoint, the checkpoint speed can be improved compared to the WAL method that requires an additional migration cost. Application Not Responding).

In addition, the present invention is disadvantageous in the selection operation because the WAL file must be searched once unconditionally in the case of reading, but in the present invention, since only the database file is searched, the search cost can be lowered. have.

It will be apparent to those skilled in the art that the present invention can be embodied in other specific forms without departing from the spirit and essential features of the present invention.

The present invention described above can be embodied as computer readable codes on a medium in which a program is recorded. The computer-readable medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include ROM, RAM, CD-ROM, magnetic tape, floppy disks, optical data storage devices, and the like, which are also implemented in the form of carrier waves (eg, transmission over the Internet). It also includes. In addition, the computer may include a control unit of the terminal.

Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

Various embodiments have been described in the best mode for carrying out the invention.

The present invention is used in the field related to a database management system that enables data to be changed and recovered.

It will be apparent to those skilled in the art that various changes and modifications can be made in the present invention without departing from the spirit or scope of the invention. Accordingly, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

A database storing a database file organized in units of pages;

A log file generation unit generating a log file for a database file on which a transaction is performed;

A transaction execution unit that performs a transaction of the database file; And,

A control unit for controlling the database, a log file generation unit, and a transaction execution unit;

The control unit,

When a transaction of the database file is requested, the transaction execution unit is controlled to perform a transaction of the database file.

When a transaction of the database file is performed, a log record of a change history is generated for each dirty page whose contents are changed among the pages of the database file, and the transaction is committed to the database. and committing, controlling the log file generating unit to store the generated entire log record in the log file.
The method of claim 1, wherein the control unit,

When storing the generated full log record in the log file,

If the size of the generated full log record is smaller than the size of the dirty page, store the generated full log record in the log file,

And control the log file generator to store the dirty page in the log file when the size of the generated total log record is larger than the size of the dirty page.
The method of claim 1, wherein the log file,

Organized in log pages,

The log page,

And a log page header including log page information, a log pointer including position and length information of each log record, and a log record including log data.
The method of claim 3, wherein the log page header,

And at least one of a log page number, a number of log records in a log page, available space, and a flag.
The method of claim 3, wherein the log pointer,

A first unit for storing position information of the log record;

And a second unit for storing length information of the log record.
The method of claim 3, wherein the log record,

A first unit for storing work instruction information;

A second unit for storing a dirty page number of the database file on which the operation is performed;

A third unit for storing a cell number in which the operation is performed in the dirty page; And,

And a fourth unit for storing log data according to the work command.
The method of claim 3, wherein the log pointer and the log record,

Database management system, characterized in that arranged in one-to-one correspondence with each other.
The method of claim 3, wherein the number of log pointers and the number of log records are:

Database management system, characterized in that the same.
The method of claim 3, wherein the log pointer,

And when the log record is inserted into the log page.
The method of claim 3, wherein the log pointer,

And when the log record is generated before the log record is inserted into the log page.
The method of claim 3, wherein the log page header,

Stored at the beginning of the log page,

The log pointer is,

The log record is sequentially stored from the log page header toward the end point of the log page according to the order of insertion of the log record into the log page,

The log record,

And sequentially storing the log record in the direction from the end point of the log page to the start point in the order of insertion of the log record into the log page.
The method of claim 11, wherein the log pointer,

And length information and position information of a corresponding current log record.
The method of claim 3, wherein the log page header,

Stored at the beginning of the log page,

The log pointer and log record,

And sequentially storing the log record in the direction of the end point of the log page from the log page header in the order of insertion of the log record into the log page.
The method of claim 13, wherein the log pointer,

The length information of the corresponding current log record,

A database management system, comprising the location information of previous log records.
The method of claim 3, wherein the control unit,

If the number of log records inserted in the log page exceeds the amount of free space of the log page, create a new additional log page,

And controlling the log file generator to add an overflow flag in the log page header.
The method of claim 1, wherein the control unit,

When generating the log record,

Check the change history for the dirty page, and if a change history exists in the dirty page, generate a log record for the change history of the dirty page, and store the generated entire log record in the log file,

And if the change history does not exist in the dirty page, controlling the log file generator to store the entire dirty page in the log file without generating a log record of the change history of the dirty page. .
The method of claim 16, wherein the control unit,

When checking the change history for the dirty page,

A database management system, characterized by checking the change history using a bitmap index.
The method of claim 1, wherein the control unit,

When the transaction is committed,

And storing a checksum in a commit log record of the log file.
The method of claim 18, wherein the control unit,

Upon recovery of the database file, comparing the checksum with the contents of the log record,

And if the contents of the checksum and the log record are different, determine the corresponding transaction as a failure, and exclude the log record in the redo process.
In the data recovery method of a database management system for generating a log file for a database file on which a transaction is performed,

Receiving a data recovery request;

Checking the existence of a log file for the database file to be recovered;

If the log file exists, searching for the reverse log from the last log record of the log file to the last commit log record to determine whether there is an original page for the database file to be restored;

If the original page exists, storing the original page in the database file;

Retrieving log records existing between the last checkpoint log record and the last commit log record of the log file in order; And,

And deleting the log record existing after the last commit log record of the log file.