Data processing method and related apparatus

Abstract

The present application provides a data processing method and a related apparatus, which can be applied to database flashback scenarios. The method comprises: receiving a first flashback instruction, and in response to the first flashback instruction, recording a first page into a flashback log before modifying the first page in a database for the first time within a target period; and receiving a second flashback instruction, and in response to the second flashback instruction, restoring the database to a state at a specified moment on the basis of the flashback log, and a redo log in the database. In the present application, a first page is recorded into a flashback log only before the first page is modified for the first time within a target period. That is, for a first page that undergoes modification operations, only one initial page is recorded within a target period, while subsequent modified versions within the target period are not recorded, thereby effectively reducing the disk space overhead.

Description

A data processing method and related device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 24, 2024, with application number 202410101131.2 and application name “A data processing method and related devices”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a data processing method and related devices. Background Art

[0003] Database flashback is a database recovery technology that restores a database to its previous state. It has a wide range of applications and can be used in business processes such as upgrades, fault recovery, and undoing logical errors. For example, if you enable the flashback feature when preparing for a database upgrade and an error occurs during the upgrade, you can use flashback to restore the database to its pre-upgrade state. Currently, the industry generally uses physical backups to achieve a similar effect to database flashback. In the event of a database exception, a physical backup is used to rebuild the database. Physical backups essentially copy the current database data and then use the copied data for recovery. Therefore, physical backups consume a significant amount of disk space.

[0004] To address this issue, the industry has proposed several solutions, such as achieving flashback by rolling back (undo) data. Specifically, this solution includes an undo module and a flashback module. During business execution, the undo module is responsible for recording and maintaining the database's undo data. When a flashback command is required, the flashback module selects the corresponding data from the undo data and flashes the database back to the specified time based on the relevant data.

[0005] Undo data records every moment of database data change, effectively enabling database flashback without requiring a physical backup. However, during busy business hours, data changes can be significant, requiring a large volume of undo data, which consumes significant disk space. In extreme scenarios, the disk space occupied by undo data can even exceed that required for physical backups.

[0006] Summary of the Invention

[0007] The present application provides a data processing method and related devices, which can effectively reduce disk space overhead while realizing database flashback function.

[0008] In a first aspect, the present application provides a data processing method applicable to a data processing device. The method comprises: receiving a first flashback instruction; in response to the first flashback instruction, recording a first page in a database to a flashback log before the first modification to the first page in a target cycle; receiving a second flashback instruction; and in response to the second flashback instruction, restoring the database to a state at a specified time based on the flashback log and the database's redo log.

[0009] When the user chooses to turn on the flashback function, a first flashback instruction is issued. After receiving the first flashback instruction, the data processing device records the first page with a modification operation in the flashback log only before the first modification of the first page within the target cycle. That is to say, even if the first page is modified multiple times within the target cycle (usually it will be modified multiple times), only one copy of the initial page is recorded. For pages that have no modification operation within the target cycle, no processing is performed. The target cycle can be any specified period of time, for example, 5 minutes as a target cycle, or one hour as a target cycle. The target cycle can also be a fixed period, for example, the target cycle is a CKPT cycle, or the target cycle includes multiple CKPT cycles.

[0010] When a user needs to restore a database, they send a second flashback command. This second flashback command carries the specified time to restore. The specified time can be the time the flashback function is enabled, or any time after the flashback function is enabled; this is not limited here. After receiving the second flashback command, the data processing device performs a flashback operation on the database. Specifically, based on the specified time carried in the second flashback command, the corresponding target page is determined from the first page of the flashback log record. For example, if the specified time is 9:00 AM, the database needs to be restored to its state at 9:00 AM. The flashback log then locates the target page with the closest recorded time to 9:00 AM. A flashback operation is performed on the target page, restoring the data to the state of the target page. Subsequently, a replay is performed based on the redo log, restoring the database to its state at the specified time. The closer the page's recorded time is to the specified time, the shorter the time required for subsequent replay based on the redo log. Uncommitted transactions are then rolled back using undo data.

[0011] In the first aspect of the present application, only the first modification to the first page within a target period is recorded in the flashback log. That is, for a modified first page, only one copy of the initial page is recorded within the target period, and subsequent modified versions within the target period are not recorded, thereby effectively reducing disk space overhead. Furthermore, recording only one copy of the initial page within the target period also results in fewer versions of the page being recorded in the flashback log, allowing for quick identification of the corresponding target page and reducing the duration of database flashbacks.

[0012] In a possible implementation of the first aspect, the target cycle is the checkpoint (CKPT) cycle in which the first page is modified for the first time after receiving the first flashback instruction. That is, the first page will only be recorded in the first CKPT cycle in which the first page is modified after receiving the first flashback instruction, and the first page is the original page after receiving the first flashback instruction. In other words, even if the first page is modified in multiple CKPT cycles after receiving the first instruction, or is modified multiple times in one CKPT cycle, only the first page before the first modification (i.e., the original page) is recorded in the flashback log.

[0013] In this possible implementation, for multiple modifications to a page, only one copy of the original page is recorded, significantly saving disk space. Furthermore, since only the original page is recorded, the process of searching through multiple historical versions for the page at a given moment is reduced, significantly improving flashback speed.

[0014] In a possible implementation of the first aspect, the target cycle is a single checkpoint cycle, and the flashback log includes multiple first pages, where each first page corresponds to a checkpoint cycle. That is, in each CKPT cycle in which a modification operation is performed on the first page, the first page is recorded in the flashback log before the first modification is performed on the first page within the CKPT cycle. In other words, for each CKPT cycle in which a modification operation is performed on the first page, a copy of the initial page of the first page in the cycle is recorded in the flashback log, and the flashback log includes multiple versions of the first page, each of which corresponds to a CKPT cycle.

[0015] In this possible implementation, for multiple modifications to the first page within a CKPT cycle, only the changes before the first modification within that CKPT cycle are recorded in the flashback log. This means that only one copy of the page is recorded per CKPT cycle, reducing disk space usage. Furthermore, because a copy of the page is recorded for each CKPT cycle in which a modification occurs, it is possible to find a version of the page that is closer to the user-specified time point, allowing the database to be quickly restored to its state at the specified time.

