Data recovery methods, devices, equipment, storage media, and software products

Abstract

This application relates to a data recovery method, apparatus, computer device, storage medium, and computer program product. The method includes: upon receiving a data recovery instruction for a target data table in a database, determining a set of visible records, the set containing target modified records of the target data table, the target modified records being used to record completed modification operations on the target data table; determining the modification operation type corresponding to each target modified record based on the flashback time indicated by the data recovery instruction, the modification operation type including deletion operation type and insertion operation type; and performing data recovery processing on the target data table according to the modification operation type corresponding to each target modified record to restore the target data table to the flashback time. This method can improve data recovery efficiency.

Description

Technical Field

[0001] This application relates to the field of databases, and in particular to a data recovery method, apparatus, device, storage medium, and program product. Background Technology

[0002] PostgreSQL is a powerful, open-source relational database that is increasingly used in various industries and fields. However, issues such as data misoperation and data loss are common problems encountered when using PostgreSQL.

[0003] To address the above issues, the traditional approach is to use pre-made data backups to perform database recovery.

[0004] However, this method of recovery is time-consuming, and there may be issues such as reduced database performance or database restart during data recovery. Summary of the Invention

[0005] Therefore, it is necessary to provide a data recovery method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve data recovery efficiency in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a data recovery method. The method includes:

[0007] Upon receiving a data recovery instruction for the target data table in the database, the set of visible records is determined. The set of visible records contains the target modification records of the target data table, which are used to record the modification operations that have been completed on the target data table.

[0008] Based on the flashback time indicated by the data recovery command, determine the modification operation type corresponding to each target modified record. The modification operation type includes deletion operation type and insertion operation type.

[0009] Based on the modification operation type corresponding to each target modification record, data recovery processing is performed on the target data table to restore the target data table to the flashback point.

[0010] In this embodiment, the data to be recovered corresponding to the erroneous data that has been modified is realized based on a determined set of visible records. At the same time, the modification operation type corresponding to each target modification record is determined according to the flashback time indicated by the data recovery instruction, so as to perform data recovery processing on the target data table. This realizes the data flashback of the erroneous data that has been modified, that is, the erroneous data that has been modified can be quickly recovered without data backup, without restarting the database, with low recovery cost and high recovery efficiency.

[0011] In one embodiment, the data recovery process for the target data table based on the modification operation type corresponding to each target modification record includes:

[0012] Based on the modification operation type corresponding to each target modification record, determine the corresponding data recovery operation for each target modification record;

[0013] Based on the transaction commit timestamps corresponding to each target modification record, the first execution order of each data recovery operation is determined, where the transaction commit timestamp is used to characterize the time when the modification record was committed.

[0014] Perform the data recovery operations corresponding to the modified records of each target in the first execution order.

[0015] In this embodiment, by determining the modification operation type corresponding to each target modification record and the first execution order of each data recovery operation to execute the data recovery operation corresponding to each target modification record, data conflicts during the data recovery process are avoided, the possibility of failure during the data recovery process is reduced, and the accuracy of data recovery is improved.

[0016] In one embodiment, determining the data recovery operation corresponding to each target modification record based on the modification operation type of each target modification record includes:

[0017] For each target modified record, if the modification operation type corresponding to the target modified record is a deletion operation, then the insertion operation is determined as the data recovery operation corresponding to the target modified record; if the modification operation type corresponding to the target modified record is an insertion operation, then the deletion operation is determined as the data recovery operation corresponding to the target modified record.

[0018] This embodiment realizes the determination of the modification operation type corresponding to each target modification record. The method is simple and easy to implement.

[0019] In one embodiment, the first execution order of each data recovery operation is determined based on the transaction commit timestamp corresponding to each target modification record, including:

[0020] Based on the transaction commit timestamp corresponding to each target modification record, determine the second execution order of the modification operations corresponding to each target modification record;

[0021] The reverse of the second execution order is determined as the first execution order.

[0022] This embodiment determines the first execution order of each data recovery operation in a simple and easy-to-implement manner.

[0023] In one embodiment, the data recovery operation corresponding to each target modified record is performed according to a first execution order, including:

[0024] According to the first execution order, the data table corresponding to the target modified record of the corresponding data restoration operation that is an insert operation is inserted into the target data table; the data table corresponding to the target modified record of the corresponding data restoration operation that is a delete operation is deleted from the target data table.

[0025] In this embodiment, based on the first execution order, corresponding data recovery operations are performed on each target modified record to avoid data conflicts during the data recovery process and reduce the possibility of failures during the data recovery process.

[0026] In one embodiment, determining the set of visible records includes:

[0027] Determine the target transaction snapshot that is closest to the current time from multiple transaction snapshots corresponding to the target data table;

[0028] The set of visible records is determined based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamp corresponding to each modified record of the target transaction snapshot. The snapshot timestamp is used to represent the time when the transaction snapshot was created, and the transaction commit timestamp is used to represent the time when the modified record was committed.

[0029] This embodiment determines the set of visible records by identifying the target transaction snapshot, avoiding interference from other transactions currently executing on the current data recovery operation and improving the accuracy of data recovery.

[0030] In one embodiment, the set of visible records is determined based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamps corresponding to each modification record corresponding to the target transaction snapshot, including:

[0031] The modification record that meets any one of the first, second, and third conditions is identified as the target modification record;

[0032] The first condition includes: the first transaction commit timestamp of the modified record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction commit timestamp of the modified record corresponding to the second transaction number is greater than the snapshot timestamp. The first transaction number is used to identify the transaction number corresponding to the modification operation type of the modified record when it is an insert operation, and the second transaction number is used to identify the transaction number corresponding to the modification operation type of the modified record when it is a delete operation.

[0033] The second condition includes: the commit timestamp of the first transaction corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction number is zero;

[0034] The third condition includes: the modification record corresponding to the first transaction number is in a frozen state.

[0035] Based on the target modified record, a set of visible records is obtained.

[0036] In this embodiment, the set of visible records is determined based on multiple judgment conditions, which avoids missing modified records that are visible to the target transaction snapshot and improves the accuracy of obtaining the set of visible records.

[0037] In one embodiment, the modification operation type corresponding to each target modified record is determined based on the flashback time indicated by the data recovery instruction, including:

[0038] If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is greater than the flashback time, and the second transaction number is zero, then the modification operation type is determined to be the insert operation type.

[0039] If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is less than the flashback time, and the second transaction commit timestamp of the target modified record corresponding to the second transaction number is greater than the flashback time, then the modification operation type is determined to be the deletion operation type.

