WO2017082520A1 - Système de gestion de base de données et son procédé de modification et de récupération de données - Google Patents

Système de gestion de base de données et son procédé de modification et de récupération de données Download PDF

Info

Publication number
WO2017082520A1
WO2017082520A1 PCT/KR2016/008849 KR2016008849W WO2017082520A1 WO 2017082520 A1 WO2017082520 A1 WO 2017082520A1 KR 2016008849 W KR2016008849 W KR 2016008849W WO 2017082520 A1 WO2017082520 A1 WO 2017082520A1
Authority
WO
WIPO (PCT)
Prior art keywords
log
page
file
record
database
Prior art date
Application number
PCT/KR2016/008849
Other languages
English (en)
Korean (ko)
Inventor
장용일
김효성
박상현
신민철
이준희
Original Assignee
엘지전자 주식회사
연세대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사, 연세대학교 산학협력단 filed Critical 엘지전자 주식회사
Publication of WO2017082520A1 publication Critical patent/WO2017082520A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • 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.
  • 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.
  • 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.
  • various applications used in the mobile terminal use a rollback journal (RWB) method or a write ahead log (WAL) method.
  • RWB rollback journal
  • WAL write ahead log
  • the RBJ method is a method of backing up original data and applying it to a database when a write operation occurs
  • WAL method is a method of maintaining original data in a database file and storing changed pages in a WAL file.
  • the RBJ method and the WAL method have a problem of backing up data that does not change.
  • the WAL method has a problem that a log file must be searched every time a read operation is performed.
  • the WAL file since the latest modification exists in the WAL file, when a read operation is performed, the WAL file must be searched once.
  • the WAL method has a problem that the checkpoint operation is delayed.
  • 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.
  • 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.
  • 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.
  • a database management system 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.
  • 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 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 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 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).
  • ANR Application Not Responding
  • the WAL file 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.
  • FIG. 1 is a block diagram showing a database management system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating contents stored in a database.
  • 3 is a diagram showing the structure of a database file.
  • FIG. 4 is a diagram illustrating a dirty page according to a change of a database file.
  • FIG. 5 is a diagram illustrating a log record generation method according to the dirty page of FIG. 4.
  • FIG. 6 is a view for explaining a logging mode change process according to the size of a log record.
  • FIG. 7 is a diagram showing the structure of a log record.
  • FIG. 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.
  • FIGS. 10 and 11 are diagrams for explaining the position of a log record inserted into a log page.
  • FIG. 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.
  • 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.
  • FIG. 1 is a block diagram showing a database management system according to an embodiment of the present invention.
  • 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.
  • the database 100 may store a database file (DB file) configured in units of pages.
  • DB file database file
  • 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.
  • the log file generation unit 200 may generate a log file for a database file on which a transaction is performed.
  • 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.
  • 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.
  • 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.
  • the transaction execution unit 300 may perform a transaction of the database file.
  • 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.
  • controller 400 may control the database 100, the log file generation unit 200, and the transaction execution unit 300.
  • the controller 400 may control the transaction execution unit 300 to perform the transaction of the database file.
  • 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.
  • the log file generator 200 may be controlled to store the generated entire log record in a log file.
  • the dirty page of the database file may mean a page whose contents are changed by performing a transaction.
  • 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.
  • 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.
  • the present invention can compress the log record and store it in the log file, thereby further reducing the size of the log file.
  • the controller 400 may compare the size of the generated full log record and the size of the dirty page.
  • the log file generator 200 may be controlled to store the data in the log file.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the present invention can reflect all the generated log records in the log file without losing the log records.
  • 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 controller 400 may check the change history by using a bitmap index.
  • log files when a log file is stored in a database, some log records of the pages in the log file may be lost or corrupted.
  • 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.
  • 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.
  • the process of storing the entire contents of the dirty pages can be omitted.
  • the controller 400 may store a checksum in a commit log record of the log file.
  • 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.
  • 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.
  • 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.
  • the controller 400 may compress the entire log record at once and store the compressed full log record in the log file.
  • 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.
  • 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
  • FIG. 3 is a diagram showing the structure of a database file.
  • 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.
  • a number of records 122 may be stored in one page of the database file 120.
  • the customer information list 110 may include customer information 112 such as the name, age, and gender of the customer. have.
  • 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.
  • FIG. 3 shows the structure of a database file 120 in which three records 122 are stored in one page.
  • FIG. 4 is a diagram illustrating a dirty page according to a change of a database file
  • FIG. 5 is a diagram illustrating a log record generation method according to the dirty page of FIG. 4.
  • the system 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.
  • 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.
  • the database file may generate two dirty pages whose contents are changed as a result of the change command.
  • log records for two dirty pages whose contents are changed may be generated.
  • the log file may be very large.
  • 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.
  • a change history is stored for each page along with each change type, and the size of a log file.
  • 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.
  • FIG. 6 is a view for explaining a logging mode change process according to the size of a log record.
  • 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.
  • 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.
  • 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.
  • log records for the change history of the dirty pages 13 and 17 may be generated.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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
  • FIG. 9 is a change command list showing change commands of a database file.
  • 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.
  • 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.
  • 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.
  • the system of the present invention can achieve a greater performance improvement in terms of processing speed and processing efficiency.
  • 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.
  • the log pointer 620 and the log record 630 may be arranged in a one-to-one correspondence with each other.
  • 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.
  • 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.
  • 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.
  • the present invention can perform a logical operation satisfying the two conditions as shown in FIG. 9.
  • one logical operation must correspond to one operation for changing a database file.
  • 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.
  • 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.
  • the pages modified by the PagerStress function of the present invention can be written to a database file before the transaction is committed.
  • 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.
  • 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
  • Cell index indicates the number of cells in the page.
  • Data after the cell index stores necessary data according to the characteristics of the opcode.
  • the invention 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.
  • 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.
  • the nth log entry can be accessed by getting the corresponding byte from the address pointed to by Pointer n.
  • the present invention supports overflow records to minimize internal fragmentation of log pages.
  • 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.
  • 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.
  • FIGS. 10 and 11 are diagrams for explaining the position of a log record inserted into a log page.
  • 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.
  • 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.
  • 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.
  • the log pointer 720 may include length information and position information of a corresponding current log record.
  • the log pointer 720 may include flag 722, length 724, and offset 726 information.
  • 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.
  • 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.
  • the log pointer 820 may include length information of a corresponding current log record and position information of a previous log record.
  • the log pointer 820 may include flag 822, length 824, and previous offset 826 information.
  • 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.
  • 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
  • FIG. 14 illustrates a log according to a change history of a dirty page. The figure shows a file.
  • 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.
  • 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.
  • the second and third log records 1022 and 1023 may be lost due to a failure in execution.
  • 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.
  • 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.
  • 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.
  • the system of the present invention can check the change history using a bitmap index 1030 as shown in FIG. 13.
  • bitmap index 1030 consumes only 1 bit per page of the database file
  • bitmap index 1030 can cover 32768 pages with only 4 KB.
  • 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.
  • 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.
  • 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.
  • the present invention stores the log differently according to the page state of the changed database file.
  • a log entry is generated and stored in the log page.
  • bitmap which is a dirty experience bit
  • bitmap requires only 1 bit per page (0 or 1)
  • 32768 DB pages can be represented by only 4 KB.
  • 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”.
  • bitmap 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.
  • 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.
  • 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.
  • the checksum may be performed on a log record and a log pointer indicating the log record.
  • 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.
  • the data change method of the database management system configured as follows.
  • 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.
  • the system may extract a database file requested for change from the database, perform a transaction, and change a page of the database file.
  • 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.
  • 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.
  • the log page may be stored in the buffer memory.
  • 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.
  • 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.
  • the log page may be stored in the buffer memory.
  • the log pages stored in the buffer memory 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 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.
  • 16 is a flowchart illustrating a data recovery method of a database management system according to an embodiment of the present invention.
  • the system of the present invention may receive a data recovery request.
  • 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)
  • the system stores the original page in the database file (S50).
  • 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).
  • 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).
  • the system deletes the corresponding log record (S110).
  • 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.
  • 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.
  • 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.
  • the present invention shows superior performance than other methods, and can solve the problems of the existing methods.
  • the present invention can perform data recovery in various situations.
  • the present invention enables data recovery in a transaction failure situation.
  • 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.
  • 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.
  • the present invention can cope with the following situations caused by a system crash.
  • the present invention processes the Pager_stressed log record and deletes the log record associated with the transaction.
  • 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
  • the database file contains all the changes made by the transaction. It is not known whether it is reflected.
  • the present invention may redo all log records associated with the transaction while performing a recovery algorithm.
  • the present invention enables data recovery in a disk failure situation.
  • the data of the disc block may be lost.
  • the log file stores the page so that data can be recovered.
  • 17 to 20 are diagrams illustrating a recovery performance of a database management system according to an embodiment of the present invention.
  • FIG. 17 is a graph comparing execution times according to the number of checkpoints using RL benchmarks.
  • 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.
  • 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.
  • 50, 1000, and 1000000 of the horizontal axis mean the range of execution of the checkpoint.
  • the DWAL method of the present invention has a faster execution processing time than the conventional WAL method. have.
  • 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.
  • 5, 10, 20, 50, and 100 on the horizontal axis mean the number of log records inserted per single transaction.
  • the DWAL method of the present invention has a faster execution processing time than the conventional WAL method. have.
  • 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.
  • the first logging method is a page-oriented logging only method for logging only the change history
  • 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.
  • 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.
  • the checkpoint speed can be improved compared to the WAL method that requires an additional migration cost. Application Not Responding).
  • 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.
  • 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.
  • the computer may include a control unit of the terminal.
  • the present invention is used in the field related to a database management system that enables data to be changed and recovered.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Library & Information Science (AREA)