[0016] In a possible implementation of the first aspect, the target cycle includes N checkpoint cycles, and the flashback log includes multiple first pages, wherein each first page corresponds to N checkpoint cycles, and N is an integer greater than 1. That is, in every N CKPT cycles in which the first page has a modification operation, the first page will only be recorded in the flashback log before the first modification is performed on the first page for the N CKPT cycles. In other words, a copy of the first page will be recorded in the flashback log every N CKPT cycles, and the flashback log will include multiple versions of the first page, each copy of the first page corresponds to N CKPT cycles. Exemplarily, if N is 5, only one initial page (i.e., the first page itself) will be recorded in every 5 CKPT cycles.

[0017] In this possible implementation, compared to recording a first page in every CKPT cycle, recording only one first page over multiple CKPT cycles can further save disk space. Furthermore, compared to recording an initial page only in the first modified CKPT cycle, recording an initial page every N CKPT cycles can help find a version page closer to the user-specified time point, thereby reducing replay time.

[0018] In a possible implementation of the first aspect, the above steps of: restoring the database to a state at a specified time based on a flashback log and a redo log of the database, include: constructing a quick search structure in an index structure based on multiple first pages; determining a target page corresponding to a specified time from the multiple first pages based on the quick search structure; and restoring the database to a state at the specified time based on the target page and the redo log.

[0019] When the target period is a single CKPT cycle or N CKPT cycles, the first page may have multiple versions recorded in the flashback log. For example, when the target period is a single CKPT cycle, if page A is modified in 20 CKPT cycles, the flashback log will record 20 versions of page A. To find the target page among these 20 versions, the current industry-wide solution is to read pages sequentially until the required version is found, which is time-consuming.

[0020] In this possible implementation, a fast search structure is constructed to quickly identify the target page from multiple versions. Specifically, an index structure is created for the multiple versions recorded in the flashback log. The index structure can be a linked list or a balanced tree (B-tree). The balanced tree can be a B-tree, B* tree, or B+ tree. The index structure provides a directory-like effect, allowing the target page to be quickly identified from multiple pages.

[0021] In a possible implementation of the first aspect, after receiving the first flashback instruction, the method further includes recording logs between a recovery point (RCY) and a least recovery point (LRP) in the redo log into a flashback log.

[0022] In this possible implementation, the redo logs from the RCY point to the LRP point are recorded in the flashback log. In this way, even if the redo log archive is cleared, the redo operation can be replayed based on the redo logs cached in the flashback log, ensuring the stability of the solution.

[0023] In a possible implementation of the first aspect, the method further includes: modifying the first page to obtain a second page; and flushing the second page to disk. The second page that has not yet been flushed to disk is referred to as a dirty page and is placed in a dirty page queue. When a flush operation is to be performed, the second page is retrieved from the dirty page queue and written to disk.

[0024] In a possible implementation of the first aspect, the above step: recording the page to the flashback log includes: copying the page to the flashback buffer; recording the page from the flashback buffer to the flashback log; the above step: before writing the second page to the disk, the method also includes: checking whether the first page exists in the flashback buffer; if so, writing the first page from the flashback buffer to the flashback log.

[0025] To ensure that the database can perform flashback operations normally, before writing the second page to disk, the system first checks whether the corresponding first page still exists in the flashback buffer. If so, it indicates that the first page has not been recorded in the flashback log. In this case, the system reads the first page from the flashback buffer and writes it to the flashback log, thus fully ensuring that the initial page has been recorded in the flashback log.

[0026] In one possible implementation of the first aspect, modifying the first page and recording the first page in the flashback log are performed in parallel. That is, flushing the flashback log to disk and modifying and writing the page to disk are asynchronous. Multi-threaded asynchronous operation does not block database operations, thereby ensuring that database performance is not degraded.

[0027] A second aspect of the present application provides a data processing device comprising a receiving unit, a recording unit, and a recovery unit. The receiving unit is configured to receive a first flashback instruction; the recording unit is configured to, in response to the first flashback instruction, record the first page in the database in a flashback log before the first modification to the first page in the target cycle; the receiving unit is further configured to receive a second flashback instruction; and the recovery unit is configured to, in response to the second flashback instruction, restore the database to a state at a specified time based on the flashback log and the database's redo log.

[0028] In a possible implementation manner of the second aspect, the target cycle is a checkpoint cycle in which the first page is modified for the first time after receiving the first flashback instruction.

[0029] In a possible implementation manner of the second aspect, the target cycle is a single checkpoint cycle, and the flashback log includes multiple first pages, where each first page corresponds to a checkpoint cycle.

[0030] In a possible implementation of the second aspect, the target cycle includes N checkpoint cycles, and the flashback log includes multiple first pages, where each first page corresponds to N checkpoint cycles, and N is an integer greater than 1.

[0031] In a possible implementation of the second aspect, the recovery unit is specifically used to: construct a quick search structure in an index structure based on multiple first pages; determine the target page corresponding to a specified time from the multiple first pages based on the quick search structure; and restore the database to the state at the specified time based on the target page and the redo log.

[0032] In a possible implementation of the second aspect, the recording unit is further configured to record logs between the recovery point and the minimum recovery point in the redo log into a flashback log.

[0033] In a possible implementation of the second aspect, the device further includes: a modification unit, configured to modify the first page to obtain a second page; and a disk storage unit, configured to store the second page on a disk.

[0034] In a possible implementation of the second aspect, the recording unit is specifically used to: copy the page to the flashback buffer; record the page from the flashback buffer to the flashback log; the device also includes: a checking unit, used to check whether the first page exists in the flashback buffer; and a writing unit, used to write the first page from the flashback buffer to the flashback log if the first page exists.

[0035] In a possible implementation of the second aspect, modifying the first page and recording the first page in the flashback log are parallel operations.

[0036] The data processing device provided in the second aspect of the present application is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0037] A third aspect of the present application provides a data processing device, comprising a processor and a memory, wherein the memory is used to store instructions, and the processor is used to obtain the instructions stored in the memory to execute the method described in the first aspect or any possible implementation of the first aspect.

[0038] A fourth aspect of the present application provides a computer-readable storage medium, which includes instructions. When the instructions are executed on a computer, the computer executes the method described in the first aspect or any possible implementation of the first aspect.

[0039] A fifth aspect of the present application provides a computer program product comprising instructions, which, when run on a computer, enables the computer to execute the method described in the first aspect or any possible implementation of the first aspect.