[0040] In this embodiment, the modification operation type corresponding to the target modification record is determined by using the relevant information of the first transaction number and the second transaction number, thereby improving the efficiency of the modification operation type corresponding to each target modification record. The method is simple and easy to implement.

[0041] In one embodiment, before determining the set of visible records, the method further includes:

[0042] Obtain transaction storage configuration parameters, which include transaction cleanup parameters, transaction freeze parameters, and transaction tracking parameters. Transaction cleanup parameters are used to indicate the transaction value that triggers the record cleanup operation, transaction freeze parameters are used to indicate the transaction value that triggers the record freeze operation, and transaction tracking parameters are used to indicate the status parameters that trigger the start of transaction snapshot tracking.

[0043] Based on the transaction storage configuration parameters, corresponding modification records are stored during the operation on the target data table.

[0044] In this embodiment, according to the transaction storage configuration parameters, during the operation on the target data table, the corresponding modification records are stored, which realizes the retention of the old data corresponding to the data that has been modified in the target data table. This facilitates the accurate acquisition of the old data corresponding to the erroneous data when recovering the erroneous data in the future, and improves the data recovery efficiency.

[0045] Secondly, this application provides a data recovery method. The method includes:

[0046] Upon receiving a data recovery instruction for a target data object in the database, the target backup data stream corresponding to the target data object is determined from the historical backup data stream. The historical backup data stream is the backup data stream corresponding to each data object that has undergone a data object deletion operation. The backup data stream includes the data content corresponding to each data object and the data content corresponding to the cascaded objects of each data object. The data content includes data definition content and data file content.

[0047] Perform data recovery operations on the target data object based on the target backup data stream.

[0048] This application embodiment enables rapid recovery of data that has been mistakenly deleted. This data recovery method can achieve targeted recovery of data that has been mistakenly deleted, unlike the prior art which requires performing a recovery operation on the entire database when a mistakenly deleted data object needs to be recovered. This improves data recovery efficiency and eliminates the need to restart the database.

[0049] In one embodiment, determining the target backup data stream corresponding to the target data object from the historical backup data stream includes:

[0050] Obtain the target object identifier of the target data object;

[0051] The target backup data stream is determined from the historical backup data stream based on the target object identifier.

[0052] In this embodiment, the target backup data stream is determined by the target object identifier of the target data object, which facilitates accurate determination of the backup data stream of the target data object and improves the accuracy of determining the target backup data stream.

[0053] In one embodiment, before determining the target backup data stream corresponding to the target data object from the historical backup data stream, the process includes:

[0054] Upon receiving a data object deletion command for a data object in the database, retrieve the backup data stream corresponding to the data object;

[0055] Based on the object backup configuration parameters, the backup data stream is backed up to a preset directory in the recycle bin to generate a historical backup data stream. The object backup configuration parameters include the object identifier of the data object.

[0056] Perform data object deletion processing on the data object.

[0057] In this embodiment, after receiving a data object deletion instruction for a data object in the database, the system obtains the backup data stream corresponding to the data object and backs up the backup data stream to a preset directory in the recycle bin based on the object backup configuration parameters. This achieves the backup of the data content corresponding to the data object and improves the accuracy of obtaining the backup data stream of the target data object when performing subsequent data recovery.

[0058] In one embodiment, performing a data recovery operation on a target data object based on a target backup data stream includes:

[0059] The third execution order is determined based on the cascading relationship between the data objects corresponding to the target backup data stream;

[0060] Data recovery operations are performed on each data object corresponding to the target backup data stream in the third execution order.

[0061] In this embodiment, the cascading relationship between data objects corresponding to the target backup data stream is used to determine the recovery order of each data object corresponding to the target backup data stream, thereby avoiding errors during data recovery and reducing the possibility of database failure.

[0062] Thirdly, this application also provides a data recovery apparatus. The apparatus includes:

[0063] The receiving module is used to determine the set of visible records after receiving a data recovery instruction for a target data table in the database. The set of visible records contains the target modification records of the target data table, which are used to record the modification operations that have been completed on the target data table.

[0064] The determination module is used to determine the modification operation type corresponding to each target modified record based on the flashback time indicated by the data recovery instruction. The modification operation type includes deletion operation type and insertion operation type.

[0065] The recovery module is used to perform data recovery processing on the target data table according to the modification operation type corresponding to each target modification record, so as to restore the target data table to the flashback moment.

[0066] Fourthly, this application also provides a data recovery apparatus. The apparatus includes:

[0067] The receiving module is used to determine the target backup data stream corresponding to the target data object from the historical backup data stream after receiving a data recovery instruction for the target data object in the database. The historical backup data stream is the backup data stream corresponding to each data object that has undergone a data object deletion operation. The backup data stream includes the data content corresponding to each data object and the data content corresponding to the cascaded objects of each data object. The data content includes data definition content and data file content.

[0068] The recovery module is used to perform data recovery operations on the target data object based on the target backup data stream.

[0069] Fifthly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the data recovery method as described in either the first aspect or the second aspect above.

[0070] Sixthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the data recovery method as described in either the first aspect or the second aspect above.

[0071] In a seventh aspect, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the data recovery method as described in either the first aspect or the second aspect above.

[0072] The aforementioned data recovery methods, apparatus, computer equipment, storage media, and computer program products, upon receiving a data recovery instruction for a target data table in a database, determine a set of visible records. This set includes target modification records of the target data table, which record completed modification operations. Based on the flashback time indicated by the data recovery instruction, the modification operation type corresponding to each target modification record is determined. Modification operation types include deletion and insertion operations. Based on the modification operation type corresponding to each target modification record, data recovery processing is performed on the target data table to restore it to the flashback time. This application embodiment, based on the determined set of visible records, realizes the recovery of erroneous data corresponding to modified data. Simultaneously, based on the flashback time indicated by the data recovery instruction, the modification operation type corresponding to each target modification record is determined for data recovery processing of the target data table. This achieves data flashback of erroneous data that has undergone modification operations, enabling rapid recovery of erroneous data without data backup, without requiring database restart, resulting in low recovery cost and high recovery efficiency. Attached Figure Description

[0073] Figure 1 This is a flowchart illustrating a data recovery method in one embodiment;

[0074] Figure 2 This is a flowchart illustrating a data recovery method in another embodiment;

[0075] Figure 3This is a flowchart illustrating step 103 in one embodiment;

[0076] Figure 4 This is a flowchart illustrating step 101 in one embodiment;

[0077] Figure 5 This is a flowchart illustrating a data recovery method in another embodiment;