Abstract

La présente invention se rapporte à un système de gestion de base de données qui permet de modifier et de récupérer des données, ainsi qu'à son procédé de modification et de récupération de données. Ledit système de gestion de base de données comprend : une base de données destinée à mémoriser un fichier de base de données configuré en unités de pages ; une unité de génération de fichier journal conçue pour générer un fichier journal d'un fichier de base de données pour lequel une transaction a été réalisée ; une unité de réalisation de transaction servant à réaliser une transaction d'un fichier de base de données ; et une unité de commande permettant de commander la base de données, l'unité de génération de fichier journal et l'unité de réalisation de transaction, cette unité de commande pouvant commander l'unité de réalisation de transaction afin qu'elle réalise une transaction d'un fichier de base de données lorsque la transaction du fichier de base de données est demandée, et commander l'unité de génération de fichier journal pour qu'elle génère un enregistrement de journal de détails de modification concernant chaque page non nettoyée, dont le contenu a été modifié, parmi les pages du fichier de base de données quand la transaction du fichier de base de données est réalisée, et qu'elle mémorise la totalité de l'enregistrement de journal généré dans un fichier journal lorsque la transaction est exécutée dans la base de données.
PCT/KR2016/008849 2015-11-10 2016-08-11 Système de gestion de base de données et son procédé de modification et de récupération de données WO2017082520A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020150157340A KR20170054767A (ko) 2015-11-10 2015-11-10 데이터베이스 관리 시스템 및 그의 데이터 변경 및 복구 방법
KR10-2015-0157340 2015-11-10

