KR102139578B1 - Method for restoring data of database through analysis of disc block pattern - Google Patents

Abstract

Disclosed is a method for recovering a database file through disk block pattern analysis.
A method for recovering a database file through disk block pattern analysis according to an embodiment of the present invention includes receiving a data file of a database through the input unit 10; Predicting the size of a block from a database block address (DBA) of the data file by the control unit 20; And predicting a file identification number from a database block address (DBA) by the control unit 20.

Description

How to recover database files through disk block pattern analysis {METHOD FOR RESTORING DATA OF DATABASE THROUGH ANALYSIS OF DISC BLOCK PATTERN}

The present invention relates to a method for recovering a database file through disk block pattern analysis. More specifically, the present invention relates to a method for recovering a database file through disk block pattern analysis that can predict structural information of a data file using only the data file.

In general, an organization uses a database to manage a large amount of data in an integrated manner, and thus, important information such as business data and personal information is often stored in the database. This means that there is a high likelihood that meaningful information will remain, so a database is an important research subject from a digital forensic perspective.

It is important to extract normal records from the database, but it is also important to recover deleted records. The user's behavior can be reconstructed through the recovery of deleted records, and it can respond to the suspect's deliberate destruction of evidence, which can greatly assist investigation.

Table space is a space that physically stores actual data in a database. By analyzing this table space, you can obtain table data and table schema information from the database. According to IDC, the Oracle database has a 40.7% share worldwide, and the Oracle database has a 60% share in the domestic database market.

In addition, previous studies on database forensics to date have focused on recovering records based on transaction logs. P. Wright explained how to track changes in the database through redolog and logminer in the Oracle database and how to restore data from a previous point in time. In addition, Heloise Pieterse summarized the technique of concealing data values, records, and tables using encryption and fragmented storage in the database, and emphasized the importance of transaction logs. Oluwasola Mary showed that queries can be expressed in algebra in a database. Also, the query can be represented in reverse, and a relational algebra log is proposed to store this formula. The method of restoring data from the previous point through this log was described. In general, when restoring deleted records in an Oracle database, DBF files and transaction logs must exist in pairs. Then, the deleted records are restored using the log miner in the running Oracle database. However, this method can only recover the time when the transaction log is recorded, and not the time when the transaction log is not recorded. In addition, in the case of No Archive Mode in the way of leaving the transaction log in the Oracle database, if the specified capacity is exceeded, the existing transaction log is overwritten, so whether or not to recover may be determined according to the Oracle database operating environment or company policy. have.

However, according to the prior art, when restoring data to a database, there was a problem that recovery is possible only through a transaction log. Research is needed to restore data without resorting to transaction logs.

As mentioned earlier, Oracle database is the most widely used product in the world among commercial DBMSs, and it is used in many institutions to manage and manage important data in Korea. If there is a problem with the Oracle database and the data cannot be accessed, the institution has difficulties in performing normal tasks.

In general, when a problem occurs in the Oracle database, it is possible to perform almost automated recovery using the recovery function, but it is impossible when some system files fail due to user's carelessness or system error.

For example, if the control file containing the structure information (block size, identification number, and path of the data file) of the Oracle database is damaged, the block size and identification number of the data file are also damaged. In this case, there is a problem that it is impossible to recover and extract data as well as to operate or start the database.

Therefore, when such a control file is damaged or lost, it becomes impossible to recover or extract the data file as well as movement or startup of the database.

In order to solve this problem, when a control file is damaged or lost, research into a method of estimating the structure information of each file using only data files is required.

The items described in the background art section are written to improve the understanding of the background of the invention, and may include matters that are not known to those skilled in the art to which this technology belongs.

The present invention is to solve the above problems, and provides a method for recovering a database file through disk block pattern analysis that can predict the structure information of a data file using only the data file when the control file of the database is damaged. It is aimed at.