[0078] Figure 6 This is a flowchart illustrating a data recovery method in another embodiment;

[0079] Figure 7 This is a schematic diagram illustrating the cascading relationship of data objects in one embodiment;

[0080] Figure 8 This is a flowchart illustrating a data recovery method in another embodiment;

[0081] Figure 9 This is a flowchart illustrating step 602 in one embodiment;

[0082] Figure 10 This is a flowchart illustrating a data recovery method in another embodiment;

[0083] Figure 11 This is a structural block diagram of a data recovery device in one embodiment;

[0084] Figure 12 This is a structural block diagram of a data recovery device in another embodiment;

[0085] Figure 13 This is a structural block diagram of a data recovery device in another embodiment;

[0086] Figure 14 This is a structural block diagram of a data recovery device in another embodiment;

[0087] Figure 15 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation

[0088] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0089] PostgreSQL is a powerful, open-source relational database. PostgreSQL has the following advantages: (1) It supports most SQL functions, such as complex SQL queries, foreign keys, triggers, views, transaction integrity, multi-version concurrency control, etc.; (2) PostgreSQL can be extended with the help of extension tools; (3) PostgreSQL can run on all major operating systems; (4) Anyone can use, modify and distribute PostgreSQL for any purpose free of charge.

[0090] Based on these advantages, PostgreSQL databases are being used in an increasing number of industries and fields. However, data misoperation issues are commonly encountered during the use of PostgreSQL databases.

[0091] To address the aforementioned issues, the traditional approach is to perform data recovery on the entire PostgreSQL database using pre-prepared data backups. However, this method is time-consuming and may degrade database performance or require a database restart during the recovery process.

[0092] In view of this, embodiments of this application provide a data recovery method to improve the data recovery efficiency of PostgreSQL databases.

[0093] This application provides a data recovery method. The data recovery method can be executed by a data recovery device, which can be implemented as part or all of a terminal or server through software, hardware, or a combination of both. The terminal can be a personal computer, laptop, media player, smart TV, smartphone, tablet, or portable wearable device, etc.; the server can be a standalone server or a server cluster composed of multiple servers.

[0094] In the following method embodiments, the execution subject is always described using a terminal as an example. It is understood that this method can also be applied to a server, and can also be applied to a system that includes both a terminal and a server, and can be implemented through the interaction between the terminal and the server.

[0095] In this application embodiment, corresponding data recovery strategies are proposed for data modification operations performed based on database commands (insert, update, and delete) and data object deletion operations performed based on the "drop" database command. In specific implementation, the corresponding data recovery strategy can be adopted based on the data operation corresponding to the erroneous data.

[0096] For data modification operations performed using database commands (insert, update, and delete), the corresponding data recovery methods can be found in [reference needed]. Figure 1 .like Figure 1 As shown, a data recovery method provided in this application embodiment may include the following steps:

[0097] Step 101: After receiving the data recovery instruction for the target data table in the database, determine the set of visible records.

[0098] The visible record set contains the target modification records of the target data table. The target modification records are used to record the modification operations that have been completed in the target data table.

[0099] In PostgreSQL, a transaction is a discrete unit of database work, a sequence of database operations that access and potentially modify various data items in the database. Each transaction includes multiple modified records. To ensure that the execution of a transaction is not interfered with by other transactions, a transaction snapshot is typically allocated for each transaction based on PostgreSQL's MVCC mechanism to save the transaction state information that the transaction can see at a certain point in time. During the transaction snapshot taking process, neither the executing transaction nor future transactions are visible to the transaction snapshot. Therefore, to avoid the impact of other transactions on the current data recovery process, it is necessary to first determine the set of visible records at the current moment.

[0100] Optionally, this modification operation is a database operation based on insert, update, and delete database commands. The data processing mechanism for the "update" command is as follows: first, the old data is marked as deleted, and then the new data is inserted.

[0101] Based on this, the modification operation corresponding to this target modified record is deletion or insertion.

[0102] Step 102: Determine the modification operation type corresponding to each target modification record based on the flashback time indicated by the data recovery command.

[0103] The modification operation types include deletion operation types and insertion operation types.

[0104] Optionally, the flashback time can be manually set or determined by the terminal based on the user's input recovery target.

[0105] Typically, a transaction involves multiple modified records. For each modified record within a transaction, a first transaction number (xmin) and a second transaction number (xmax) are stored. The first transaction number (xmin) identifies the transaction number corresponding to an insert operation, and the second transaction number (xmax) identifies the transaction number corresponding to a delete operation. When the modification operation type is insert, the first transaction number (xmin) is set to the transaction number xid of that transaction, and the second transaction number (xmax) is set to 0. When the modification operation type is delete, the second transaction number (xmax) is set to the transaction number xid of that transaction.

[0106] Therefore, the modification operation type corresponding to each target modification record can be determined based on the first transaction number and the second transaction number corresponding to each target modification record.

[0107] Step 103: Based on the modification operation type corresponding to each target modification record, perform data recovery processing on the target data table to restore the target data table to the flashback time.

[0108] Optionally, if a failure occurs during data recovery, the data in the target table will not be damaged because the data recovery transaction has not been committed.

[0109] In this embodiment, the data to be recovered corresponding to the erroneous data that has been modified is realized based on a determined set of visible records. At the same time, the modification operation type corresponding to each target modification record is determined according to the flashback time indicated by the data recovery instruction, so as to perform data recovery processing on the target data table. This realizes the data flashback of the erroneous data that has been modified, that is, the erroneous data that has been modified can be quickly recovered without data backup, without restarting the database, with low recovery cost and high recovery efficiency.

[0110] In one embodiment, when data modifications are performed on the target data table, the corresponding old data is retained. Therefore, as... Figure 2 As shown, before determining the set of visible records, the method also includes:

[0111] Step 201: Obtain transaction storage configuration parameters.

[0112] The transaction storage configuration parameters include transaction cleanup parameters, transaction freeze parameters, and transaction tracing parameters. The transaction cleanup parameters indicate the transaction value that triggers the record cleanup operation, the transaction freeze parameters indicate the transaction value that triggers the record freeze operation, and the transaction tracing parameters indicate the status parameters that trigger the start of transaction tracing.

[0113] Optionally, the transaction value corresponding to the transaction cleanup parameter can be set based on the `vacuum_defer_cleanup_age` field. For example, this transaction value can be set to 1,000,000. Specifically, the transaction cleanup parameter can be set using the statement "vacuum_defer_cleanup_age = 1,000,000", which ensures that modified records within 1 million transactions are not cleaned up to the recycle bin.