Publications (1)

Publication Number Publication Date
WO2017082520A1 true WO2017082520A1 (fr) 2017-05-18

Family

ID=58695745

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/008849 WO2017082520A1 (fr) 2015-11-10 2016-08-11 Système de gestion de base de données et son procédé de modification et de récupération de données

Country Status (2)

Country Link
KR (1) KR20170054767A (fr)
WO (1) WO2017082520A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109284179A (zh) * 2018-08-07 2019-01-29 北京达佳互联信息技术有限公司 解决应用程序卡顿的方法、装置、电子设备及存储介质
CN111104259A (zh) * 2019-12-23 2020-05-05 厦门市美亚柏科信息股份有限公司 一种数据库恢复方法、装置及存储介质
CN112015807A (zh) * 2019-05-31 2020-12-01 阿里巴巴集团控股有限公司 数据同步的处理方法、装置、电子设备及计算机存储介质
CN115129739A (zh) * 2022-08-31 2022-09-30 杭州沃趣科技股份有限公司 一种数据文件断点续传方法、装置、设备及存储介质

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101990329B1 (ko) * 2017-08-10 2019-06-18 주식회사 티맥스데이터 로그 데이터 분석을 이용한 데이터베이스 복구 속도 향상 기법 및 장치
KR102085608B1 (ko) * 2018-12-21 2020-03-06 주식회사 티맥스데이터 복구 서버 및 컴퓨터 프로그램
KR20240056278A (ko) 2022-10-21 2024-04-30 네이버 주식회사 데이터 복구 방법 및 이를 이용하는 컴퓨팅 장치

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0628043A (ja) * 1992-06-30 1994-02-04 Toshiba Corp 静止形開閉器
JP2004062759A (ja) * 2002-07-31 2004-02-26 Hitachi Ltd データベースログの管理方法、その装置およびそのプログラム
KR20050052016A (ko) * 2003-11-28 2005-06-02 한국전자통신연구원 파일 시스템의 메타 데이터 회복을 위한 로깅과 회복 방법및 장치
KR20080044480A (ko) * 2006-11-16 2008-05-21 삼성전자주식회사 지연된 로깅 방법 및 그 장치
KR20080084263A (ko) * 2007-03-15 2008-09-19 주식회사넥싸이트 시리얼 ｅｅｐｒｏｍ의 손상된 데이터를 복구하기 위한장치 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0628043A (ja) * 1992-06-30 1994-02-04 Toshiba Corp 静止形開閉器
JP2004062759A (ja) * 2002-07-31 2004-02-26 Hitachi Ltd データベースログの管理方法、その装置およびそのプログラム
KR20050052016A (ko) * 2003-11-28 2005-06-02 한국전자통신연구원 파일 시스템의 메타 데이터 회복을 위한 로깅과 회복 방법및 장치
KR20080044480A (ko) * 2006-11-16 2008-05-21 삼성전자주식회사 지연된 로깅 방법 및 그 장치
KR20080084263A (ko) * 2007-03-15 2008-09-19 주식회사넥싸이트 시리얼 ｅｅｐｒｏｍ의 손상된 데이터를 복구하기 위한장치 및 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LEE, JOON HEE ET AL.: "A Novel Recovery Scheme for SQLite Based on Logical Logging", JOURNAL OÍKL1T, vol. 12, no. 11, 30 November 2014 (2014-11-30), pages 181 - 192, XP055382000 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109284179A (zh) * 2018-08-07 2019-01-29 北京达佳互联信息技术有限公司 解决应用程序卡顿的方法、装置、电子设备及存储介质
CN112015807A (zh) * 2019-05-31 2020-12-01 阿里巴巴集团控股有限公司 数据同步的处理方法、装置、电子设备及计算机存储介质
CN111104259A (zh) * 2019-12-23 2020-05-05 厦门市美亚柏科信息股份有限公司 一种数据库恢复方法、装置及存储介质
CN111104259B (zh) * 2019-12-23 2022-08-12 厦门市美亚柏科信息股份有限公司 一种数据库恢复方法、装置及存储介质
CN115129739A (zh) * 2022-08-31 2022-09-30 杭州沃趣科技股份有限公司 一种数据文件断点续传方法、装置、设备及存储介质
CN115129739B (zh) * 2022-08-31 2022-11-25 杭州沃趣科技股份有限公司 一种数据文件断点续传方法、装置、设备及存储介质