[0040] In a sixth aspect, the present application provides a chip system, comprising at least one processor and a communication interface, wherein the communication interface and the at least one processor are interconnected via lines, and the at least one processor is used to run a computer program or instruction to execute the method described in the first aspect or any possible implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] FIG1 is a schematic diagram of the architecture of a database system used in an embodiment of the present application;

[0042] FIG2 is a schematic diagram of an embodiment of a data processing method provided in an embodiment of the present application;

[0043] FIG3 is a schematic diagram of another embodiment of the data processing method provided in an embodiment of the present application;

[0044] FIG4 is a schematic diagram of an embodiment of enabling flashback point flashback in the embodiment of the present application;

[0045] FIG5 is a schematic diagram of an embodiment of enabling time point flashback in an embodiment of the present application;

[0046] FIG6 is a schematic diagram of an embodiment of the data processing method provided in an embodiment of the present application in a database upgrade scenario;

[0047] FIG7 is another schematic diagram of the architecture of the database system used in the embodiment of the present application;

[0048] FIG8 is a schematic diagram of an embodiment of the data processing method provided by the present application in a misoperation recovery scenario;

[0049] FIG9 is a schematic structural diagram of a data processing device provided in an embodiment of the present application;

[0050] FIG10 is another schematic diagram of the structure of the data processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] Embodiments of the present application provide a data processing method that can implement database flashback functionality while effectively reducing disk space overhead and shortening the time required for flashback. Embodiments of the present application also provide corresponding devices, computer-readable storage media, and computer program products. These are described below.

[0052] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present application, rather than all the embodiments. Those skilled in the art will appreciate that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0053] The terms "system" and "network", "redo log" and "redo log", "rollback data" and "undo data" in the specification and claims of this application and the above-mentioned drawings can be used interchangeably. Unless otherwise specified, ordinal numbers such as "first" and "second" are used to distinguish multiple objects and are not used to limit the order, timing, priority or importance of multiple objects. It should be understood that the terms used in this way are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0054] To facilitate understanding, the following first introduces the relevant terms and concepts mainly involved in the embodiments of this application.

[0055] 1. Checkpoint

[0056] A checkpoint (CKPT) is a database event. After a modification operation is performed during the CKPT period, the dirty page is placed in a dirty page queue. Subsequently, the dirty page is removed from the dirty page queue and written to disk.

[0057] 2. Database Flashback Technology

[0058] Database flashback technology is a full database flashback technology that can restore the database to a specific point in time or a specific transaction end point. By using database flashback technology, you can undo incorrect operations on the database or restore it to a previous state.

[0059] 3. Page

[0060] A page is the smallest unit for managing data in the storage engine. All data inserted into the database is stored in a page.

[0061] 4. Restore Point

[0062] A recovery point (RCY) is a point in the database logbook where all changes prior to this point have been applied to the database. Changes after this point in time must be restored through a recovery operation. Recovery points are commonly used in database backup and recovery operations. During recovery, the database is replayed starting from the RCY point.

[0063] 5. Minimum recovery point

[0064] The least recovery point (LRP) is a log point in a database where the database is restored to a consistent state after all redo logs prior to that point have been replayed. LRPs are commonly used for database failure recovery and transaction rollback operations.

[0065] 6.X Lock

[0066] An exclusive lock (X lock) is a database locking mechanism. Its characteristics are as follows: Exclusivity: After a transaction acquires an X lock, other transactions cannot simultaneously acquire an X lock or an S lock. This means that only one transaction can write to the locked resource; other transactions must wait for the first transaction to release the lock. Write operations: A transaction that has acquired an X lock can read and modify the locked resource. Blocking: If a transaction holds an X lock and another transaction requests an X lock or an S lock, the requesting transaction will be blocked until the holding transaction releases the lock. X locks are used in the following scenarios: Modification operations: When a transaction needs to modify a resource, it needs to acquire an X lock to ensure that other transactions cannot modify the resource simultaneously. Data consistency: By acquiring an X lock, other transactions cannot read inconsistent data during the modification operation.

[0067] 7. Balanced Tree

[0068] A balanced tree (B-tree), also known as a B-tree, is a self-balancing tree that keeps data in order. This data structure enables data lookups, sequential access, insertions, and deletions in logarithmic time. A B-tree is essentially a generalized binary search tree that can have more than two children. Unlike a self-balancing binary search tree, a B-tree is optimized for reading and writing large blocks of data. It reduces the number of intermediate steps required to locate a record, thereby speeding up access.

[0069] Database flashback is a database recovery technique that restores a database to its previous state. Currently, the industry generally uses physical backups to achieve a similar effect. A physical backup copies the current database data, using the copied data to rebuild the database when a flashback is needed. Because physical backups copy all the database data at the current moment, they require a significant amount of disk space, take up a similar amount of time to restore, and only restore the database to its state at the time the physical backup was made (data generated after the backup is not recorded).

[0070] To address these issues, the industry has proposed several solutions, such as enabling database flashback through rollback data (undo data) and flashback through physical backups combined with point-in-time recovery (PITR). Flashback solutions using undo data include an undo module and a flashback module. During business execution, the undo module is responsible for recording the database's undo data. When a flashback command is required, the flashback module selects the corresponding data from the undo data and flashes the database back to the specified time based on the data. Because undo data records every moment of database data change, it effectively implements flashback and allows recovery to any point in time where undo data is recorded. However, when business is busy, data changes can be significant, requiring the recording of large amounts of undo data, which in turn consumes significant disk space. Furthermore, a page often has multiple historical versions, and selecting the page at the corresponding moment from these numerous historical pages consumes considerable time, resulting in a longer flashback time.

[0071] Flashback through physical backup combined with PITR is an enhanced implementation of physical backup. Specifically, a physical backup is first used to back up the current data, followed by continuous recording of redo logs to log files. When the flashback command is executed, the database is rebuilt based on the backup data, restoring the data at the time of the backup. The recorded logs are then replayed to restore the database to the specified time. This solution allows flashback to any point in time, but because physical backups are also required, it does not address the issues of high space usage and long backup and restore times.