[0114] Optionally, the transaction value corresponding to the transaction freeze parameter can be set based on the `vacuum_freeze_min_age` field. For example, this transaction value can be set to 50,000,000. Specifically, the transaction freeze parameter can be set using the statement "vacuum_freeze_min_age = 50,000,000", which ensures that modified records within 50 million transactions will not be frozen.

[0115] Optionally, a transaction tracking parameter can be set using the statement "rack_commit_timestamp=on". This parameter ensures that the transaction end time can be obtained based on the transaction number.

[0116] Step 202: Based on the transaction storage configuration parameters, store the corresponding modification records during the operation on the target data table.

[0117] In this embodiment, according to the transaction storage configuration parameters, during the operation on the target data table, the corresponding modification records are stored, which realizes the retention of the old data corresponding to the data that has been modified in the target data table. This facilitates the accurate acquisition of the old data corresponding to the erroneous data when recovering the erroneous data in the future, and improves the data recovery efficiency.

[0118] In the embodiments of this application, such as Figure 3 As shown, based on Figure 1 The embodiment shown illustrates a data recovery process for the target data table in step 103, based on the modification operation type corresponding to each target modification record. This process includes the following steps 301-303:

[0119] Step 301: Determine the data recovery operation corresponding to each target modification record based on the modification operation type corresponding to each target modification record.

[0120] Optionally, for each target modified record, if the modification operation type corresponding to the target modified record is a deletion operation, then the insertion operation is determined as the data recovery operation corresponding to the target modified record; if the modification operation type corresponding to the target modified record is an insertion operation, then the deletion operation is determined as the data recovery operation corresponding to the target modified record.

[0121] Step 302: Determine the first execution order of each data recovery operation based on the transaction commit timestamp corresponding to each target modification record.

[0122] The transaction commit timestamp is used to represent the time when the modified record was committed.

[0123] Optionally, based on the transaction commit timestamps corresponding to each target modification record, the second execution order of the modification operations corresponding to each target modification record is determined; the reverse of the second execution order is determined as the first execution order.

[0124] Step 303: Perform the data recovery operations corresponding to each target modification record in the first execution order.

[0125] Optionally, according to the first execution order, the data table corresponding to the target modified record of the corresponding data restoration operation that is an insert operation is inserted into the target data table; the data table corresponding to the target modified record of the corresponding data restoration operation that is a delete operation is deleted from the target data table.

[0126] In this embodiment, by determining the modification operation type corresponding to each target modification record and the first execution order of each data recovery operation to execute the data recovery operation corresponding to each target modification record, data conflicts during the data recovery process are avoided, the possibility of failure during the data recovery process is reduced, and the accuracy of data recovery is improved.

[0127] In the embodiments of this application, such as Figure 4 As shown, based on any of the above embodiments, this embodiment relates to the implementation process of determining the set of visible records in step 101, including the following implementation steps:

[0128] Step 401: Determine the target transaction snapshot that is closest to the current time from multiple transaction snapshots corresponding to the target data table.

[0129] Optionally, obtain the snapshot timestamp corresponding to each transaction snapshot, and compare the snapshot timestamp corresponding to each transaction snapshot with the current time to obtain the target transaction snapshot.

[0130] Step 402: Determine the set of visible records based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamps corresponding to each modification record of the target transaction snapshot.

[0131] Among them, the snapshot timestamp is used to represent the time when the transaction snapshot was created, and the transaction commit timestamp is used to represent the time when the modified record was committed.

[0132] In this embodiment, the target transaction snapshot closest to the current time is determined from multiple transaction snapshots corresponding to the target data table. Based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamps corresponding to each modified record of the target transaction snapshot, the set of visible records is determined. This embodiment determines the set of visible records by determining the target transaction snapshot, avoiding interference from other transactions currently executing on the current data recovery operation and improving the accuracy of data recovery.

[0133] In one embodiment, to avoid missing modification records visible to the target transaction snapshot and to improve the accuracy of obtaining the set of visible records, modification records that satisfy any one of the first, second, and third conditions are identified as target modification records; and based on the target modification records, the set of visible records is obtained.

[0134] The first condition includes: the first transaction commit timestamp of the modification record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction commit timestamp of the modification record corresponding to the second transaction number is greater than the snapshot timestamp; the second condition includes: the first transaction commit timestamp of the modification record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction number is zero; the third condition includes: the modification record corresponding to the first transaction number is in a frozen state.

[0135] Correspondingly, xmin can be used to represent the first transaction number, and xmax can be used to represent the second transaction number. For each modified record, the first condition can be expressed as follows: the commit timestamp of the first transaction corresponding to xmin is less than the snapshot timestamp, and the commit timestamp of the second transaction corresponding to xmax is greater than the snapshot timestamp; the first condition can be expressed as follows: the commit timestamp of the first transaction corresponding to xmin is less than the snapshot timestamp, and xmax = 0; the first condition can be expressed as follows: xmin is frozen.

[0136] Furthermore, in one embodiment, step 102, which determines the implementation process of the modification operation type corresponding to each target modification record based on the flashback time indicated by the data recovery instruction, includes:

[0137] If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is greater than the flashback time, and the second transaction number is zero, then the modification operation type is determined to be an insert operation type.

[0138] If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is less than the flashback time, and the second transaction commit timestamp of the target modified record corresponding to the second transaction number is greater than the flashback time, then the modification operation type is determined to be the deletion operation type.

[0139] In this embodiment, the modification operation type corresponding to the target modification record is determined by using the first transaction number and related information of the first transaction number, thereby improving the efficiency of the modification operation type corresponding to each target modification record. The method is simple and easy to implement.

[0140] In the embodiments of this application, such as Figure 5 As shown, a data recovery method is provided, which includes the following steps:

[0141] Step 501: Obtain transaction storage configuration parameters.

[0142] The transaction storage configuration parameters include transaction cleanup parameters, transaction freeze parameters, and transaction tracing parameters. The transaction cleanup parameters indicate the transaction value that triggers the record cleanup operation, the transaction freeze parameters indicate the transaction value that triggers the record freeze operation, and the transaction tracing parameters indicate the status parameters that trigger the start of transaction tracing.

[0143] Step 502: Based on the transaction storage configuration parameters, store the corresponding modification records during the operation on the target data table.

[0144] Step 503: After receiving the data recovery instruction for the target data table in the database, determine the target transaction snapshot that is closest to the current time from multiple transaction snapshots corresponding to the target data table.

[0145] Step 504: Based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamp corresponding to each modification record corresponding to the target transaction snapshot, determine the modification record that satisfies any one of the first, second, and third conditions as the target modification record to obtain a set of visible records.

[0146] The snapshot timestamp represents the time when the transaction snapshot was created, and the transaction commit timestamp represents the time when the modified records were committed. The record set contains the target modified records of the target data table, which are used to record the completed modification operations on the target data table.

[0147] The first condition includes: the first transaction commit timestamp of the modified record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction commit timestamp of the modified record corresponding to the second transaction number is greater than the snapshot timestamp. The first transaction number is used to identify the transaction number corresponding to the modification operation type of the modified record when it is an insert operation, and the second transaction number is used to identify the transaction number corresponding to the modification operation type of the modified record when it is a delete operation. The second condition includes: the first transaction commit timestamp of the modified record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction number is zero. The third condition includes: the modified record corresponding to the first transaction number is in a frozen state.

[0148] Step 505: If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is greater than the flashback time, and the second transaction number is zero, then the modification operation type is determined to be the insert operation type.

[0149] Step 506: If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is less than the flashback time, and the second transaction commit timestamp of the target modified record corresponding to the second transaction number is greater than the flashback time, then the modification operation type is determined to be the deletion operation type.

[0150] Step 507: For each target modified record, if the modification operation type corresponding to the target modified record is a deletion operation type, then the insertion operation is determined as the data recovery operation corresponding to the target modified record; if the modification operation type corresponding to the target modified record is an insertion operation type, then the deletion operation is determined as the data recovery operation corresponding to the target modified record.

[0151] Step 508: Based on the transaction commit timestamps corresponding to each target modification record, determine the second execution order of the modification operations corresponding to each target modification record, and determine the reverse of the second execution order as the first execution order.

[0152] Step 509: According to the first execution order, insert the data table corresponding to the target modified record of the data restoration operation that is an insert operation into the target data table; delete the data table corresponding to the target modified record of the data restoration operation that is a delete operation from the target data table.

[0153] This embodiment enables data flashback of erroneously modified data, allowing for rapid recovery of such data without data backup, resulting in low recovery cost and high recovery efficiency.

[0154] The following describes the implementation process of the data recovery strategy corresponding to the data object deletion operation executed based on the "DROP" database command. In the embodiments of this application, as... Figure 6 As shown, a data recovery method is provided, which includes the following steps:

[0155] Step 601: After receiving a data recovery instruction for a target data object in the database, determine the target backup data stream corresponding to the target data object from the historical backup data stream.

[0156] Among them, the historical backup data stream is the backup data stream corresponding to each data object that has undergone a data object deletion operation. The backup data stream includes the data content corresponding to each data object and the data content corresponding to the cascaded objects of each data object. The data content includes data definition content and data file content.

[0157] The data object deletion operation is a database operation performed based on the "DROP" database command.

[0158] Optional, such as Figure 7 As shown, database data objects can be divided into the following levels: Level 1 - <Database>, Level 2 - <Schema>, Level 3 - , and Level 4 - <Column, View, Constraint, Subtable, Subrange>. For a given data object, its cascading objects include its child data objects and the cascading objects of those child data objects. Taking this data object as a schema as an example, the cascading objects include the Level 3 data objects and the corresponding Level 4 data objects.

[0159] Optionally, the data definition includes table definition (pg_class), index definition (index_class), column definition (pg_attribute), type definition (pg_type), trigger definition (pg_trigger), and constraint definition (pg_constraint). These definitions are set by the PostgreSQL database itself for the data object.

[0160] Optionally, the data definition also includes the backup table definition dg_class (adding two fields, deletion time and object oid, to pg_class), the backup column definition dg_attribute (adding two fields, deletion time and object oid, to pg_attribute), the backup type definition dg_type (adding two fields, deletion time and object oid, to pg_type), and the backup trigger definition dg_trigger (adding two fields, deletion time and object oid, to pg_trigger).

[0161] Step 602: Perform a data recovery operation on the target data object based on the target backup data stream.

[0162] Optionally, the data definition content and data file content included in the target backup data stream can be restored to the database.

[0163] Optionally, in the event of a data recovery failure, only the recovered data files need to be cleaned up; the metadata information does not need to be cleaned up. The metadata information recovery transaction will only be committed after all data files have been recovered.

[0164] In this embodiment, upon receiving a data recovery instruction for a target data object in the database, the target backup data stream corresponding to the target data object is determined from the historical backup data stream. Data recovery is then performed on the target data object based on the target backup data stream. The historical backup data stream consists of backup data streams corresponding to each data object for which a data object deletion operation has been performed. This embodiment enables rapid recovery of erroneously deleted data. Furthermore, this data recovery method allows for targeted recovery of erroneously deleted data, eliminating the need to perform a recovery operation on the entire database as required in existing technologies. This improves data recovery efficiency and eliminates the need to restart the database.

[0165] In one embodiment, to facilitate obtaining a backup data stream of the data object, a backup data stream of the data object is backed up when the data object is deleted. For example... Figure 8 As shown, before determining the target backup data stream corresponding to the target data object from the historical backup data stream, the process includes:

[0166] Step 701: After receiving a data object deletion instruction for a data object in the database, obtain the backup data stream corresponding to the data object.

[0167] The data object deletion command is the "DROP" database command.

[0168] Optionally, upon receiving a data object deletion instruction for a data object in the database, the HOOKdg_recycle method is used to intercept the data object deletion process and obtain the backup data stream of the data object.

[0169] Step 702: Based on the object backup configuration parameters, back up the backup data stream to a preset directory in the recycle bin to generate a historical backup data stream.

[0170] Optionally, the object backup configuration parameters include the object identifier of the data object.

[0171] Optionally, the object backup configuration parameters also include the data object's deletion time, object name, and preset directory construction information. Specifically, a db_oid / rel_oid directory can be created under the recycle bin, where db_oid is the database directory name and rel_oid is the data object directory name; each data item in the backup data stream is backed up to its corresponding created directory. The data stored in the directories in the recycle bin constitutes the historical backup data stream.

[0172] Step 703: Perform data object deletion processing on the data object.

[0173] In this embodiment, after receiving a data object deletion instruction for a data object in the database, the system obtains the backup data stream corresponding to the data object and backs up the backup data stream to a preset directory in the recycle bin based on the object backup configuration parameters. This achieves the backup of the data content corresponding to the data object and improves the accuracy of obtaining the backup data stream of the target data object when performing subsequent data recovery.

[0174] Furthermore, in one embodiment, the process of determining the target backup data stream corresponding to the target data object from the historical backup data stream includes: obtaining the target object identifier of the target data object; and determining the target backup data stream from the historical backup data stream based on the target object identifier.