Also Published As

Publication number Publication date
KR20170054767A (ko) 2017-05-18

Similar Documents

Publication Publication Date Title
WO2017082520A1 (fr) Système de gestion de base de données et son procédé de modification et de récupération de données
WO2018159997A1 (fr) Appareil et procédé de réalisation d'essai à l'aide d'un jeu d'essais
WO2018101640A1 (fr) Procédé de récupération de cohérence pour duplication de base de données transparente
WO2014208863A1 (fr) Appareil et procédé de gestion de données intégrée pour cache de tampon non volatil et dispositif de stockage non volatil
CN108416040B (zh) 一种数据库修复方法、装置、终端设备及存储介质
WO2018034426A1 (fr) Procédé de correction automatique d'erreurs dans un corpus balisé à l'aide de règles pdr de noyau
WO2014032262A1 (fr) Procédé et système d'implémentation pour migration d'application entre des plateformes
WO2016204529A1 (fr) Dispositif et procédé de stockage en mémoire destinés à la prévention de perte de données après une perte d'alimentation électrique
US7823007B2 (en) Apparatus, system, and method for switching a volume address association in a point-in-time copy relationship
WO2020101343A1 (fr) Procédé de mise en œuvre d'une capture de données de changement dans un système de gestion de base de données
WO2019088334A1 (fr) Système de stockage et de recherche de mégadonnées en temps réel
WO2021040167A1 (fr) Appareil d'agent de mise à jour de logiciel et procédé de correctif l'utilisant
WO2015002481A1 (fr) Appareil et procédé de gestion de tampon à trois états sur la base d'une mémoire flash
WO2021080385A1 (fr) Dispositif informatique et procédé de fonctionnement associé
WO2015005636A1 (fr) Système de mémoire et procédé de traitement de données pour mémoire
WO2018076872A1 (fr) Procédé et appareil de sauvegarde de données, support de stockage et serveur
WO2019062093A1 (fr) Procédé et dispositif de gestion de raid, et support d'informations lisible par ordinateur
WO2017035785A1 (fr) Procédé et appareil pour localiser une fuite de mémoire
WO2016192110A1 (fr) Procédé et dispositif de traitement d'informations de fichier, et appareil et système de traitement de fichier
WO2019062103A1 (fr) Procédé de montage d'un réseau de disques, dispositif android et support de stockage
WO2018236141A1 (fr) Procédé de regroupement de rapports de panne , serveur et programme informatique
WO2021172708A1 (fr) Procédé de traitement d'une commande de barrière de mémoire cache pour réseau de disques et dispositif associé
WO2023163405A1 (fr) Procédé et appareil de mise à jour ou de remplacement de modèle d'évaluation de crédit
WO2019062107A1 (fr) Procédé et dispositif de gestion de raid, et support de stockage lisible par ordinateur
WO2014073747A1 (fr) Procédé pour réduire la consommation d'énergie d'une mémoire flash et appareil associé

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16864446

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16864446

Country of ref document: EP

Kind code of ref document: A1