[0072] In view of this, an embodiment of the present application provides a data processing method, which records a database page only before the first modification of the page within the target cycle. The database can be flashed back to the state before the first modification through the recorded page, and then the database can be restored to the state at a specified time by replaying the page in combination with the redo log. In other words, even if the page is modified multiple times within the target cycle, only the initial page of the page in the target cycle is recorded. For pages that have not been modified within the target cycle, there is no need to record them, so that the flashback function of the database can be implemented with very little disk space overhead. In addition, since only one page is recorded within the target cycle, the required page can be quickly determined when flashing back, thereby reducing the duration of the database flashback and improving the efficiency of the flashback.

[0073] It is understandable that the data processing method provided in the embodiment of the present application can be applied to various databases, such as MySQL, Oracle, and SQL Server, etc. For the convenience of description, the embodiment of the present application takes MySQL as an example for description, without specific limitation.

[0074] Please refer to Figure 1 below, which is a schematic diagram of the architecture of the database system used in the embodiment of the present application.

[0075] As shown in Figure 1, the database system is deployed in a database server and specifically includes a software part and a hardware part. The hardware part is a disk, which is the physical medium for storing data in the database. The software part is the database platform software, which is used to manage data files on the disk, including operations such as reading, writing, updating and deleting data. The database platform software includes a storage engine, and the program code for implementing the embodiment of the present application is present in the storage engine. The storage engine includes a flashback module, which is used to implement the flashback function of the database. Specifically, the flashback module can be subdivided into a flashback log submodule and a flashback recovery submodule. After the flashback function is turned on, for the page that is modified for the first time within the target cycle, the flashback log submodule records its corresponding initial page within the target cycle (i.e., the page before the first modification) in the flashback log. When executing the flashback instruction, the flashback recovery submodule performs a flashback operation on the database according to the initial page recorded in the flashback log.

[0076] It should be noted that the target period can be any specified period of time, for example, 5 minutes as a target period, or one hour as a target period. The target period can also be a fixed period, for example, the target period is one CKPT period, or the target period includes multiple CKPT periods. To make the solution clearer, the embodiments of the present application are described as an example of a target period of one CKPT period or including multiple CKPT periods, without specific limitation.

[0077] Based on the system architecture shown in Figure 1, the overall process of the embodiment of the present application is described below in conjunction with Figure 2. As shown in Figure 2, the overall process includes a page modification thread, a dirty page disk write thread, and a flashback thread for recording the initial page. Optionally, the dirty page disk write thread can also be used to ensure that the initial page has been recorded in the flashback log. Among them, steps 201 and 202 are the business logic of the modification thread, steps 203 and 204 are the business logic of the disk write thread when writing dirty pages to disk, steps 205 to 207 are the business logic of the flashback thread, and steps 208 and 209 are the business logic of the disk write thread to ensure that the initial page is recorded in the flashback log. Writing to disk means writing data to the disk, and the process from page modification to writing to disk is a CKPT cycle, that is, steps 201 to 204 are a CKPT cycle. It should be understood that within a CKPT cycle, there are usually many pages to be modified and written to disk, and a page can be modified multiple times. Each step is described below.

[0078] 201. The modifying thread reads the first page from disk using an X lock. A transaction that acquires an X lock can read and modify the locked resource and ensures that other transactions cannot modify the page simultaneously. A transaction is a complete logical process consisting of a series of database operations.

[0079] 202. The modification thread modifies the first page to obtain the second page. Pages that have not been written to disk after modification can be called dirty pages. Pages are not written to disk immediately after modification, but are written to disk in a centralized manner at the end of a CKPT cycle. The modified pages are first cached in a dirty page queue. There are usually multiple dirty pages in the dirty page queue. For example, in Figure 2, the dirty page queue includes pages 1-10, pages 2-3, and pages 3-7. Among them, page 1-10 is the 10th page of file 1, page 2-3 is the 3rd page of file 2, and page 3-7 is the 7th page of file 3.

[0080] After modifying the first page to obtain the second page, the modification thread puts the second page into the dirty page queue.

[0081] 203. When a dirty page is to be written to disk, the writing thread extracts the second page from the dirty page queue.

[0082] 204. The disk write thread writes the second page to the disk.

[0083] 205. Before the first modification of the first page within the target cycle, the flashback thread copies the first page to the flashback buffer. The flashback thread does not process modifications to the first page after the first modification within the target cycle. In other words, for multiple modifications to the first page within the target cycle, the flashback thread only records the page before the first modification (i.e., the initial page within the target cycle). For example, if page B is modified three times, the flashback log will only copy the initial page of page B within the target cycle to the flashback buffer.

[0084] The target cycle can be one CKPT cycle, or it can include multiple CKPT cycles, such as two CKPT cycles or five CKPT cycles. That is, the flashback log only records the first page before the first modification of the first page within one CKPT cycle, or only records the first page before the first modification of the first page within multiple CKPT cycles. Assuming that the first page will be modified in each CKPT cycle, when the target cycle is one CKPT cycle, one first page will be recorded in each CKPT cycle. The first page recorded at this time is the initial page of the first page in each CKPT cycle, and five pages will be recorded in five CKPT cycles. When the target cycle is multiple (for example, five) CKPT cycles, only one first page will be recorded in five CKPT cycles. The first page recorded at this time is the initial page of the first page in the first CKPT cycle. Therefore, compared to a target cycle of a single CKPT cycle, a target cycle of multiple CKPT cycles can further save disk space overhead, but it usually takes more time to replay based on the redo log.

[0085] It is understandable that step 205 and step 202 can be performed simultaneously. That is, the modification operation of the first page and the copy operation of the first page are asynchronous mechanisms, and the modification thread and the flashback thread can be executed in parallel.

[0086] 206. The flashback thread reads the first page from the flashback buffer. After the first page is read, the first page no longer exists in the flashback buffer.

[0087] 207. The flashback thread records the first page in the flashback log. Both the flashback log and the redo log are stored on disk.

[0088] 208. The flushing thread checks whether the dirty page to be flushed (i.e., the second page) has a corresponding initial page (i.e., the first page) in the flashback buffer. Typically, a CKPT cycle is long, and by the time the second page is flushed, the first page in the flashback buffer has already been recorded in the flashback log by the flashback thread. However, it is also possible that the first page has not been flushed. In view of this, before flushing the second page (i.e., step 204), the flushing thread first checks whether the first page corresponding to the second page still exists in the flashback buffer. If not, it means that the first page has been recorded in the flashback log, and step 204 is executed. If so, step 209 is executed.