[0175] In this embodiment, the target backup data stream is determined by the target object identifier of the target data object, which facilitates accurate determination of the backup data stream of the target data object and improves the accuracy of determining the target backup data stream.

[0176] In the embodiments of this application, such as Figure 9 As shown, based on Figure 6 In the illustrated embodiment, step 602 performs a data recovery operation on the target data object based on the target backup data stream, including:

[0177] Step 801: Determine the third execution order based on the cascading relationship between the data objects corresponding to the target backup data stream.

[0178] Optionally, the data objects can be sorted according to their corresponding levels, from high level to low level, to obtain the third execution order.

[0179] Optionally, a numerical identifier can be set for each data object. The higher the level of the data object, the smaller the numerical identifier value. For example, the numerical identifiers for database, schema, table, column, view, constraint, sub-table, and sub-range can be set to 1, 2, 3, 4, 5, 6, 7, and 8 respectively.

[0180] Optionally, obtain the numerical identifiers corresponding to each data object in the target backup data stream, sort the data objects according to the numerical values ​​of each numerical identifier, and obtain the third execution order, which is an ascending order.

[0181] Step 802: Perform data recovery operations on each data object corresponding to the target backup data stream according to the third execution order.

[0182] Optionally, the data content of each data object can be restored to the database in the third execution order.

[0183] In this embodiment, a third execution order is determined based on the cascading relationship between data objects corresponding to the target backup data stream. Data recovery operations are then performed on each data object corresponding to the target backup data stream according to the third execution order. The cascading relationship between data objects corresponding to the target backup data stream is used to determine the recovery order of each data object corresponding to the target backup data stream, thereby avoiding errors during data recovery and reducing the possibility of database failure.

[0184] In the embodiments of this application, such as Figure 10 As shown, this embodiment provides a data recovery method, which includes the following steps:

[0185] Step 901: After receiving a data object deletion instruction for a data object in the database, obtain the backup data stream corresponding to the data object.

[0186] Step 902: Based on the object backup configuration parameters, back up the backup data stream to a preset directory in the recycle bin to generate a historical backup data stream.

[0187] Step 903: Perform data object deletion processing on the data object.

[0188] Step 904: After receiving a data recovery instruction for the target data object in the database, determine the target backup data stream corresponding to the target data object from the historical backup data stream.

[0189] Step 905: Determine the third execution order based on the cascading relationship between the data objects corresponding to the target backup data stream.

[0190] Step 906: Perform data recovery operations on each data object corresponding to the target backup data stream according to the third execution order.

[0191] This application embodiment enables rapid recovery of data from erroneous deletion operations. This data recovery method can achieve targeted recovery of data from erroneous deletion operations, without the need to perform a recovery operation on the entire database when recovering erroneously deleted data objects, as is the case in the prior art. This improves data recovery efficiency and eliminates the need to restart the database.

[0192] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0193] Based on the same inventive concept, this application also provides a data recovery apparatus for implementing the data recovery method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more data recovery apparatus embodiments provided below can be found in the limitations of the data recovery method described above, and will not be repeated here.

[0194] In one embodiment, such as Figure 11 As shown, a data recovery device is provided, including: a receiving module 100, a determining module 200, and a recovery module 300, wherein:

[0195] The receiving module 100 is used to determine the set of visible records after receiving a data recovery instruction for a target data table in the database. The set of visible records includes the target modification records of the target data table, which are used to record the modification operations that have been completed on the target data table.

[0196] The determination module 200 is used to determine the modification operation type corresponding to each target modification record based on the flashback time indicated by the data recovery instruction. The modification operation type includes deletion operation type and insertion operation type.

[0197] The recovery module 300 is used to perform data recovery processing on the target data table according to the modification operation type corresponding to each target modification record, so as to restore the target data table to the flashback moment.

[0198] In one embodiment, the recovery module 300 is specifically used for:

[0199] Based on the modification operation type corresponding to each target modification record, determine the corresponding data recovery operation for each target modification record;

[0200] Based on the transaction commit timestamps corresponding to each target modification record, the first execution order of each data recovery operation is determined, where the transaction commit timestamp is used to characterize the time when the modification record was committed.

[0201] Perform the data recovery operations corresponding to the modified records of each target in the first execution order.

[0202] In one embodiment, the recovery module 300 is further specifically used for:

[0203] For each target modified record, if the modification operation type corresponding to the target modified record is a deletion operation, then the insertion operation is determined as the data recovery operation corresponding to the target modified record; if the modification operation type corresponding to the target modified record is an insertion operation, then the deletion operation is determined as the data recovery operation corresponding to the target modified record.

[0204] In one embodiment, the recovery module 300 is further specifically used for:

[0205] Based on the transaction commit timestamp corresponding to each target modification record, determine the second execution order of the modification operations corresponding to each target modification record;

[0206] The reverse of the second execution order is determined as the first execution order.

[0207] In one embodiment, the recovery module 300 is further specifically used for:

[0208] According to the first execution order, the data table corresponding to the target modified record of the corresponding data restoration operation that is an insert operation is inserted into the target data table; the data table corresponding to the target modified record of the corresponding data restoration operation that is a delete operation is deleted from the target data table.

[0209] In one embodiment, the receiving module 100 is specifically used for:

[0210] Determine the target transaction snapshot that is closest to the current time from multiple transaction snapshots corresponding to the target data table;

[0211] The set of visible records is determined based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamp corresponding to each modified record of the target transaction snapshot. The snapshot timestamp is used to represent the time when the transaction snapshot was created, and the transaction commit timestamp is used to represent the time when the modified record was committed.

[0212] In one embodiment, the receiving module 100 is further specifically used for:

[0213] The modification record that meets any one of the first, second, and third conditions is identified as the target modification record;

[0214] The first condition includes: the first transaction commit timestamp of the modified record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction commit timestamp of the modified record corresponding to the second transaction number is greater than the snapshot timestamp. The first transaction number is used to identify the transaction number corresponding to the modification operation type of the modified record when it is an insert operation, and the second transaction number is used to identify the transaction number corresponding to the modification operation type of the modified record when it is a delete operation.

[0215] The second condition includes: the commit timestamp of the first transaction corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction number is zero;

[0216] The third condition includes: the modification record corresponding to the first transaction number is in a frozen state.

[0217] In one embodiment, the determining module 200 is specifically used for:

[0218] If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is greater than the flashback time, and the second transaction number is zero, then the modification operation type is determined to be the insert operation type.