A database file recovery method through disk block pattern analysis according to an embodiment of the present invention for achieving the above object comprises: receiving a data file of a database through the input unit 10; Predicting the size of a block from a database block address (DBA) of the data file by the control unit 20; And predicting a file identification number from a database block address (DBA) by the control unit 20.

The step of predicting the size of the block may include obtaining first data of a set size from an offset point set at the front of the data file; Obtaining second data of a size set at the end of the first data; And calculating the size of the block by dividing the maximum block size that can be configured in the database by the second data.

The step of predicting the file identification number may include obtaining third data having a set size from a DBA offset point of the second block of the data file; And predicting fourth data having a size set at the front of the third data using the file identification number.

In the data file, the plurality of blocks are continuously configured, the size of the data file is smaller than the size of a unit block, and the size of the block is made of a power of 2, and the first block of the data file is meta. It is data, and the database block address is located at a position set from the starting point of the block, and the number of the block can be sequentially increased from 0 to 1.

The database block address may be an identifier of a block position where all blocks except the first block of the data file have the same offset position.

According to the database file recovery method through disk block pattern analysis according to the embodiment of the present invention as described above, it is possible to predict the database file recovery method through disk block pattern analysis that can predict the structure information of the data file using only the data file. Can be.

Since these drawings are for reference to explain exemplary embodiments of the present invention, the technical spirit of the present invention should not be construed as being limited to the accompanying drawings.
1 is a block diagram of a database file recovery apparatus through disk block pattern analysis according to an embodiment of the present invention.
2 is a view for explaining the structure of a data file constituting a database according to an embodiment of the present invention.
3 is a view for explaining the structure of a database block address according to an embodiment of the present invention.
4 is a flowchart illustrating a database file recovery method through disk block pattern analysis according to an embodiment of the present invention.

The embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art to which the present invention pertains can easily practice. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein.

In order to clearly describe the present invention, parts irrelevant to the description are omitted, and the same reference numerals are assigned to the same or similar elements throughout the specification.

Additionally, several methods can be implemented by at least one controller.

The term controller refers to a hardware device comprising a memory and a processor adapted to execute one or more steps interpreted as an algorithmic structure.

The memory is adapted to store algorithmic steps, and the processor is specifically configured to execute the algorithmic steps to perform one or more of the processes described below.

Furthermore, the control logic of the present invention may be embodied in a non-transitory, computer-readable medium on a computer-readable means including executable program instructions executed by a processor, controller, or the like.

Examples of computer readable means include, but are not limited to, ROM, RAM, CD-ROM, magnetic tape, floppy disk, flash drive, smart card and optical data storage.

First, a database file recovery apparatus through disk block pattern analysis according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram of a database file recovery apparatus through disk block pattern analysis according to an embodiment of the present invention.

As shown in FIG. 1, a file recovery apparatus according to an embodiment of the present invention includes an input unit 10 for receiving a data file, and a control unit for predicting structure information of a data file from the data file input through the input unit 10 (20). The Oracle database is comprised of a control file and a data file.

The control file is a small binary file and contains structure information of the Oracle database. For example, it contains the necessary structure information to open the data file, such as the block size, identification number, and path of the data file and log file, and is the first file referenced by the Oracle database to start.

The data file is composed of a plurality of blocks, and when the Oracle database creates a data file, the size of one block can be set from a minimum of 1024 (1 KB) to a maximum of 262144 (256 KB). The smaller the size of the block, the smaller the size of the file by reducing the empty space in the file, and the larger the size of the block, the faster the operation speed of the database. The block size of the data file is stored in the control file. If the control file is damaged or lost, meaningful data cannot be extracted because the start and end of the block of the data file are unknown.

Blocks of data files in Oracle database have the following characteristics.

2 is a view for explaining the structure of a data file constituting a database according to an embodiment of the present invention.