[0089] 209. The write-to-disk thread triggers the flashback thread to record the first page in the flashback log (i.e., steps 206 and 207). After the flashback thread executes, the write-to-disk thread continues to execute step 204, thereby fully ensuring that the initial page is recorded in the flashback log, thereby ensuring the normal implementation of the database flashback function.

[0090] In conjunction with the overall flow chart shown in Figure 2, please refer to Figure 3 below, which is a schematic diagram of an embodiment of the data processing method provided in the application embodiment. As shown in Figure 3, this embodiment includes steps 301 to 306.

[0091] 301. Receive a first flashback instruction.

[0092] When the user chooses to enable the flashback function, a first flashback instruction is issued.

[0093] 302. In response to a first flashback instruction, before modifying a first page in a database for the first time within a target cycle, record the first page in a flashback log.

[0094] After receiving the first flashback instruction, the data processing device uses the flashback thread to record the pre-modification page for the page to be modified (i.e., the page read via the X-lock). Specifically, within the target cycle, the first page to be modified is recorded in the flashback log only before the first modification. In other words, even if the first page is modified multiple times within the target cycle, only one copy of the initial page is recorded. Pages that were not modified within the target cycle are not processed. It should be noted that the specific process for recording the first page is to first copy the first page to the flashback buffer, then read the first page from the flashback buffer and record it in the flashback log. After the first page is read from the flashback buffer, it no longer exists in the flashback buffer.

[0095] In one possible solution, the target cycle is the CKPT cycle in which the first page is modified for the first time after receiving the first flashback instruction. In other words, the first page at this time is the original page after receiving the first flashback instruction. This possible solution can be applied to scenarios where the database needs to be restored to the time when flashback was enabled. For example, a user issues the first instruction before upgrading the system, and an error occurs during the system upgrade. In this case, the database can be quickly restored to its state before the system upgrade using the original page before the system upgrade recorded in the flashback log.

[0096] In another possible solution, the target cycle is a single CKPT cycle. That is, in each CKPT cycle in which the first page has a modification operation, the first page will be recorded in the flashback log before the first page is modified for the first time in the CKPT cycle. In other words, for each CKPT cycle in which the first page has a modification operation, a copy of the initial page of the first page in the cycle will be recorded in the flashback log. The flashback log will include multiple versions of the first page, and each first page corresponds to a CKPT cycle. In this possible solution, the flashback log records the initial page of the first page in each CKPT cycle, so that the page for restoring the database that is closer to the user-specified time point can be found, and the database can be quickly restored to the state at the specified time.

[0097] In another possible solution, the target cycle includes N CKPT cycles, where N is an integer greater than 1. That is, in every N CKPT cycles in which the first page has a modification operation, the first page will only be recorded in the flashback log before the first page is modified for the first time within the N CKPT cycles. In other words, a first page will be recorded in the flashback log for every N CKPT cycles, and the flashback log will also include multiple versions of the first page, each first page corresponding to N CKPT cycles. Exemplarily, if N is 5, only an initial page (i.e., the first page itself) will be recorded in every 5 CKPT cycles. Compared with recording a first page in each CKPT cycle, recording a first page in multiple CKPT cycles can further save the cost of disk space. However, it may also cause the first page recorded in the flashback log to be separated from the time point specified by the user by a long time, thereby requiring longer time to perform database recovery.

[0098] It is understandable that the user can also adjust the value of N during the operation of the flashback function. For example, when the user turns on the flashback function, N is set to 3, that is, a copy of the first page is recorded every 3 CKPT cycles. During the operation of the flashback function, N can be adjusted to 5, that is, a copy of the first page is recorded every 5 CKPT cycles. Alternatively, it can be combined with a solution in which the target cycle is a single CKPT cycle. For example, when the flashback function is just turned on, it is more likely to perform a database flashback operation, and an initial page will be recorded in each CKPT cycle during this part of the CKPT cycle. In subsequent CKPT cycles, an initial page is recorded every N CKPT cycles, which can not only improve the speed of database recovery but also reduce the occupied disk space.

[0099] 303. Modify the first page.

[0100] After reading the first page from disk using an X lock, the first page is modified to obtain the second page. Pages that have been modified but not yet flushed to disk are called dirty pages. Pages are not flushed immediately after modification but are instead flushed collectively at the end of a CKPT cycle. Modified pages are first cached in a dirty page queue. The dirty page queue typically contains multiple dirty pages.

[0101] After the first page is modified to obtain the second page, the second page is put into the dirty page queue.

[0102] 304. Save the second page to disk.

[0103] When flushing is to be performed, the second page is taken from the dirty page queue and written to disk.

[0104] Optionally, to ensure that the database can perform flashback operations normally, before writing the second page to disk, a check is performed to determine whether the corresponding first page still exists in the flashback buffer. If so, indicating that the first page has not been recorded in the flashback log, the data processing device executes the flashback thread to read the first page from the flashback buffer and write it to the flashback log, thereby fully ensuring that the initial page has been recorded in the flashback log.

[0105] It should be noted that modifying the first page and recording it in the flashback log can be performed in parallel. That is, steps 303 and 304 (i.e., modifying and writing the page to disk) and steps 301 and 302 (i.e., flushing the flashback log to disk) operate asynchronously. Multi-threaded asynchronous operation does not block database operations, thereby ensuring that database performance is not degraded.

[0106] 305. Receive a second flashback instruction.

[0107] After the user enables the flashback function, when the database needs to be restored, a second flashback command is sent. The second flashback command will carry the time point to be restored.

[0108] 306. In response to the second flashback instruction, restore the database to a state at a specified time based on the flashback log and the database redo log.

[0109] After receiving the second flashback instruction, the data processing device performs a flashback operation on the database. Specifically, the corresponding target page is determined from the flashback log based on the specified time carried in the second flashback instruction. For example, the specified time is nine o'clock in the morning, that is, the database needs to be restored to the state at nine o'clock in the morning. At this time, the target page with the recording time closest to nine o'clock in the morning is found from the flashback log, and the flashback operation is performed based on the target page to restore the data to the state of the target page. Subsequently, the data is replayed based on the redo log, thereby restoring the database to the state at the specified time. The closer the recording time of the page is to the specified time, the shorter the time required for subsequent replay based on the redo log. It should be noted that in an embodiment of the present application, if there are uncommitted transactions during the flashback operation, a rollback operation is also required using undo data.

[0110] It should be understood that the pages that need to be restored are the numerous pages that have been modified before the specified time, and the target page is a version of each of the numerous pages that is closest to the specified time.

[0111] Optionally, when the target cycle is a single CKPT cycle or N CKPT cycles, the first page may have multiple versions recorded in the flashback log. For example, when the target cycle is a single CKPT cycle, if page A is modified in 20 CKPT cycles, the flashback log will record 20 versions of page A. To find the target page from these 20 versions, the current industry-wide solution is to read the pages sequentially until the required version is found, which is time-consuming.

[0112] To quickly identify a target page from multiple versions, this embodiment proposes a fast search structure. Specifically, an index structure is established for multiple versions of a page. The index structure can be a linked list or a balanced tree. The balanced tree can be a B-tree, B* tree, or B+ tree. The index structure provides a directory-like effect, allowing the desired target page to be quickly identified from multiple pages.

[0113] Optionally, to ensure database consistency, the redo logs from the RCY point to the LRP point are recorded in the flashback log. This way, even if the redo log archive is cleared, the operation can be replayed based on the redo logs cached in the flashback log, ensuring the stability of the solution.

[0114] It is understandable that steps 305 and 306 can occur before step 304, that is, flashback is performed according to the flashback log before the modified page is written to the disk. After the flashback, there is no need to execute step 304 to write the dirty pages in the CKPT cycle to the disk.

[0115] In this embodiment, the first page is recorded in the flashback log only before it is modified for the first time within the target period. Based on this first page, the database can be flashed back to the state before the page was first modified within the target period, and then replayed according to the redo log, so that the database can be quickly restored to the state at a specified time. Since only one copy of the initial page with the modified page is recorded within the target period, disk space overhead can be greatly saved. In addition, recording only one copy of the initial page within the target period also means that the number of historical versions of the page recorded in the flashback log is relatively small, so the required target page can be quickly determined, improving the rate of database flashback. In addition, in this embodiment, a fast search structure is constructed using a linked list or a balanced tree, which can further improve the speed of finding the target page, thereby further improving the efficiency of database flashback. Moreover, recording the first page in the flashback log and modifying the first page can be performed in parallel, thereby ensuring that the database business performance is not reduced.

[0116] As can be seen from the embodiment shown in Figure 3, when the target cycle is the CKPT cycle in which the first page is modified for the first time after receiving the first flashback instruction, the database can be flashed back to the flashback function activation moment. When the target cycle is a single CKPT cycle or multiple CKPT cycles, the database can be flashed back to any specified moment. Thus, the flashback function in the embodiment of the present application can be divided into two categories, or in other words, the embodiment of the present application provides two interfaces for the flashback function. One is flashback point flashback, under which the database can be restored to the state of the flashback function activation moment (i.e. the moment when the user sends the first instruction), and only the initial page in the first CKPT cycle with the modification operation needs to be recorded, which can greatly reduce the disk space occupied. The other is time point flashback, under which the database can be quickly restored to the state of any time point after the flashback moment is activated. It is understandable that the flashback point flashback function can actually restore the database to the state of any time point, i.e. after flashing back to the flashback function activation moment, it can be replayed according to the redo log, but this will take more time. The time point flashback function can also be used to restore the database to the state at the time when the flashback function is turned on, that is, find the page before the first modification of the first page recorded in the flashback log after the flashback function is turned on (that is, the original page), and then restore the database to the state before the first modification based on the original page. The state before the first modification is the state at the time when the flashback function is turned on. Although the flashback point flashback function can also be realized through the time point flashback, in the scenario where only the flashback function needs to be restored to the point where the flashback function is turned on, this will cause additional disk space overhead and will consume more time. The flashback point flashback function can be applied to database upgrade scenarios, and the time period flashback function can be applied to scenarios that are attacked from the outside or scenarios where operations are recovered from errors. In the embodiments of the present application, there is no specific limitation on the functions of these two interfaces.

[0117] The following describes these two interfaces in conjunction with Figures 4 and 5. Please refer to Figure 4, which is a schematic diagram of an embodiment of the flashback point flashback function. As shown in Figure 4, this embodiment includes steps 401 to 405.

[0118] 401. The user sends a first flashback instruction to enable a flashback point flashback function.

[0119] 402. After receiving the first flashback instruction, the data processing device records the redo log between the RCY point and the LRP point in the flashback log. In this way, even if the redo log archive is cleared, the replay operation can be performed based on the redo log cached in the flashback log, thereby ensuring the stability of the solution.

[0120] 403. Before modifying the first page for the first time after receiving the first flashback instruction, record the first page in the flashback log. That is, for a page that has been modified, only one copy of the original page is recorded in the flashback log.

[0121] 404. The user sends a second flashback instruction. In response to the second flashback instruction, the data processing device flashes back the page in the database to the state before the first modification based on the first page recorded in the flashback log.

[0122] 405. The database is then replayed based on the relevant redo logs to achieve a consistent state. The relevant redo logs can be read from flashback logs or redo logs. Uncommitted transactions are then rolled back using undo data.

[0123] In this embodiment, only one copy of the original page is recorded for multiple modifications to a page, effectively reducing space overhead. In scenarios where large databases are frequently modified, this approach can save over 90% of space compared to the previously described solution for implementing database flashback based on undo data. It can also save over 99% of space compared to the previously described solution of combining physical backup with PITR.

[0124] Moreover, in this embodiment, only one original version is recorded for a page, and there is no need to construct a historical page. The recorded original page is the target page, thereby reducing the process of determining the target page from multiple historical versions, which can greatly improve the flashback speed. Compared with the above two solutions (i.e., flashback based on undo data and flashback based on physical backup combined with PITR), more than 90% of the time can be saved.

[0125] Please refer to FIG5 , which is a schematic diagram of an embodiment of the time point flashback function. As shown in FIG5 , this embodiment includes steps 501 to 505 .

[0126] 501. The user sends a first flashback instruction to enable a point-in-time flashback function.

[0127] 502. After receiving the first flashback instruction, before the first page is modified for the first time within a single CKPT cycle, or before the first page is modified within N CKPT cycles, the first page is recorded in the flashback log. That is, after receiving the first flashback instruction, a copy of the initial page is recorded for each CKPT cycle in which the first page is modified, or a copy of the initial page is recorded for each N CKPT cycles in which the first page is modified.

[0128] 503. As can be seen from step 502, multiple different versions of the first page are recorded, corresponding to different CKPT periods. To quickly find the target page corresponding to the user-specified time, a fast search structure is constructed using a linked list or balanced tree. The linked list or balanced tree includes multiple versions of a page and can provide a directory-like function, allowing the target page to be quickly determined from multiple versions.

[0129] 504. The user sends a second flashback instruction. In response to the second flashback instruction, the data processing device flashes back the page in the database to the state of the target page.

[0130] 505. The redo log is then used to replay the transaction, bringing the database to a consistent state. Uncommitted transactions are rolled back using undo data.

[0131] In this embodiment, regardless of how many times the first page is modified during each CKPT cycle or every N CKPT cycles, only one copy of the initial page is recorded during each CKPT cycle or every N CKPT cycles, thereby effectively reducing space overhead. In scenarios where large databases are frequently modified, compared to the previously described solution for implementing database flashback based on undo data, over 50% of space can be saved. Compared to the previously described solution of combining physical backup with PITR, over 99% of space can be saved.

[0132] Recording a copy of the initial page every CKPT cycle or every N CKPT cycles significantly reduces the number of page versions, thereby shortening flashback duration. Furthermore, this embodiment also constructs a fast search structure to further improve flashback speed. Compared to the two aforementioned solutions (flashback based on undo data and flashback based on physical backup combined with PITR), both can save over 90% of time.

[0133] In conjunction with the above, a typical application scenario of an embodiment of the present application is described below. Please first refer to Figure 6, which illustrates the application of the flashback point flashback function in an offline database upgrade scenario. In this scenario, when a database upgrade fails, the database can be quickly flashed back to its state before the upgrade. The embodiment shown in Figure 6 can be applied to the system architecture shown in Figure 1. As shown in Figure 6, this embodiment includes steps 601 to 606.

[0134] 601. Shut down the database software and replace the database software files (binary replacement).

[0135] 602. Pull up the database to the running state.

[0136] 603. Send a first flashback instruction to enable a flashback point flashback function.

[0137] 604. Execute the database upgrade process to complete the upgrade.

[0138] 605. During the upgrade process, if an error occurs or the upgrade fails, the page in the database will be flashed back to the state before the first modification through the flashback point flashback function.

[0139] 606. After shutting down the database software, replace the database software files (binary replacement of the old version) and restart the database.

[0140] Please refer to Figures 7 and 8 below, which illustrate the application of the point-in-time flashback feature in a primary-backup dual-machine error recovery scenario. In this scenario, when a logical operation error occurs in the database, the database can be quickly flashed back to the state at a specified time. The embodiment shown in Figure 8 can be applied to the system architecture shown in Figure 7. The system architecture shown in Figure 7 will be described below.

[0141] As shown in Figure 7, the database system includes two database servers: a primary database server and a standby database server. The primary database server is used to execute database operations, while the standby database server serves as a disaster recovery backup for the primary database server. Compared to the system architecture shown in Figure 1, the database system shown in Figure 7 adds a high availability (HA) module to both the primary and standby database servers. The HA module enables the transmission of redo logs and acknowledgment (ACK) messages, thereby ensuring consistency between the primary and standby servers. The remaining modules of the database system shown in Figure 7 are similar to the system architecture shown in Figure 1 and will not be further described here.

[0142] The application of the point-in-time flashback function in the scenario of recovering from an erroneous operation of a primary and backup dual-machine system will be described below with reference to Figure 8. As shown in Figure 8, this embodiment includes steps 801 to 806.

[0143] 801. To minimize the impact on services on the primary database server, enable the point-in-time flashback feature only on the standby database server. Alternatively, you can enable the point-in-time flashback feature on both the primary and standby servers. This is not a limitation here.

[0144] 802. Execute business logic on the primary database server.

[0145] 803. The standby database server receives the redo log transmitted by the primary database server through the HA module, and performs data synchronization based on the redo log.

[0146] 804. When a business logic error occurs in the main database server, shut down the main database server.

[0147] 805. Specify a time point before the error occurs for the standby database server, and flash back the standby database server to the state before the error occurs using a time point flashback function.

[0148] 806. Convert the standby database server to the primary database server to continue business processing, thereby ensuring business continuity.

[0149] The above describes the embodiments of the present application from the perspective of the method. The following describes the relevant devices in the embodiments of the present application from the perspective of specific device implementation.

[0150] Please refer to FIG. 9 , which is a schematic diagram of a data processing device 900 provided in an embodiment of the present application. The data processing device 900 includes a receiving unit 901 , a recording unit 902 , and a recovery unit 903 .

[0151] The receiving unit 901 is configured to receive a first flashback instruction.

[0152] The recording unit 902 is configured to record the first page in the database into a flashback log in response to the first flashback instruction before the first page in the database is modified for the first time within a target cycle.

[0153] The receiving unit 901 is further configured to receive a second flashback instruction.

[0154] The recovery unit 903 is configured to respond to the second flashback instruction and restore the database to a state at a specified time based on the flashback log and the redo log of the database.

[0155] Optionally, the target cycle is a checkpoint cycle in which the first page is modified for the first time after receiving the first flashback instruction.

[0156] Optionally, the target cycle is a single checkpoint cycle, and the flashback log includes multiple first pages, where each first page corresponds to a checkpoint cycle.

[0157] Optionally, the target cycle includes N checkpoint cycles, and the flashback log includes multiple first pages, where each first page corresponds to N checkpoint cycles, and N is an integer greater than 1.

[0158] Optionally, the recovery unit 903 is specifically used to build a quick search structure in an index structure based on multiple first pages; determine the target page corresponding to a specified time from the multiple first pages based on the quick search structure; and restore the database to the state at the specified time based on the target page and the redo log.

[0159] Optionally, the recording unit 902 is further configured to record the logs between the recovery point and the minimum recovery point in the redo log into the flashback log.

[0160] Optionally, the data processing device 900 further includes a modification unit 904 for modifying the first page to obtain a second page; and a disk storage unit 905 for storing the second page on disk.