[0219] If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is less than the flashback time, and the second transaction commit timestamp of the target modified record corresponding to the second transaction number is greater than the flashback time, then the modification operation type is determined to be the deletion operation type.

[0220] In one embodiment, such as Figure 12 As shown, the data recovery device also includes a configuration module 400, which is used for:

[0221] Obtain transaction storage configuration parameters, which include transaction cleanup parameters, transaction freeze parameters, and transaction tracking parameters. Transaction cleanup parameters are used to indicate the transaction value that triggers the record cleanup operation, transaction freeze parameters are used to indicate the transaction value that triggers the record freeze operation, and transaction tracking parameters are used to indicate the status parameters that trigger the start of transaction snapshot tracking.

[0222] Based on the transaction storage configuration parameters, corresponding modification records are stored during the operation on the target data table.

[0223] In one embodiment, such as Figure 13 As shown, a data recovery device is provided, comprising: a receiving module 500 and a recovery module 600, wherein:

[0224] The receiving module 500 is used to determine the target backup data stream corresponding to the target data object from the historical backup data stream after receiving a data recovery instruction for the target data object in the database. The historical backup data stream is the backup data stream corresponding to each data object that has undergone a data object deletion operation. The backup data stream includes the data content corresponding to each data object and the data content corresponding to the cascaded objects of each data object. The data content includes data definition content and data file content.

[0225] Recovery module 600 is used to perform data recovery operations on target data objects based on the target backup data stream.

[0226] In one embodiment, the receiving module 500 is specifically used for:

[0227] Obtain the target object identifier of the target data object;

[0228] The target backup data stream is determined from the historical backup data stream based on the target object identifier.

[0229] In one embodiment, such as Figure 14 As shown, the data recovery device also includes a configuration module 700, which is used for:

[0230] Upon receiving a data object deletion command for a data object in the database, retrieve the backup data stream corresponding to the data object;

[0231] Based on the object backup configuration parameters, the backup data stream is backed up to a preset directory in the recycle bin to generate a historical backup data stream. The object backup configuration parameters include the object identifier of the data object.

[0232] Perform data object deletion processing on the data object.

[0233] In one embodiment, the recovery module 600 is specifically used for:

[0234] The third execution order is determined based on the cascading relationship between the data objects corresponding to the target backup data stream;

[0235] Data recovery operations are performed on each data object corresponding to the target backup data stream in the third execution order.

[0236] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 15As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a data recovery method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0237] Those skilled in the art will understand that Figure 15 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0238] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0239] Upon receiving a data recovery instruction for the target data table in the database, the set of visible records is determined. The set of visible records contains the target modification records of the target data table, which are used to record the modification operations that have been completed on the target data table.

[0240] Based on the flashback time indicated by the data recovery command, determine the modification operation type corresponding to each target modified record. The modification operation type includes deletion operation type and insertion operation type.

[0241] Based on the modification operation type corresponding to each target modification record, data recovery processing is performed on the target data table to restore the target data table to the flashback point.

[0242] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0243] Based on the modification operation type corresponding to each target modification record, determine the data recovery operation corresponding to each target modification record; based on the transaction commit timestamp corresponding to each target modification record, determine the first execution order of each data recovery operation, where the transaction commit timestamp is used to represent the time of the modification record commit; execute the data recovery operations corresponding to each target modification record in the first execution order.

[0244] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0245] For each target modified record, if the modification operation type corresponding to the target modified record is a deletion operation, then the insertion operation is determined as the data recovery operation corresponding to the target modified record; if the modification operation type corresponding to the target modified record is an insertion operation, then the deletion operation is determined as the data recovery operation corresponding to the target modified record.

[0246] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0247] Based on the transaction commit timestamps corresponding to each target modification record, determine the second execution order of the modification operations corresponding to each target modification record; and determine the first execution order as the reverse of the second execution order.

[0248] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0249] According to the first execution order, the data table corresponding to the target modified record of the corresponding data restoration operation that is an insert operation is inserted into the target data table; the data table corresponding to the target modified record of the corresponding data restoration operation that is a delete operation is deleted from the target data table.

[0250] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0251] Determine the target transaction snapshot closest to the current time from multiple transaction snapshots corresponding to the target data table; determine the set of visible records based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamp corresponding to each modified record of the target transaction snapshot. The snapshot timestamp is used to characterize the time when the transaction snapshot was created, and the transaction commit timestamp is used to characterize the time when the modified record was committed.

[0252] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0253] The modified record that satisfies any one of the first, second, and third conditions is identified as the target modified record. The first condition includes: the first transaction commit timestamp of the modified record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction commit timestamp of the modified record corresponding to the second transaction number is greater than the snapshot timestamp. The first transaction number is used to identify the transaction number corresponding to an insert operation, and the second transaction number is used to identify the transaction number corresponding to a delete operation. The second condition includes: the first transaction commit timestamp of the modified record corresponding to the first transaction number is less than the snapshot timestamp, and the second transaction number is zero. The third condition includes: the modified record corresponding to the first transaction number is in a frozen state.

[0254] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0255] If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is greater than the flashback time, and the second transaction number is zero, then the modification operation type is determined to be an insert operation type; if the first transaction commit timestamp of the target modified record corresponding to the first transaction number is less than the flashback time, and the second transaction commit timestamp of the target modified record corresponding to the second transaction number is greater than the flashback time, then the modification operation type is determined to be a delete operation type.

[0256] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0257] Obtain transaction storage configuration parameters, including transaction cleanup parameters, transaction freeze parameters, and transaction tracking parameters. Transaction cleanup parameters indicate the transaction values ​​that trigger the record cleanup operation, transaction freeze parameters indicate the transaction values ​​that trigger the record freeze operation, and transaction tracking parameters indicate the status parameters that trigger the start of transaction snapshot tracking. Based on the transaction storage configuration parameters, store the corresponding transaction snapshots during the operation on the target data table.

[0258] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps.

[0259] Upon receiving a data recovery instruction for a target data object in the database, the target backup data stream corresponding to the target data object is determined from the historical backup data stream. The historical backup data stream consists of backup data streams corresponding to each data object that has undergone a data object deletion operation. The backup data stream includes the data content corresponding to each data object and the data content corresponding to the cascaded objects of each data object. The data content includes data definition content and data file content. The data recovery operation is then performed on the target data object based on the target backup data stream.

[0260] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0261] Obtain the target object identifier of the target data object; determine the target backup data stream from the historical backup data stream based on the target object identifier.