As shown in Fig. 2, a data file consists of a series of blocks. And the size of the data file is larger than the size of the unit block. In addition, the possible block size is a power of 2 (1KB to 256KB: 1024 to 262144). And the first block of the data file is the metadata of the data file, not the data in the Oracle database. In addition, the database block address (DBA) is located at the Ox4 point (DBA offset) at the starting point of any one block. Finally, the block number is incremented by 1 in order, with the first block in the data file being 0.

The data file is composed of a plurality of blocks having the same size. The block is a minimum unit for managing the storage space of the data file, and is determined at the time of creating the data file.

In the above, the database block address (DBA) means an identifier of a block position that all blocks except the first block of the data file have at the same offset position (eg, Ox4).

3 is a view for explaining the structure of a database block address according to an embodiment of the present invention.

As shown in FIG. 3, the database block address is composed of 4 bytes (32 bits), the upper 10 bits mean the file number, and the lower 22 bits mean the block number.

As described above, when the control file is damaged or lost in consideration of the characteristics of the data file of the Oracle database and the database block address (DBA) described above, the file recovery apparatus according to an embodiment of the present invention uses the data file to recover the data file. The structure information (eg, the block size of the data file and the identification number of the data file) can be predicted.

Hereinafter, a method for recovering a database file through disk block pattern analysis according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

4 is a flowchart illustrating a database file recovery method through disk block pattern analysis according to an embodiment of the present invention.

As illustrated in FIG. 4, when the control file is damaged or lost, a data file of the Oracle database is received through the input unit 10 (S10 ). The data file input through the input unit 10 is transmitted to the control unit 20.

The control unit 20 predicts the size of the block from the database block address (DBA) included in the data file (S20).

Specifically, the control unit 20 obtains the first data of the set size from the offset point set at the front of the data file (S110).

Here, the offset point set at the front of the data file means the Ox40004 point, and the first data of the set size means 4 bytes (32-bit) data read from the Ox40004 point. Here, the set offset point is a value obtained by adding Ox4 (hereinafter referred to as'DBA offset') in which the database block address (DBA) is located at the maximum block size that can be configured in the database.

Therefore, the 4-byte data read at the Ox40004 point means a database block address (DBA) of any block in the database.

As mentioned earlier, Oracle databases have block sizes ranging from 1KB to 256KB. That is, the maximum possible block size in the database is 256KB (256*1026=262144), so converting it to hexadecimal results in Ox400000. Therefore, the first data means the DBA extracted from the next block of the largest block that can be set in the Oracle database.

And, as described above, since the database block addresser (DBA) is 4-byte data from the Ox4 point of each block, the second data, which is 4-byte data read from the Ox40004 point, is the database block read from the next block of the largest block. It means address (DBA).

The controller 20 acquires second data having a set size from the end of the first data read in step S110 (S120 ).

Here, when the second data of 22 bits, which is the size set at the end of the first data DBA, is read, the second data means the block number of the database block address DBA read from the next block of the maximum size block. .

The controller 20 calculates the size of the block by dividing the maximum block size in step S120 by the second data obtained in step S120 (S130).

For example, when the 22-bit data (second data) read from the end of the 4-byte data (first data) read from the set offset point Ox40004 is 4, the block number at this time is 4. Therefore, this block means that there are four more blocks (0th block to 3rd block) in front, and if the maximum block size of 256KB is divided by block number 4, it can be predicted that the size of each block is 64KB.

As another example, if the 22-bit data (second data) read from the end of the 4-byte data (first data) read from the set offset point Ox40004 is 1, the block number at this time is 1. Therefore, this block means that there is one more block (0th block) in front, and if the maximum block size of 256KB is divided by block number 1, it can be predicted that the size of each block is 256KB.

After predicting the size of the block from the database block address (DBA), the controller 20 predicts the file identification number from the database block address (DBA) (S30).