[0161] Optionally, the recording unit 902 is specifically used to copy the page to the flashback buffer; record the page from the flashback buffer to the flashback log; the data processing device 900 also includes a checking unit 906, which is used to check whether the first page exists in the flashback buffer; and a writing unit 907, which is used to write the first page from the flashback buffer to the flashback log if the first page exists.

[0162] Optionally, modifying the first page and recording the first page in the flashback log are parallel operations.

[0163] Each module in the data processing device 900 performs the operations of the data processing device in the embodiments shown in Figures 2 to 6 and 8 above, and the details are not repeated here.

[0164] Please refer to Figure 10 below, which is a schematic diagram of a possible structure of a data processing device 1000 provided in an embodiment of the present application, including a processor 1001, a communication interface 1002, a memory 1003, and a bus 1004. The processor 1001, the communication interface 1002, and the memory 1003 are interconnected via the bus 1004. In an embodiment of the present application, the processor 1001 is used to control and manage the actions of the data processing device. For example, the processor 1001 is used to execute the steps performed by the data processing device in the method embodiment shown in Figure 3. The communication interface 1002 is used to support the data processing device in communication. The memory 1003 is used to store the program code and data of the data processing device.

[0165] The processor 1001 may be a central processing unit (CPU), a general-purpose processor (GPOR), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device (PLD), a transistor logic device (TLD), a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. A processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like. The bus 1004 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, for example. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG. 10 shows only one thick line, but this does not imply that there is only one bus or only one type of bus.

[0166] An embodiment of the present application also provides a computer-readable storage medium, which includes instructions. When the instructions are executed on a computer, the computer executes the method in the embodiments shown in Figures 2 to 6 and 8 above.

[0167] An embodiment of the present application further provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the methods in the embodiments shown in the aforementioned Figures 2 to 6 and 8 .

[0168] An embodiment of the present application also provides a chip system, which includes at least one processor and a communication interface, wherein the communication interface and the at least one processor are interconnected through lines, and the at least one processor is used to run computer programs or instructions to execute the methods in the embodiments shown in Figures 2 to 6 and 8 above.

[0169] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0170] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0172] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0173] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0174] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A data processing method, characterized in that, including: receiving a first flashback instruction; in response to the first flashback instruction, before the first modification of the first page in the database within a target period, recording the first page to a flashback log; receiving a second flashback instruction; in response to the second flashback instruction, restoring the database to the state at a specified moment based on the flashback log and the redo log of the database.

2. The method according to claim 1, characterized in that, The target period is the checkpoint period when the first page is first modified after receiving the first flashback instruction.

3. The method according to claim 1, characterized in that, The target period is a single checkpoint period, and the flashback log includes multiple first pages, where each first page corresponds to one checkpoint period.

4. The method according to claim 1, characterized in that, The target period includes N checkpoint periods, and the flashback log includes multiple first pages, where each first page corresponds to the N checkpoint periods, and N is an integer greater than 1.

5. The method according to claim 3 or 4, characterized in that, The restoring the database to the state at a specified moment based on the flashback log and the redo log of the database includes: constructing a fast lookup structure in an index structure based on multiple first pages; determining a target page corresponding to the specified moment from multiple first pages based on the fast lookup structure; restoring the database to the state at the specified moment based on the target page and the redo log.

6. The method according to any one of claims 1 to 5, characterized in that After receiving the first flashback instruction, the method further includes: recording the log records between the recovery point and the minimum recovery point in the redo log to the flashback log.

7. The method according to any one of claims 1 to 6, characterized in that The method further includes: modifying the first page to obtain a second page; flushing the second page to disk.

8. The method according to claim 7, characterized in that, The recording the page to the flashback log includes: copying the page to a flashback buffer; recording the page from the flashback buffer to the flashback log; Before flushing the second page to disk, the method further includes: checking whether the first page exists in the flashback buffer; if it exists, writing the first page from the flashback buffer to the flashback log.

9. The method according to any one of claims 1 to 8, characterized in that The modification of the first page and the recording of the first page to the flashback log are parallel operations.

10. A data processing device, characterized in that, including: a receiving unit, configured to receive a first flashback instruction; a recording unit, configured to, in response to the first flashback instruction, before the first modification of the first page in the database within a target period, record the first page to a flashback log; The receiving unit is further configured to receive a second flashback instruction; a restoring unit, configured to, in response to the second flashback instruction, restore the database to the state at a specified moment based on the flashback log and the redo log of the database.

11. The device according to claim 10, characterized in that, The target period is the checkpoint period when the first page is first modified after receiving the first flashback instruction.

12. The device according to claim 10, characterized in that, The target period is a single checkpoint period, and the flashback log includes multiple first pages, where each first page corresponds to one checkpoint period.

13. The device according to claim 10, characterized in that, The target period includes N checkpoint periods, and the flashback log includes a plurality of the first pages, where each of the first pages corresponds to the N checkpoint periods, and N is an integer greater than 1.

14. The device according to claim 12 or 13, characterized in that The recovery unit is specifically configured to: Construct a fast lookup structure based on the plurality of the first pages in an index structure manner; Determine a target page corresponding to the specified moment from the plurality of the first pages based on the fast lookup structure; Restore the database to the state at the specified moment based on the target page and the redo log.

15. The device according to any one of claims 10 to 14, characterized in that The recording unit is further configured to: Record the log between the recovery point and the minimum recovery point in the redo log into the flashback log.

16. The device according to any one of claims 10 to 15, characterized in that, The apparatus further includes: A modification unit, configured to modify the first page to obtain a second page; A disk writing unit, configured to write the second page to disk.

17. The device according to claim 16, characterized in that, The recording unit is specifically configured to: Copy the page to the flashback buffer; Record the page from the flashback buffer to the flashback log; The apparatus further includes: A checking unit, configured to check whether the first page exists in the flashback buffer; A writing unit, configured to write the first page from the flashback buffer to the flashback log when the first page exists.

18. The device according to any one of claims 10 to 17, characterized in that Modifying the first page and recording the first page to the flashback log are parallel operations.

19. A data processing device, characterized in that, Includes: A processor and a memory; The memory is used to store instructions; The processor is used to execute the instructions stored in the memory to implement the method according to any one of claims 1 to 9.

20. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program, when executed by one or more processors, implements the method according to any one of claims 1 to 9.

21. A computer program product comprising instructions, characterized in that, When the computer program product runs on a computer, the computer is caused to execute the method according to any one of claims 1 to 9.

Images