[0262] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0263] Upon receiving a data object deletion instruction for a data object in the database, the system retrieves the backup data stream corresponding to the data object; based on the object backup configuration parameters, it backs up the backup data stream to a preset directory in the recycle bin to generate a historical backup data stream. The object backup configuration parameters include the object identifier of the data object; and it performs data object deletion processing on the data object.

[0264] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0265] Based on the cascading relationship between the data objects corresponding to the target backup data stream, determine the third execution order; and perform data recovery operations on each data object corresponding to the target backup data stream according to the third execution order.

[0266] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0267] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0268] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0269] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0270] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A data recovery method, characterized in that, The method includes: Upon receiving a data recovery instruction for a target data table in the database, a set of visible records is determined. This set of visible records includes target modification records of the target data table, which are used to record completed modification operations on the target data table. The step of determining the set of visible records includes: obtaining the transaction identifier and transaction status information carried in each historical modification record of the target data table; and, based on the transaction identifier and transaction status information, selecting historical modification records that are visible at the flashback time indicated by the data recovery instruction as the target modification records. The transaction identifier and transaction status information are allocated to each historical modification record based on the Multi-Version Concurrency Control (MVCC) mechanism. If the first transaction commit timestamp of the target modified record corresponding to the first transaction number is greater than the flashback time indicated by the data recovery instruction, and the second transaction number is zero, then the modification operation type corresponding to each target modified record is determined to be an insert operation type; if the first transaction commit timestamp of the target modified record corresponding to the first transaction number is less than the flashback time, and the second transaction commit timestamp of the target modified record corresponding to the second transaction number is greater than the flashback time, then the modification operation type is determined to be a delete operation type. Based on the modification operation type corresponding to each of the target modification records, perform a data recovery operation on the target data table that is the opposite of each of the modification operation types, so as to restore the target data table to the flashback time.

2. The method according to claim 1, characterized in that, The step of performing data recovery processing on the target data table according to the modification operation type corresponding to each target modification record includes: Based on the modification operation type corresponding to each target modification record, determine the data recovery operation corresponding to each target modification record; Based on the transaction commit timestamp corresponding to each of the target modification records, the first execution order of each of the data recovery operations is determined, wherein the transaction commit timestamp is used to characterize the time when the modification record was committed; Perform the data recovery operations corresponding to each of the target modified records in the first execution order.

3. The method according to claim 2, characterized in that, The step of determining the data recovery operation corresponding to each target modified record based on the modification operation type of each target modified record includes: For each of the target modified records, if the modification operation type corresponding to the target modified record is a deletion operation type, then the insertion operation is determined as the data recovery operation corresponding to the target modified record; if the modification operation type corresponding to the target modified record is an insertion operation type, then the deletion operation is determined as the data recovery operation corresponding to the target modified record.

4. The method according to claim 3, characterized in that, The step of performing data recovery operations corresponding to each of the target modified records according to the first execution order includes: According to the first execution order, the data table data corresponding to the target modified record of the corresponding data restoration operation that is an insert operation is inserted into the target data table; the data table data corresponding to the target modified record of the corresponding data restoration operation that is a delete operation is deleted from the target data table.

5. The method according to any one of claims 1 to 4, characterized in that, The determination of the set of visible records includes: Determine the target transaction snapshot that is closest to the current time from multiple transaction snapshots corresponding to the target data table; The set of visible records is determined based on the snapshot timestamp corresponding to the target transaction snapshot and the transaction commit timestamp corresponding to each modification record of the target transaction snapshot. The snapshot timestamp is used to characterize the time when the transaction snapshot was created, and the transaction commit timestamp is used to characterize the time when the modification record was committed.

6. A data recovery method, characterized in that, The method includes: Upon receiving a data recovery instruction for a target data object in the database, the target object identifier of the target data object is obtained; based on the target object identifier, the target backup data stream corresponding to the target data object is determined from the historical backup data stream. The historical backup data stream is the backup data stream corresponding to each data object that has undergone a data object deletion operation. The backup data stream includes the data content corresponding to each data object and the data content corresponding to the cascaded objects of each data object. The data content includes data definition content and data file content. A third execution order is determined based on the cascading relationship between the data objects corresponding to the target backup data stream; data recovery operations are performed on each data object corresponding to the target backup data stream according to the third execution order; determining the third execution order based on the cascading relationship between the data objects corresponding to the target backup data stream includes: sorting each data object according to the hierarchy corresponding to each data object, from high-level to low-level, to obtain the third execution order.

7. A data recovery device, characterized in that, The device includes: A receiving module is configured to, upon receiving a data recovery instruction for a target data table in a database, determine a set of visible records. This set of visible records includes target modification records of the target data table, which are used to record completed modification operations on the target data table. The step of determining the set of visible records includes: obtaining transaction identifiers and transaction status information carried in each historical modification record of the target data table; and, based on the transaction identifiers and transaction status information, selecting historical modification records that are visible at the flashback time indicated by the data recovery instruction as the target modification records. The transaction identifiers and transaction status information are allocated to each historical modification record based on a Multi-Version Concurrency Control (MVCC) mechanism. The determination module is configured to determine the modification operation type corresponding to each target modification record as an insert operation type if the first transaction commit timestamp of the target modification record corresponding to the first transaction number is greater than the flashback time indicated by the data recovery instruction, and the second transaction number is zero; and to determine the modification operation type as a delete operation type if the first transaction commit timestamp of the target modification record corresponding to the first transaction number is less than the flashback time, and the second transaction commit timestamp of the target modification record corresponding to the second transaction number is greater than the flashback time. The recovery module is used to perform a data recovery operation on the target data table that is opposite to the modification operation type corresponding to each of the target modification records, so as to restore the target data table to the flashback time.

8. A data recovery device, characterized in that, The device includes: The receiving module is configured to, upon receiving a data recovery instruction for a target data object in the database, obtain the target object identifier of the target data object; and, based on the target object identifier, determine the target backup data stream corresponding to the target data object from the historical backup data stream, wherein the historical backup data stream is the backup data stream corresponding to each data object that has undergone a data object deletion operation, and the backup data stream includes the data content corresponding to each data object and the data content corresponding to the cascaded objects of each data object, wherein the data content includes data definition content and data file content; The recovery module is used to determine a third execution order based on the cascading relationship between data objects corresponding to the target backup data stream; and to perform data recovery operations on each data object corresponding to the target backup data stream according to the third execution order. Specifically, the recovery module is used to sort each data object according to the level corresponding to each data object, in order from high level to low level, to obtain the third execution order.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5; or, when the processor executes the computer program, it implements the steps of the method according to claim 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 5; or, when the processor executes the computer program, it implements the steps of the method according to claim 6.

Images