In order to predict the file identification number, it is preferable to predict the size of the block first and then predict the file identification number. That is, since the size of the block must be accurately predicted, the database block address can be accurately extracted from the data file, so the method of predicting the block size should precede the method of predicting the identification number.

Specifically, the controller 20 predicts the size of the block through step S20 described above.

Thereafter, the controller 20 acquires third data having a set size from the DBA offset point at the beginning of the second block of the data file (S210).

Here, the DBA offset point means the Ox4 point at the beginning of the second block of the data file, and the third data of the set size means 4 bytes (32-bit) data read from the Ox4 point at the beginning of the second block. That is, the third data of 4 bytes read from the Ox4 point means the database block address (DBA).

In step S20, since the block size of the data file is calculated, the starting point of the second block can be known. Therefore, the 4-byte data (third data) read from the Ox4 point of the second block becomes the database block address (DBA) of the corresponding block.

The controller 20 reads the fourth data of the size set in front of the third data read in step S210 and predicts the fourth data as the file identification number (S220).

Here, the 10-bit data (fourth data), which is the size set at the front of the third data DBA, means the identification number of the data file.

According to the file recovery method according to an embodiment of the present invention as described above, even if the control file constituting the Oracle database is damaged or lost, the structure information (eg, block size and identification) of the data file using only the data file Number).

Various embodiments described herein can be implemented in a computer- or similar device-readable recording medium using, for example, software, hardware, or a combination thereof.

According to a hardware implementation, the embodiments described herein include application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), It may be implemented using at least one of processors, controllers, micro-controllers, microprocessors, and electrical units for performing other functions.

According to the software implementation, embodiments such as procedures and functions described herein may be implemented as separate software modules. Each of the software modules may perform one or more functions and operations described herein. Software code can be implemented in a software application written in an appropriate programming language.

On the other hand, the present invention, in one embodiment, the above-described database file recovery apparatus may be implemented as a computer program including a series of instructions to perform a method or apparatus. That is, the present invention may be a computer program running in a predetermined operating system, for example, a mobile operating system, and the program may process the process according to the series of instructions so that the method according to the present invention is implemented.

In addition, in another embodiment of the present invention, the computer program is stored, a floppy disk, CD, DVD, hard disk memory, various types of memory, such as a computer or similar electronic device can be a recording medium that can be read In addition, a computer or similar electronic device, such as a smart phone, etc., which read the computer program in the recording medium may perform the method according to the present invention according to the series of instructions on the computer program.

Although the preferred embodiments of the present invention have been described through the above, the present invention is not limited thereto, and it is possible to carry out various modifications within the scope of the claims and detailed description of the invention and the accompanying drawings. Naturally, it is within the scope of the invention.

10: input
20: control unit

Claims (5)

Receiving an input data file of the database through the input unit 10;
Predicting the size of a block from a database block address (DBA) of the data file by the control unit 20; And
And predicting, by the control unit 20, a file identification number from a database block address (DBA).
The step of predicting the size of the block
Obtaining first data of a set size from an offset point set at the front of the data file;
Obtaining second data of a size set at the end of the first data; And
Calculating the size of the block by dividing the maximum block size configurable in the database by the second data;
Database file recovery method through disk block pattern analysis, including. delete According to claim 1,
The step of predicting the file identification number
Obtaining third data of a set size from a DBA offset point of the second block of the data file; And
Predicting fourth data of a size set in front of the third data by the file identification number;
Database file recovery method through disk block pattern analysis, including. According to claim 1,
The data file is
A plurality of blocks are continuously configured, the size of the data file is smaller than the size of a unit block, the size of the block consists of a power of 2, and the first block of the data file is metadata, and the block The database block address is located at a location set from the starting point of the, and the number of the block is sequentially increased from 0 to 1, thereby recovering a database file through disk block pattern analysis. According to claim 1,
The database block address
A method of restoring a database file through disk block pattern analysis, which is an identifier of a block position where all blocks except the first block of the data file have the same offset position.

Images