CN112052120B - Database deleted data recovery method and device - Google Patents
Database deleted data recovery method and device Download PDFInfo
- Publication number
- CN112052120B CN112052120B CN202010878851.1A CN202010878851A CN112052120B CN 112052120 B CN112052120 B CN 112052120B CN 202010878851 A CN202010878851 A CN 202010878851A CN 112052120 B CN112052120 B CN 112052120B
- Authority
- CN
- China
- Prior art keywords
- data
- determining
- data block
- offset address
- flag
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
Abstract
The embodiment of the application discloses a database deleted data recovery method and device. One embodiment of the method comprises: determining a data segment set from a preset database file; for each data segment in the set of data segments, determining a set of data regions from the data segment; for each data area in the set of data areas, determining a set of data blocks from the data area; determining a valid data block from the data block set; and determining a line type mark corresponding to each line of data in the effective data block, and recovering the line type mark as the line of data corresponding to the deletion mark. The implementation mode effectively utilizes the structure of the data stored in the database, accurately positions the storage position of the deleted data and recovers the deleted data, and realizes accurate and comprehensive recovery of the deleted data in the database.
Description
Technical Field
The embodiment of the application relates to the technical field of computers, in particular to a database deleted data recovery method and device.
Background
A database is a warehouse that organizes, stores, and manages data in a data structure so that automated management of data can be achieved using computers, and thus, the database has been widely used for management in various departments in various enterprises.
For example, the Oracle database is one of the most popular client/server (client/server) architecture databases at present, and is also the most widely used database management system in the world at present, and serves as a general database system which has complete data management functions; as a relational database, it is a complete relational product; it implements distributed processing functions as a distributed database.
Currently, a database deletion record recovery technology has been concerned in the field of data security. Taking Oracle as an example, there is no effective | Oracle deleted data record recovery technology in the market at present, so that the deleted data cannot be recovered effectively.
Disclosure of Invention
An object of the embodiments of the present application is to provide an improved database deletion data recovery method and apparatus, so as to solve the technical problems mentioned in the above background.
In a first aspect, an embodiment of the present application provides a database deletion data recovery method, where the method includes: determining a data segment set from a preset database file; for each data segment in the set of data segments, determining a set of data regions from the data segment; for each data area in the set of data areas, determining a set of data blocks from the data area; determining a valid data block from the data block set; and determining a line type mark corresponding to each line of data in the effective data block, and recovering the line type mark as the line of data corresponding to the deletion mark.
In some embodiments, determining valid data blocks from the set of data blocks comprises: for each data block in the data block set, extracting a data flag at a target storage location of the data block; based on the data flag, it is determined whether the data block is a valid data block.
In some embodiments, extracting the data flag at the preset storage location of the data block includes: respectively extracting data marks stored in a target address from the head information of the kernel cache block at the head of the data block, the block check information at the tail of the data block and the fixed head information; determining whether the data block is a valid data block based on the data flag, including: and in response to determining that each data flag is a valid data flag, determining the data block as a valid data block.
In some embodiments, determining a row type flag corresponding to each row of data in the valid data block, and restoring the row of data corresponding to the row type flag as the delete flag comprises: determining a set of entry lists from the valid data blocks; for each table directory in the table directory set, extracting a row directory offset address set based on the table directory; for each row directory offset address in the set of row directory offset addresses, reading a row type flag based on the row directory offset address; in response to determining that the row type flag is a delete flag, an offset address of the delete data is determined based on the delete flag, and the delete data is restored according to the offset address of the delete data.
In some embodiments, determining a set of entries from the valid data blocks comprises: extracting kernel data block header information from the valid data block; reading the number of the table entries from a preset position of the kernel data block header information; determining a starting offset address of the entry set; and reading the entry set based on the number of the entries and the initial offset address of the entry set.
In some embodiments, extracting the kernel data block header information from the valid data block includes: determining an offset address of a transaction slot number value from a valid data block; determining an offset address of unknown information based on the offset address of the transaction slot number value; determining an offset address of the kernel data block header information based on the offset address of the unknown information; and extracting the kernel data block header information based on the offset address of the kernel data block header information and the size of the kernel data block header information.
In some embodiments, prior to determining the offset address of the delete data based on the delete flag in response to determining the row type flag is the delete flag, the method further comprises: determining the size of a free space from the kernel data block header information; based on the size of the free space, a start offset address of a space for storing the line data is determined.
In some embodiments, determining an offset address for the deleted data based on the delete flag comprises: an offset address for deleting data is determined from a space for storing line data based on the deletion flag.
In a second aspect, an embodiment of the present application provides an apparatus for recovering deleted data of a database, where the apparatus includes: the first determining module is used for determining a data segment set from a preset database file; a second determining module, configured to determine, for each data segment in the set of data segments, a set of data regions from the data segment; a third determining module, configured to determine, for each data area in the set of data areas, a set of data blocks from the data area; a fourth determining module, configured to determine a valid data block from the data block set; and the recovery module is used for determining the line type mark corresponding to each line of data in the effective data block and recovering the line of data with the line type mark as the deletion mark.
In a third aspect, an embodiment of the present application provides an electronic device, including: one or more processors; storage means for storing one or more programs which, when executed by one or more processors, cause the one or more processors to carry out a method as described in any one of the implementations of the first aspect.
In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements the method as described in any implementation manner of the first aspect.
According to the method and the device for recovering the deleted data of the database, the data segment set is determined from the preset database file, the data area set is determined from the data segment, the data block set is determined from the data area, the effective data block is determined from the data block set, and finally the deleted data is determined and recovered according to the row type mark corresponding to each row of data in the effective data block, so that the structure of the stored data in the database is effectively utilized, the storage position of the deleted data is accurately positioned and recovered, and the deleted data in the database is accurately and comprehensively recovered. The data is recovered by analyzing the database file, the database service is not required to be operated, and the deleted record can be recovered without depending on whether the log file and the transaction are opened or not.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
FIG. 1 is an exemplary system architecture diagram in which the present application may be applied;
FIG. 2 is a flow diagram for one embodiment of a database deletion data recovery method according to the present application;
FIG. 3 is a flow diagram of yet another embodiment of a database deletion data recovery method according to the present application;
FIG. 4 is an exemplary block diagram of a data block in an Oracle database according to the database deletion data recovery method of the present application;
FIG. 5 is a schematic diagram illustrating an embodiment of a database deletion data recovery apparatus according to the present application;
FIG. 6 is a schematic block diagram of a computer system suitable for use in implementing an electronic device according to embodiments of the present application.
Detailed Description
The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
Fig. 1 illustrates an exemplary system architecture 100 to which the database deletion data recovery method of the embodiments of the present application may be applied.
As shown in fig. 1, system architecture 100 may include terminal device 101, network 102, and server 103. Network 102 is the medium used to provide communication links between terminal devices 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
A user may use terminal device 101 to interact with server 103 over network 102 to receive or send messages and the like. Various communication client applications, such as a data management application, a search application, a web browser application, a shopping application, an instant messaging tool, etc., may be installed on the terminal device 101.
The terminal device 101 may be various electronic devices including, but not limited to, a mobile terminal such as a mobile phone, a notebook computer, a digital broadcast receiver, a PDA (personal digital assistant), a PAD (tablet computer), a PMP (portable multimedia player), a vehicle-mounted terminal (e.g., a car navigation terminal), etc., and a fixed terminal such as a digital TV, a desktop computer, etc.
The server 103 may be a server that provides various services, such as a background database server that provides support for data used on the terminal device 101. The background database server may store data sent by the terminal device 101 or send data to the terminal device 101, and the background database server may also provide data to other servers or receive data from other servers.
It should be noted that the database deletion data recovery method provided in the embodiment of the present application may be executed by the terminal device 101 or the server 103, and accordingly, the database deletion data recovery apparatus may be disposed in the terminal device 101 or the server 103.
It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation. In the case where the database file does not need to be acquired from a remote location, the system architecture described above may not include a network, and only include a server or a terminal device.
With continued reference to FIG. 2, a flow 200 of one embodiment of a database deletion data recovery method according to the present application is shown. The method comprises the following steps:
In this embodiment, an execution subject (for example, the terminal device or the server shown in fig. 1) of the database deletion data recovery method may determine the data segment set from a preset database file. Wherein a database file is a file (e.g., DBF file) for storing data in a database. The smallest particle for a database (e.g., an Oracle database or other similar database) to hold data in this embodiment is a data block (also called a logical block, an Oracle block, or a page). One data block corresponds to a particular amount of physical database space on disk.
The next level of logical database space is the data area. A data area includes a certain number of consecutive data blocks for holding a certain type of information.
A logical database above the data area stores the hierarchical calling data segments. The data section includes a series of data areas.
As an example, for an Oracle database, the execution body may set a preset size of space (for example, 8 kbytes) as a unit, then traverse all information of the DBF file, if a first byte of a header of the read unit is 0x23, the unit is a start unit of a data segment, and according to the start unit, a data segment set Su ═ S1, S2, S3.
For each data segment in the set of data segments, a set of data regions is determined from the data segment, step 202.
In this embodiment, for each data segment in the set of data segments, the execution body may determine the set of data regions from the data segment.
As an example, for an Oracle database, for a certain data segment Si of Su ═ { S1, S2, S3...... Sn }, segment header information (KTEMH) is read from the 72 th byte of Si, the number of data areas is calculated from the KTEMH information (KTEMH [0] + KTEMH [1] < <8), the data areas are cyclically analyzed from the 90 th byte of Si according to the number of data areas (KTETB), and the analysis rule: the data area is (KTETB [3] < <0x18) + KTETB [2] < <0x10+ KTETB [1] < <0x08+ KTETB [0 ]). Finally, a data area set Eu included in each data segment is obtained, wherein Eu is { E1, E2, E3..
For each data region in the set of data regions, a set of data blocks is determined from the data region, step 203.
In this embodiment, for each data area in the data area set, the execution body may determine the data block set from the data area.
As an example, for an Oracle database, for a certain data area Ei of Eu { E1, E2, E3..... En }, the number of data blocks contained in each data area is calculated as (KTETB [7] < <0x18) + KTETB [6] < <0x10+ KTETB [5] < <0x08+ KTETB [4]), the number of cyclically read blocks and the block data are calculated as (Ei &0x3 fffffff), the size of each block is fixed 8K bytes, and a block data set Bu { B1, B2, B3.... Bn } contained in Ei is obtained.
In this embodiment, the execution subject may determine a valid data block from the data block set. Wherein the valid data block is a data block storing valid data. The execution body may determine whether the data block is a valid data block according to a specific flag in the data block.
In some optional implementations of this embodiment, step 204 may be performed as follows:
step 2041, for each data block in the set of data blocks, extracts the data flag at the target storage location of the data block.
The data flag is used for representing whether the data block is a valid data block. In general, a technician may set a target storage location in advance according to a structure of a database stored in the database, and the execution main body reads data of the target storage location to obtain a data flag.
Step 2042, based on the data flag, determines whether the data block is a valid data block.
The data flag is used to characterize whether the data block is a valid data block, and if the data flag is a specific value, the data block can be determined to be a valid data block.
It should be noted that the target storage location may be at least one location, that is, the number of the data flags may be at least one, and by determining at least one data flag, it may be determined whether the data block is a valid data block. For example, when at least one of the data flags is a specific value, the data block may be determined to be a valid data block.
According to the implementation mode, the data marks are extracted, whether the data blocks are valid data blocks or not is determined according to the data marks, invalid data blocks can be excluded from the range of data recovery, and the efficiency and pertinence of the data recovery are further improved.
In some optional implementations of this embodiment, for each data block in the data block set, the executing main body may execute step 2041 according to the following steps:
and respectively extracting data marks stored in the target address from the core cache block head information at the head part of the data block, the block check information at the tail part of the data block and the fixed head information. The sizes and offset addresses of the core cache block head information, the tail block check information and the fixed head information are predetermined.
Based on this step, the above step 2042 may be performed as follows:
and in response to determining that each data flag is a valid data flag, determining the data block as a valid data block.
As an example, for an Oracle database, the execution subject may sequentially acquire all blocks Bi in a data block set B ═ { B1, B2, B3.... Bn }, and set an Offset address Offset of 0 at a Bi start position for a certain database Bi; reading and obtaining 20 bytes of kernel cache block header information (KCBH) at the head of the block, wherein the 1 st byte is a data mark, if the value is 6, the data block is represented as an effective data block, continuing to execute the following judgment, and otherwise, reading the next data block.
Reading block verification information (TAILCHK) of 4 bytes at the tail of the block as a data mark, judging whether the data block is a valid data block or not according to the data mark, and verifying the rule: (tailchck [0] & & TAILCHK [1] ═ KCBH [0] & & TAILCHK [2] ═ KCBH [8] & & TAILCHK [3] ═ KCBH [9]), if the rule is met, the following determination is continued, otherwise the next data block is read.
Setting Offset of transaction fixed header information (KTBBH), reading 24 bytes of KTBBH at the Offset, wherein the first byte represents a block type mark, when the type mark is 1, the data block is a valid data block, otherwise, reading the next data block. Until all the data blocks in the data block set B are judged to be finished.
According to the implementation mode, the data marks are extracted from the kernel cache block head information, the tail block check information and the fixed head information, so that the mechanism characteristics of the data block can be effectively utilized, whether the data block is an effective data block or not can be further accurately judged, and the efficiency and the accuracy of data recovery are improved.
In this embodiment, the execution subject may determine a line type flag corresponding to each line of data in the valid data block, and restore the line of data corresponding to the line type flag being the deletion flag.
The line data in the data block is stored in a specific area in the data block, and the execution body can position the line data from the line data area according to the structure of the data block. And then reading the line type mark of the line data, determining whether the line data is deleted data according to the line type mark, and recovering the line data by extracting or modifying the line type mark of the line data from the deleted data if the line data is deleted data.
The method provided by the above embodiment of the present application determines a data segment set from a preset database file, determines a data area set from a data segment, determines a data block set from a data area, then determines an effective data block from the data block set, and finally determines and recovers deleted data according to a row type flag corresponding to each row of data in the effective data block, thereby effectively utilizing a structure of data stored in a database, accurately positioning and recovering a storage location of the deleted data, and realizing accurate and comprehensive recovery of the deleted data in the database. The data is recovered by analyzing the database file, the database service is not required to be operated, and the deleted record can be recovered without depending on whether the log file and the transaction are opened or not. It should be noted that the embodiment of the present application can be applied to an Oracle database, and since the Oracle database does not support recovery of deleted data, the embodiment can accurately recover deleted data in the Oracle data.
With further reference to FIG. 3, a flow 300 of yet another embodiment of a database deletion data recovery method according to the present application is illustrated. On the basis of the steps shown in fig. 2, step 205 may include the following steps:
In this embodiment, the execution body may determine the entry set from the valid data block. The table directory is used for storing relevant information of the table, and a plurality of rows of data can be stored in one table.
The execution body may determine the storage location of the table directory set according to the mechanism of the data block, as shown in fig. 4, which shows the data block structure in the Oracle database, including data block header information (block header), table directory (table directory), row directory (row directory), free space (free space), and row record data (row data). The execution entity may determine offset addresses of each portion in the database according to the structure, thereby determining the table directory set Tu { T1, T2, T3.... Tn }.
In this embodiment, for each table directory in the set of table directories, the execution body may extract a set of row directory offset addresses based on the table directory.
As an example, for an Oracle database, for an entry Ti in an entry set Tu ═ { T1, T2, T3.... Tn }, the header 4 bytes information (KDBT) in Ti may be read, the value of an offset address (KDBT [0] < <0x08+ KDBT [1]) is calculated, and a line directory offset address set Ru ═ R1, R2, R3.... Rn } is extracted from the offset address.
At step 2053, for each row directory offset address in the set of row directory offset addresses, a row type flag is read based on the row directory offset address.
In this embodiment, for each row directory offset address in the set of row directory offset addresses, the row type flag is read based on the row directory offset address.
As an example, for a line directory Offset address Ri in the line directory Offset address set Ru ═ { R1, R2, R3.... Rn }, an Offset address Offset ═ Offset + Ri is set, where Offset to the right of the equal sign indicates the start address of Ri, and Offset to the left of the equal sign indicates the line directory Offset address after Ri.
Reading a first byte from the current Offset position Offset as a line type FLAG (FLAG), the line type FLAG including: 0xAC, 0x6C, 0x7C, 0x4C, 0x 3C. In addition, the second byte can be read as LOCK information (LOCK), and the third byte can be read as the number of fields (COLS) in the table.
In this embodiment, the execution body may determine, in response to determining that the row type flag is the delete flag, an offset address of the delete data based on the delete flag, and restore the delete data according to the offset address of the delete data.
As an example, when the line type flag is 0x3C, it is determined to be a deletion flag. The Offset address of the line data corresponding to the erasure flag is Offset +1 (the first byte of the Offset address is an erasure flag bit). In addition, the calculation rule of the offset address corresponding to the other line type flags is as follows: FLAG ═ 0 xc Offset ═ Offset + 16; FLAG ═ 0x6C Offset ═ Offset + 1; FLAG is 0x7C Offset + 16; FLAG is 0x4C Offset is Offset + 7.
The execution body can read the deleted data according to the offset address of the deleted data, so that the deleted data can be recovered. As an example, for the start position of a certain line data, the first byte is the number of fields (COLS), the LENGTH of a line data record is determined by the number of fields (COLS) and the LENGTH of a field (LENGTH), and the regular record LENGTH is calculated as (COLS (LENGTH + 1)). And circularly analyzing field information (field LENGTH + field value DATA) from the second byte according to the field number (COLS), analyzing rules { the first byte is the field LENGTH LENGTH, the second byte to the third byte are the field value DATA, and analyzing the field values to obtain the row DATA records.
In some optional implementations of this embodiment, the step 2051 may include the following sub-steps:
step 20511, core data block header information is extracted from the valid data block.
Specifically, according to the structure of the data block in the database, the offset address of the core data block header information can be determined, so as to locate the core data block header information.
As an example, for an Oracle database, the execution body may read 14 byte kernel data block header information (KDBH) from Offset.
And step 20512, reading the number of the entries from the preset position of the core data block header information.
By way of example, KDBH [1] stores the number of table directories, and thus the number of table directories can be read from KDBH [1 ].
At step 20513, the start offset address of the entry set is determined.
Specifically, the starting offset address of the table directory set may be determined from the KDBH described above. For example, the KDBH is followed by the starting offset address of the table directory.
At step 20514, the entry set is read based on the entry number and the starting offset address of the entry set.
For example, the entry set Tu is cyclically read out according to the entry number and the start offset address of the entry set { T1, T2, T3.
Through the steps 20511 to 20514, the size and the storage position of the table directory set can be determined based on the kernel data block header information, the table directory set can be accurately extracted, and the accuracy of data recovery is improved.
In some optional implementations of this embodiment, the step 20511 may include the following steps:
first, an offset address for the transaction slot number value is determined from the valid data block.
Specifically, after the memory region used to determine whether a data block is a valid data block, there may be an offset address of the number of transaction slots itl slots). For example, for an Oracle database, the transaction slot number is recorded in the 36 th byte in the transaction fixed header information KTBBH information.
Then, based on the offset address of the transaction slot number value, an offset address of unknown information is determined.
Specifically, for an Oracle database, based on the offset address of the transaction slot number value, an offset address of 8 bytes of unknown information can be further determined.
Then, based on the offset address of the unknown information, the offset address of the kernel data block header information is determined.
As an example, after 8 bytes of unknown information, there may be an offset address of the kernel data block header information.
And finally, extracting the kernel data block header information based on the offset address of the kernel data block header information and the size of the kernel data block header information.
As an example, 14 byte kernel data block header information (KDBH) may be read from the current offset address.
The realization mode can further accurately extract the kernel data block head information by determining the offset address of the transaction slot number value, the offset address of the unknown information and the offset address of the kernel data block head information, thereby being beneficial to further improving the accuracy of data recovery.
In some optional implementations of this embodiment, before step 2054, the executing body may further perform the following steps:
first, the size of the free space is determined from the kernel block header information.
By way of example, for an Oracle database, the size of the free space (FREESPQCE) is: FREESPQCE ═ KDBH [9] < <0x08+ KDBH [10 ]).
Then, based on the size of the free space, a start offset address of a space for storing line data is determined.
Specifically, as shown in fig. 4, according to the data block structure shown therein, after the size of the free space (free space) is determined, the start offset address of the space for storing line data located after the free space (i.e., the space indicated by row data in fig. 4) can be determined.
The implementation mode can further accurately determine the initial offset address of the space for storing the row data by determining the size of the free space, and is favorable for further accurately positioning the storage position where the deleted data is located.
In some optional implementations of this embodiment, in step 2054, the execution subject may determine, based on the deletion flag, an offset address of the deleted data according to the following steps:
based on the deletion flag, an offset address for deleting data is determined from the space for storing the line data. Since the starting offset address of the space for storing the line data is determined in the optional implementation manner, the implementation manner can accurately determine the offset address for deleting the data in the space for storing the line data, thereby further improving the accuracy of data recovery.
The method provided by the embodiment corresponding to fig. 3 of the present application determines the entry set and the row directory offset address set from the valid data block, determines the type flag of each row of data according to each row directory offset address, and determines the address of the deleted data according to the type flag, so that the deleted data can be recovered, and the structure and data distribution rules of the database are effectively utilized to accurately recover the deleted data.
With further reference to fig. 5, as an implementation of the method shown in the above-mentioned figures, the present application provides an embodiment of a database deletion data recovery apparatus, where the embodiment of the apparatus corresponds to the embodiment of the method shown in fig. 2, and the apparatus may be specifically applied to various electronic devices.
As shown in fig. 5, the database deletion data recovery apparatus 500 of the present embodiment includes: a first determining module 501, configured to determine a data segment set from a preset database file; a second determining module 502, configured to determine, for each data segment in the set of data segments, a set of data regions from the data segment; a third determining module 503, configured to determine, for each data area in the set of data areas, a set of data blocks from the data area; a fourth determining module 504, configured to determine a valid data block from the data block set; and a recovery module 505, configured to determine a line type flag corresponding to each line of data in the valid data block, and recover the line of data corresponding to the line type flag as the deletion flag.
In this embodiment, the first determining module 501 may determine the data segment set from a preset database file. Wherein a database file is a file (e.g., DBF file) for storing data in a database. The smallest particle for a database (e.g., an Oracle database or other similar database) to hold data in this embodiment is a data block (also called a logical block, an Oracle block, or a page). One data block corresponds to a particular amount of physical database space on disk.
The next level of logical database space is the data area. A data area includes a certain number of consecutive data blocks for holding a certain type of information.
A logical database above the data area stores the hierarchical calling data segments. The data section includes a series of data areas.
As an example, for an Oracle database, the first determining module 501 may set a preset size of space (for example, 8 kbytes) as a unit, then traverse all information of the DBF file, if a first byte of a header of the reading unit is 0x23, the unit is a start unit of a data segment, and according to the start unit, a data segment set Su ═ S1, S2, S3.
In this embodiment, for each data segment in the set of data segments, the second determining module 502 may determine the set of data regions from the data segment.
As an example, for an Oracle database, for a certain data segment Si of Su ═ { S1, S2, S3...... Sn }, segment header information (KTEMH) is read from the 72 th byte of Si, the number of data areas is calculated from the KTEMH information (KTEMH [0] + KTEMH [1] < <8), the data areas are cyclically analyzed from the 90 th byte of Si according to the number of data areas (KTETB), and the analysis rule: the data area is (KTETB [3] < <0x18) + KTETB [2] < <0x10+ KTETB [1] < <0x08+ KTETB [0 ]). Finally, a data area set Eu included in each data segment is obtained, wherein Eu is { E1, E2, E3..
In this embodiment, for each data area in the set of data areas, the third determining module 503 may determine the set of data blocks from the data area.
As an example, for an Oracle database, for a certain data area Ei in Eu ═ { E1, E2, E3... En }, the number of data blocks contained in each data area is calculated (KTETB [7] < <0x18) + KTETB [6] < <0x10+ KTETB [5] < <0x08+ KTETB [4]), and the number of blocks and block data are read cyclically as (Ei &0x3 fffffff), so that all block data sets Bu contained in Ei are obtained as { B1, B2, B3.. Bn }.
In this embodiment, the fourth determining module 504 may determine a valid data block from the set of data blocks. Wherein the valid data block is a data block storing valid data. The fourth determining module 504 may determine whether the data block is a valid data block according to a specific flag in the data block.
In this embodiment, the recovery module 505 may determine a row type flag corresponding to each row of data in the valid data block, and recover the row of data corresponding to the row type flag being the deletion flag.
The line data in the data block is stored in a specific area in the data block, and the recovery module 505 may locate the line data from the line data area according to the structure of the data block. And then reading the line type mark of the line data, determining whether the line data is deleted data according to the line type mark, and recovering the line data by extracting or modifying the line type mark of the line data from the deleted data if the line data is deleted data.
In some optional implementations of this embodiment, the fourth determining module 504 may include: a first extraction unit (not shown in the figure) for extracting, for each data block in the set of data blocks, a data flag at a target storage location of the data block; a first determining unit (not shown in the figure) for determining whether the data block is a valid data block based on the data flag.
In some optional implementations of this embodiment, the first extraction unit may be further configured to: respectively extracting data marks stored in a target address from the head information of the kernel cache block at the head of the data block, the block check information at the tail of the data block and the fixed head information; the first determination unit is further configured to: and in response to determining that each data flag is a valid data flag, determining the data block as a valid data block.
In some optional implementations of this embodiment, the recovery module 505 may include: a second determining unit (not shown in the figure) for determining a set of entry lists from the valid data blocks; a second extracting unit (not shown in the figure) for extracting, for each table directory in the set of table directories, a set of row directory offset addresses based on the table directory; a first reading unit (not shown in the figure) for reading the row type flag based on the row directory offset address for each row directory offset address in the row directory offset address set; and a restoring unit (not shown in the figure) for determining an offset address of the deleted data based on the deletion flag in response to determining that the row type flag is the deletion flag, and restoring the deleted data according to the offset address of the deleted data.
In some optional implementations of this embodiment, the second determining unit may include: an extraction subunit (not shown in the figure) for extracting the kernel data block header information from the valid data block; a first reading subunit (not shown in the figure) for reading the number of the entry records from a preset position of the kernel data block header information; a first determining subunit (not shown in the figure) for determining a starting offset address of the entry set; a second reading subunit (not shown in the figure) is configured to read the entry set based on the entry number and the start offset address of the entry set.
In some optional implementations of this embodiment, the extracting subunit may be further configured to: determining an offset address of a transaction slot number value from a valid data block; determining an offset address of unknown information based on the offset address of the transaction slot number value; determining an offset address of the kernel data block header information based on the offset address of the unknown information; and extracting the kernel data block header information based on the offset address of the kernel data block header information and the size of the kernel data block header information.
In some optional implementations of this embodiment, the recovery module 505 may further include: a second determining subunit (not shown in the figure) for determining the size of the free space from the kernel data block header information; a third determining subunit (not shown in the figure) for determining a start offset address of the space for storing the line data based on the size of the free space.
In some optional implementations of this embodiment, the recovery unit is further configured to: an offset address for deleting data is determined from a space for storing line data based on the deletion flag.
According to the device provided by the embodiment of the application, the data segment set is determined from the preset database file, the data area set is determined from the data segment, the data block set is determined from the data area, then the effective data block is determined from the data block set, and finally the deleted data is determined and recovered according to the row type mark corresponding to each row of data in the effective data block, so that the structure of data stored in the database is effectively utilized, the storage position of the deleted data is accurately positioned and recovered, and the deleted data in the database is accurately and comprehensively recovered. The data is recovered by analyzing the database file, the database service is not required to be operated, and the deleted record can be recovered without depending on whether the log file and the transaction are opened or not. It should be noted that the embodiment of the present application can be applied to an Oracle database, and since the Oracle database does not support recovery of deleted data, the embodiment can accurately recover deleted data in the Oracle data.
Referring now to FIG. 6, shown is a block diagram of a computer system 600 suitable for use in implementing the electronic device of an embodiment of the present application. The electronic device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the system 600 are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output portion 607 including a display such as a Liquid Crystal Display (LCD) and a speaker; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.
In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The computer program performs the above-described functions defined in the method of the present application when executed by a Central Processing Unit (CPU) 601.
It should be noted that the computer readable storage medium described herein can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable storage medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules described in the embodiments of the present application may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a first determination module, a second determination module, a third determination module, a fourth determination module, and a recovery module. Where the names of these modules do not in some cases constitute a limitation of the unit itself, for example, the first determining module may also be described as a "module for determining a set of data segments from a preset database file".
As another aspect, the present application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable storage medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: determining a data segment set from a preset database file; for each data segment in the set of data segments, determining a set of data regions from the data segment; for each data area in the set of data areas, determining a set of data blocks from the data area; determining a valid data block from the data block set; and determining a line type mark corresponding to each line of data in the effective data block, and recovering the line type mark as the line of data corresponding to the deletion mark.
The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention herein disclosed is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the invention. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.
Claims (8)
1. A database deletion data recovery method, the method comprising:
determining a data segment set from a preset database file;
for each data segment in the set of data segments, determining a set of data regions from the data segment;
for each data area in the set of data areas, determining a set of data blocks from the data area;
determining valid data blocks from the set of data blocks, comprising:
for each data block in the set of data blocks, extracting a data flag at a target storage location of the data block;
determining whether the data block is a valid data block based on the data flag;
the extracting of the data flag at the preset storage location of the data block includes:
respectively extracting data marks stored in a target address from the head information of the kernel cache block at the head of the data block, the block check information at the tail of the data block and the fixed head information;
the determining whether the data block is a valid data block based on the data flag includes:
in response to determining that each data flag is a valid data flag, determining that the data block is a valid data block;
determining a line type mark corresponding to each line of data in the effective data block, and recovering the line type mark as the line of data corresponding to the deletion mark, including:
determining a set of entries from the valid data blocks;
for each table directory in the table directory set, extracting a row directory offset address set based on the table directory;
for each row directory offset address in the set of row directory offset addresses, reading a row type flag based on the row directory offset address;
and in response to determining that the line type mark is a deletion mark, determining an offset address of the deleted data based on the deletion mark, and restoring the deleted data according to the offset address of the deleted data.
2. The method of claim 1, wherein determining the set of entries from the valid data blocks comprises:
extracting kernel data block header information from the valid data block;
reading the number of the table entries from the preset position of the kernel data block header information;
determining a starting offset address of the set of entry records;
and reading the entry set based on the number of the entries and the initial offset address of the entry set.
3. The method of claim 2, wherein extracting kernel block header information from the valid data block comprises:
determining an offset address of a transaction slot number value from the valid data block;
determining an offset address of unknown information based on the offset address of the transaction slot number value;
determining an offset address of the kernel data block header information based on the offset address of the unknown information;
and extracting the kernel data block header information based on the offset address of the kernel data block header information and the size of the kernel data block header information.
4. The method of claim 2 or 3, wherein prior to said determining that the row type flag is a delete flag, based on which an offset address for deleted data is determined, the method further comprises:
determining the size of a free space from the kernel data block header information;
and determining a starting offset address of a space for storing the row data based on the size of the free space.
5. The method of claim 4, wherein determining an offset address for the deleted data based on the delete flag comprises:
and determining an offset address for deleting data from the space for storing the line data based on the deletion flag.
6. An apparatus for database deletion data recovery, the apparatus comprising:
the first determining module is used for determining a data segment set from a preset database file;
a second determining module, configured to determine, for each data segment in the set of data segments, a set of data regions from the data segment;
a third determining module, configured to determine, for each data area in the set of data areas, a set of data blocks from the data area;
a fourth determining module, configured to determine a valid data block from the set of data blocks, including:
for each data block in the set of data blocks, extracting a data flag at a target storage location of the data block;
determining whether the data block is a valid data block based on the data flag;
the extracting of the data flag at the preset storage location of the data block includes:
respectively extracting data marks stored in a target address from the head information of the kernel cache block at the head of the data block, the block check information at the tail of the data block and the fixed head information;
the determining whether the data block is a valid data block based on the data flag includes:
in response to determining that each data flag is a valid data flag, determining that the data block is a valid data block;
a recovery module, configured to determine a row type flag corresponding to each row of data in the valid data block, and recover the row of data corresponding to the row type flag as a deletion flag, where the recovery module includes:
determining a set of entries from the valid data blocks;
for each table directory in the table directory set, extracting a row directory offset address set based on the table directory;
for each row directory offset address in the set of row directory offset addresses, reading a row type flag based on the row directory offset address;
and in response to determining that the line type mark is a deletion mark, determining an offset address of the deleted data based on the deletion mark, and recovering the deleted data according to the offset address of the deleted data.
7. An electronic device, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.
8. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010878851.1A CN112052120B (en) | 2020-08-27 | 2020-08-27 | Database deleted data recovery method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010878851.1A CN112052120B (en) | 2020-08-27 | 2020-08-27 | Database deleted data recovery method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112052120A CN112052120A (en) | 2020-12-08 |
| CN112052120B true CN112052120B (en) | 2022-08-05 |
Family
ID=73599968
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010878851.1A Active CN112052120B (en) | 2020-08-27 | 2020-08-27 | Database deleted data recovery method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112052120B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112612648B (en) * | 2020-12-29 | 2022-11-08 | 厦门市美亚柏科信息股份有限公司 | SQL Server database recovery method, terminal equipment and storage medium |
| CN112650725A (en) * | 2020-12-30 | 2021-04-13 | 四川效率源信息安全技术股份有限公司 | Method for recovering DM8 database log file |
| CN113282592B (en) * | 2021-07-22 | 2021-09-24 | 成都云祺科技有限公司 | Method, system and storage medium for recovering MSSQL database |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1991016677A1 (en) * | 1990-04-25 | 1991-10-31 | Unisys Corporation | Recoverability in mass storage data base systems |
| US6792435B1 (en) * | 1998-03-10 | 2004-09-14 | International Business Machines Corporation | Method and apparatus for recovering the definitions of dropped database objects |
| US7058664B1 (en) * | 2002-04-29 | 2006-06-06 | Sprint Communications Company L.P. | Method and system for data recovery |
| JP2007220029A (en) * | 2006-02-20 | 2007-08-30 | Nec Corp | Area-shared file management device, and method and program for restoring member deleted from area-shared file |
| CN105068887A (en) * | 2015-08-03 | 2015-11-18 | 四川效率源信息安全技术有限责任公司 | SQLServer database based data recovery method |
| CN106844607A (en) * | 2017-01-16 | 2017-06-13 | 重庆邮电大学 | A kind of SQLite data reconstruction methods suitable for non-integer major key and idle merged block |
| CN108009049A (en) * | 2017-11-28 | 2018-05-08 | 厦门市美亚柏科信息股份有限公司 | The offline restoration methods of MYISAM storage engines deletion records, storage medium |
| CN109101368A (en) * | 2018-08-20 | 2018-12-28 | 郑州云海信息技术有限公司 | A kind of data processing method and device |
| CN109726044A (en) * | 2017-10-27 | 2019-05-07 | Netapp股份有限公司 | Multiple files are efficiently restored from data de-duplication storage based on data block title |
| CN110062925A (en) * | 2016-10-28 | 2019-07-26 | Netapp股份有限公司 | Snapshot metadata arrangement for converging |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101547466B1 (en) * | 2014-03-28 | 2015-08-26 | 고려대학교 산학협력단 | Apparatus and method for recovering data in oracle database |
-
2020
- 2020-08-27 CN CN202010878851.1A patent/CN112052120B/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1991016677A1 (en) * | 1990-04-25 | 1991-10-31 | Unisys Corporation | Recoverability in mass storage data base systems |
| US5138710A (en) * | 1990-04-25 | 1992-08-11 | Unisys Corporation | Apparatus and method for providing recoverability in mass storage data base systems without audit trail mechanisms |
| US6792435B1 (en) * | 1998-03-10 | 2004-09-14 | International Business Machines Corporation | Method and apparatus for recovering the definitions of dropped database objects |
| US7058664B1 (en) * | 2002-04-29 | 2006-06-06 | Sprint Communications Company L.P. | Method and system for data recovery |
| JP2007220029A (en) * | 2006-02-20 | 2007-08-30 | Nec Corp | Area-shared file management device, and method and program for restoring member deleted from area-shared file |
| CN105068887A (en) * | 2015-08-03 | 2015-11-18 | 四川效率源信息安全技术有限责任公司 | SQLServer database based data recovery method |
| CN110062925A (en) * | 2016-10-28 | 2019-07-26 | Netapp股份有限公司 | Snapshot metadata arrangement for converging |
| CN106844607A (en) * | 2017-01-16 | 2017-06-13 | 重庆邮电大学 | A kind of SQLite data reconstruction methods suitable for non-integer major key and idle merged block |
| CN109726044A (en) * | 2017-10-27 | 2019-05-07 | Netapp股份有限公司 | Multiple files are efficiently restored from data de-duplication storage based on data block title |
| CN108009049A (en) * | 2017-11-28 | 2018-05-08 | 厦门市美亚柏科信息股份有限公司 | The offline restoration methods of MYISAM storage engines deletion records, storage medium |
| CN109101368A (en) * | 2018-08-20 | 2018-12-28 | 郑州云海信息技术有限公司 | A kind of data processing method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112052120A (en) | 2020-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112052120B (en) | Database deleted data recovery method and device | |
| CN109656923B (en) | Data processing method and device, electronic equipment and storage medium | |
| CN108897874B (en) | Method and apparatus for processing data | |
| CN112162965B (en) | Log data processing method, device, computer equipment and storage medium | |
| CN111259282B (en) | URL (Uniform resource locator) duplication removing method, device, electronic equipment and computer readable storage medium | |
| CN111274368A (en) | Slot filling method and device | |
| CN114035748A (en) | Data file access method and system | |
| CN110879808B (en) | Information processing method and device | |
| CN112506981A (en) | Online training service pushing method and device | |
| CN110990346A (en) | File data processing method, device, equipment and storage medium based on block chain | |
| CN111198861A (en) | Logic log processing method and device and electronic equipment | |
| US20220083507A1 (en) | Trust chain for official data and documents | |
| CN112579364B (en) | Deleted file deep recovery method and device based on QNX6FS file system | |
| CN111753141A (en) | Data management method and related equipment | |
| CN115587247A (en) | Method, device and equipment for monitoring user label and storage medium | |
| CN113918659A (en) | Data operation method and device, storage medium and electronic equipment | |
| CN114417102A (en) | Text duplicate removal method and device and electronic equipment | |
| CN110704372B (en) | Data recovery method and device | |
| CN108280139B (en) | POI data processing method, device, equipment and computer readable storage medium | |
| CN111143355A (en) | Data processing method and device | |
| CN114513558B (en) | User request processing method and device | |
| US11416158B1 (en) | Selective data unarchiving | |
| CN113407375B (en) | Database deleted data recovery method, device, equipment and storage medium | |
| CN110716885B (en) | Data management method and device, electronic equipment and storage medium | |
| CN110134691B (en) | Data verification method, device, equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |