KR101583283B1 - Apparatus and method for recovering data in DB2 database - Google Patents

Abstract

The present invention relates to a method and an apparatus for restoring data in a DB2 database, in which a data restoration apparatus receives a system file and a data file from a database, retrieves an extent map in which a data area address is recorded in the data file, Retrieving a deleted data record from the data area, retrieving information about one or more tables from the system file, retrieving information from one or more tables using the column size and data type of the deleted record, By sequentially comparing the column sizes and the data types included in the information on the tables, the table information of the deleted records is derived.

Description

[0001] Apparatus and method for recovering data from a DB2 database [0002]

The present invention relates to a method for restoring data in a DB2 database, and more particularly to a method for recovering deleted records remaining in an unassigned area of a database file in a non-dependent manner in a transaction log file.

A database, a structured information storage medium, is widely used in all fields that need to store computerized data. In particular, companies use databases to efficiently manage the work results of their organizations. Therefore, databases are an important collection subject for digital forensic investigation for corporations.

It is also important to collect normal data when collecting evidence against the database, but there is a possibility that the user deliberately deletes sensitive data, so research on the technique of recovering deleted data is needed.

IBM's DB2 database is one of the RDBMS products, a relational database published in 1983. According to Gartner's RDBMS global market research report released in 2012, it has a share of 20.2% after Oracle, which is the DBMS market leader. Recovering deleted records from DB2 databases, which are widely distributed globally, makes a lot of sense in terms of digital forensics.

A technique for recovering deleted records from an existing DB2 database is a technique for reconstructing the database by analyzing the transaction log and tracking the operation of the database. The database processes a series of operations on a transaction-by-transaction basis, so that more detailed data can be obtained. Here, the database stores a log of transaction processing because it uses transactions as a basic unit of execution. Research by R. A. Crus to recover deleted records in DB2 through transaction log files has been carried out. However, the proposed method has a limit in that it can not be recovered if the transaction log file does not exist due to the policy of the company and the capacity of the server.

In the prior art cited below, a method of recovering a logical error of a database is introduced, and a technique of recovering data through a transaction log is proposed. However, there are fatal disadvantages that prior art documents can only be recovered through transaction logs.

From this point of view, we can see that there is a need for technical means to recover records deleted from the database in a non-dependent manner in the transaction log.

Japanese Patent Application Laid-Open No. 10-2010-0134355 (December 23, 2010)

Therefore, a first problem to be solved by the present invention is to provide a method for recovering data unrelated to a transaction log by extracting deleted records from the data area by analyzing the file itself of the database.

A second problem to be solved by the present invention is to provide an apparatus for recovering data deleted from a data area by analyzing a file itself of a database, thereby restoring data to a transaction log in a non-dependent manner.

In order to solve the first problem, a data restoration apparatus according to an embodiment of the present invention receives a system file and a data file from a database; Retrieving an extent map in which an address of a data area is recorded in the data file and deriving a data area including the deleted record; And recovering a deleted record by extracting a deleted record in the data area, wherein the data recovery device derives information on one or more tables from the system file, And sequentially deriving table information of the deleted record by sequentially comparing the column size and the data type included in the information on the one or more tables using the column size and the data type of the deleted record And provides a restoration method.

The database according to the embodiment may be a DB2 database.

The step of deriving the data area according to an embodiment of the present invention includes: the data restoration device retrieving the extent map using the first header value in the data file; And deriving a data area in which the record offset is changed due to the deletion of the record in the extent map by the data restoration device.

The data file according to an embodiment of the present invention may distinguish the extent map from the extent according to the first header value.

When the record according to the embodiment is deleted, the record offset is changed to 0xFFFF.

The address of the data area according to the embodiment may be derived by summing a record offset included in the extent map and a current offset in which a record offset is located.

Deriving the table information area for each table by searching the table information area using the second header value in the system file according to the embodiment of the present invention; Extracting table information for each of the tables in the table information area; And the data decompression apparatus further comprises the step of storing the extracted table information by the column size, the data type, and the column number included in the table information, respectively.

The table information according to one embodiment includes a database privilege, a schema, a table, a field name, and a field type.

In order to solve the second problem, an input unit receives system files and data files from a database according to an embodiment of the present invention; A processing unit for retrieving an extent map in which an address of a data area is recorded in the data file and deriving a data area including the deleted record; And an extracting unit for extracting a deleted record from the data area, wherein the processing unit derives information on one or more tables from the system file, And sequentially derives the table information of the deleted record by sequentially comparing the column size and the data type included in the information on the one or more tables using the type information.

The database according to an embodiment of the present invention may be a DB2 database.

The processing unit searches the extent map using the first header value in the data file and derives a data area in which a record offset is changed due to deletion of a record in the extent map, And the record offset is changed to 0xFFFF when the record is deleted. The method of claim 1, wherein the record offset is changed to 0xFFFF when the record is deleted.

The address of the data area according to an embodiment of the present invention may be derived by summing up the start flag address and the record offset included in the extent map.

The table information area is searched using the second header value in the system file according to the embodiment described above and the table information area is derived for each searched table, Extracts the extracted table information by the column size, the data type, and the column number included in the table information, and stores the extracted table information, wherein the table information includes a database privilege, a schema, a table, a field name, And a data restoration device.

According to the present invention, it is possible to recover a record even if a transaction log due to a company policy or a database setting does not exist by analyzing a data file and recovering a deleted record by accessing a data area in which a deleted record exists have.

FIG. 1 is a flowchart illustrating a data restoration method employed by embodiments of the present invention.
2A is a diagram showing a folder structure and a creation file of a DB2 database according to an embodiment of the present invention.
FIG. 2B illustrates tablespace path information stored in an SQLSPCS file according to an exemplary embodiment of the present invention. Referring to FIG.
FIG. 3A is a diagram illustrating a page and an extent size using an instruction according to an exemplary embodiment of the present invention.
FIG. 3B is a diagram illustrating a DB2 table space structure according to an embodiment of the present invention.
4A is a diagram illustrating an extent map structure according to an embodiment of the present invention.
4B is a diagram illustrating a data area of an LRG tablespace according to an embodiment of the present invention.
FIG. 4C illustrates column sizes and data types stored in a data area of an LRG tablespace according to an exemplary embodiment of the present invention. Referring to FIG.
5A is a diagram illustrating a change of an extent map when a record is deleted according to an embodiment of the present invention.
FIG. 5B is a diagram illustrating a change of a data area when a record is deleted according to an embodiment of the present invention.
6A is a diagram illustrating column information stored in a system catalog file according to an embodiment of the present invention.
6B is a diagram illustrating table information stored in a system catalog file according to an embodiment of the present invention.
7 is a flowchart illustrating a method of recovering a record using a data file according to an embodiment of the present invention.
8 is a flowchart illustrating a method of recovering a record using a system file according to an embodiment of the present invention.
9 is a flowchart illustrating an RRFDB2 program algorithm according to an embodiment of the present invention.
FIG. 10 is a block diagram illustrating a data recovery apparatus adopted by an embodiment of the present invention.
11 is a diagram illustrating a result of a deleted record recovery experiment according to an embodiment of the present invention.

Prior to describing the embodiments of the present invention, technical solutions adopted by embodiments of the present invention will be outlined to solve the problems occurring in the existing data restoration method.

Since the database contains important information, there is a high probability that there will be meaningful information from the viewpoint of digital forensics. It is also important to extract normal records from the database, but it is also important to recover deleted records. Current research on database data restoration is based on transaction logs. However, this method has a fatal disadvantage that it can not be used when there is no transaction log or when it is desired to restore the data of a previous time recorded by the transaction log.

Accordingly, embodiments of the present invention seek to provide a technical means for recovering deleted records of a database in a non-dependent manner in a transaction log.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the following description and the accompanying drawings, detailed description of well-known functions or constructions that may obscure the subject matter of the present invention will be omitted. It should be noted that the same constituent elements are denoted by the same reference numerals as possible throughout the drawings.

FIG. 1 is a flowchart illustrating a data restoration method adopted by one embodiment of the present invention. The data restoration apparatus receives a system file and a data file from a database, extracts an extent map retrieving an extent map to derive a data area including the deleted record, and retrieving the deleted record from the data area, thereby recovering the deleted record, And sequentially comparing the column sizes and the data types included in the information on the one or more tables by using the column size and the data type of the deleted record, . More specifically, in step S110, the data restoration device receives the system file and the data file from the database.

To recover the deleted records, you need to understand the structure of the DB2 database-related files and the table space structure that stores the records. In the present invention, since the recovery technique is completed by analyzing the change of the database file when the record is deleted, the structure of the database-related files for searching the table space will be described first.

The DB2 database can be created with the folder structure and files as shown in FIG. 2 on the storage set at the time of installation.

2A is a diagram showing a folder structure and a creation file of a DB2 database according to an embodiment of the present invention. Table 1 below is a description of FIG. 2A.

More specifically, an instance refers to a logical database management unit. You can separate the database into logical units by specifying a separate database configuration for each instance. In the instance folder 21, a node folder 22 exists. The node folder 22 indicates the partition number where the database is stored, and each database partition is managed by the partition number. The partition number can not be arbitrarily changed, and if it is changed arbitrarily, the database map information may be damaged. The actual database-related files are created under each partition folder. Here, three types of folders are created as follows.

First, a folder 23 of a local database name is created, and there is a storage where a real data is stored, that is, a database file. In IBM DB2, it can be called a table space.

Secondly, a folder 24 for storing the environment setting related files of the node is generated. At this time, each file has a separate copy in preparation for database corruption. Among the configuration files, the SQLSPCS file stores the path of the tablespace so that it can be used as useful information. Subordinate DB2EVENT folder stores event related logs, and SQLOGDIR (25) can store query related logs. Table 2 below is a description of the environment setting related file 26 of the DB2 database.

Finally, the file 25 storing the database directory information is created, and the SQLSPCS file in which the table space path is stored can be accessed through the information of the SQLDBDIR (25) file. That is, as shown in FIG. 2B, the table space path information 28 stored in the SQLSPCS file can be known.

On the other hand, the table space may be a database file in which tables, indexes, and data are stored. There are five kinds of table spaces, which can be distinguished as file extensions. A CAT that stores system catalog information, an LRG that stores records, a TMP that temporarily stores data to cope with unexpected errors by the system, a UTM that is temporarily stored before the data entered by the user is executed in transaction units, There are 5 extensions of USR which are arbitrarily defined.

The table spaces used in the present invention are CAT and LRG, and the CAT can acquire table column information, and the LRG can store records of a table.

Therefore, the file input in step S110 of FIG. 1 may be a system file CAT and a data file LRG.

Returning now to Figure 1, step S120 will be described.

In step S120, the data recovery apparatus searches the extent map in which the address of the data area is recorded in the data file, and derives a data area including the deleted record. In other words, it is possible to retrieve the extent map using the first header value in the data file, and derive the data area in which the record offset is changed due to the deletion of the record in the extent map. Here, the data file distinguishes the extent map from the extent according to the first header value, and when the record is deleted, the record offset may be changed to 0xFFFF. In addition, the address of the data area may be derived by summing a record offset and a current offset in which the record offset is located in the extent map.

More specifically, the table space can manage data using a storage unit called an extent. The extent is composed of a plurality of pages, and the extent and page size can be confirmed through a 'LIST TABLESPACES SHOW DETAIL' command.

FIG. 3A is a view showing a page and an extent size using a command according to an embodiment of the present invention, and is a result screen using the 'LIST TABLESPACES SHOW DETAIL' command. Here, it can be seen that one page unit 31 is 4096 bytes, and the extent 32 is composed of four pages.

FIG. 3B illustrates a structure of a DB2 table space according to an embodiment of the present invention. The overall structure of the table space 33 is as follows. The table space header 34 has a file path related to the configuration of the database and an offset of the first extent. In addition, in the extent map area 35, the data 38 allocated to the data area 36 can be stored. In addition, in the data area, not only data but also column size and data type 39 of data can be stored. Here, the extent map area 35 will be described in more detail with reference to FIG. 4A.

4A is a diagram illustrating an extent map structure according to an embodiment of the present invention.

More specifically, the extent map area has a value 0x0FD00030 (Extent Map Header) 40, which is a first header value indicating that the first offset 4 bytes is an extent map area. You can use this value to distinguish extents from extent maps.

Also, in the extent map area, it is confirmed that the offset values for the records allocated to the data area are listed in the 2-byte little endian constant 46 as shown in FIG. 4A. Here, in order to access the allocated data area, when the record offset address value 0xA004C and the offset 0xB15 (46) of the first record are added together, the data area address 0xA0B61 of the allocated record comes out. It can be accessed normally.

FIG. 4B illustrates a data area of the LRG tablespace according to an exemplary embodiment of the present invention. Referring to FIG. 4B, the data area is identified when the data area is accessed using the data area address 0xA0B61. Here, the allocated record may have a large record size (47) and actual data (48).

4C is a diagram illustrating a column size and a data type stored in a data area of an LRG tablespace according to an embodiment of the present invention.

More specifically, the number of columns 49 column data type and size 50 may exist in the data area. The column data type 50 is the upper 2 bytes. The lower 2 bytes represent the column size. Table 3 below describes the column data types in the DB2 database.

In this way, it can be seen that the record offsets are allocated and managed in the order of input (INSERT) through analysis. Also, you can check the field names and types extracted from the system catalog by column size, data type, and column number. This part will be explained in detail in the system file analysis step described below.

Returning now to FIG. 1, step S120 and subsequent steps will be described.

In step S130, the data recovery apparatus retrieves the deleted record from the data area, thereby recovering the deleted record.

More specifically, when a record is deleted from the DB2 database, as described in step S120, the record allocation offset of the extent map is changed to 0xFFFF, so that the record allocation offset changed from the extent map to 0xFFFF is identified and the record can be accessed to the deleted data area have. Here, the change of the extent map when the record is deleted can be confirmed through FIG. 5A.

In addition, since the actually deleted record remains in the unallocated area as shown in FIG. 5B, the deleted record can be extracted and the deleted record can be recovered. In addition, when the table is deleted, the record allocation offset changes to 0xFFFF, and records may remain in the unallocated data area in the same manner as the record deletion.

The data restoration device derives information on one or more tables from the system file, and uses the column size and the data type of the deleted record to retrieve information on each column size included in the information on the one or more tables The table information of the deleted record can be derived by sequentially comparing the data type and the data type. That is, the data decompression apparatus retrieves the table information area using the second header value in the system file, derives the table information area for each table, and extracts the table information for each table in the table information area , And the extracted table information may be stored separately by the column size, the data type, and the number of columns included in the table information. Here, the table information may include a database authority, a schema, a table, a field name, and a field type. Here, the table information stored in the system file will be described in detail with reference to FIGS. 6A and 6B.

6A and 6B are diagrams showing column and table information stored in a system catalog file according to an embodiment of the present invention.

More specifically, in order to improve the accuracy of deleted record recovery, field names and type information of a table stored in a schema table are required. Therefore, since the system catalog, which is a system file, includes various information such as authority, schema, table, field name, and field type of the database, it is important to distinguish each information.

6A is a diagram showing column information stored in a system catalog file according to an embodiment of the present invention. The column ID 61, the column size 62, the column data type 63, the column name size 65, There is a column name 64. The column ID (61) indicates the order when there are a plurality of columns belonging to the table and starts from zero. Column data types may be the same as Table 3.

6B is a diagram illustrating table information stored in a system catalog file according to an embodiment of the present invention. Since the table schema information of the contents of the system catalog can have the value 0xFFFF00FFFF00FF of 7 bytes as the header value 66, which is the second header value, the extents are sequentially scanned through the header value 66, (67), a column name (68), a schema (69), and a data type (70).

Accordingly, the information on the obtained table can be used to confirm specific information about the records in the data area by comparing the column name, the data type, and the number of columns identified in the data area of the table space.

The data restoration method of FIG. 1 may be expressed as another flowchart as shown in FIGS. 7 and 8. FIG.

FIG. 7 is a flowchart illustrating a method of recovering a record using a data file according to an embodiment of the present invention, and includes a configuration corresponding to each step of FIG. 1 described above. Therefore, the function of each process is outlined here to avoid duplication of explanation.

More specifically, in step S710, data is input. In other words, the data restoration method proposed by the present invention can use an LRG file storing data rather than a transaction log file.

In step S720, the first header value is retrieved.

More specifically, the extent map header value 0x0FD00030 is scanned in bytes.

In step S721, the record offset portion is confirmed.

In step S722, it is determined whether there is a deleted record offset.

In step S730, the column information offset of the extent map is confirmed.

More specifically, it is possible to extract the number of columns, the column size, and the data type stored in the data area through the column offset of the extent map.

In step S731, the column size and the data type are confirmed by accessing the column information of the data area.

In step S732, record information of the data area is extracted using the column information.

In step S740, the normal record of the extracted records is excluded.

More specifically, the normal record may be storing a normal address value rather than a value of 0xFFFF.

In step S741, the deleted record is extracted.

In step S742, the deleted record is stored.

FIG. 8 is a flowchart illustrating a method of recovering a record using a system file according to an embodiment of the present invention, and includes a configuration corresponding to each of the processes of FIGS. 1 and 7 described above. Therefore, the function of each process is outlined here to avoid duplication of explanation.

More specifically, in step S810, data is input. The LRG file storing the data can be used. Here, a CAT file, which is a system table file storing table schema information, can be input and used to acquire additional data related to data, which is additional metadata.

In step S820, it is determined whether a CAT file that is a system file is input in step S810. If the CAT file is input, the process proceeds to step S830. If the CAT file is not input, the process proceeds to step S840.

In step S830, the USERSPACE1 area is searched.

More specifically, since the CAT file stores a large amount of information such as all tables, column names, and table privileges related to the database, the amount of data is enormous. A process of searching USERSPACE1 is needed to search the area where the column information is stored.

In step S831, the column information is extracted.

More specifically, the column information includes a column name, a column size, a column data type, and a column order ID.

In step S832, the signature is searched.

More specifically, it is necessary to search for a signature in order to search an area storing table information in the CAT file. The signature, i.e., the header value, which can identify the area where the table information is stored, has a value of 0xFFF00FFFF00FF, and identifies the table name by using the column name extracted from the above.

In step S833, the column information and the schema information are joined.

The column information extracted from the above is joined with the schema information to obtain the column information for each table. The table name can be identified using the column information data type and the column name.

In step S834, table information is stored.

More specifically, table-related information extracted from the table is stored.

In step S840, if an LRG file that is a data file is input in step S810

Proceed to step S840. If the LRG file is not input, the process ends.

In step S850, the extent map header value is scanned.

In step S851, the process corresponding to FIG. 7 is performed.

In step S852, the table name is identified by joining the table information and the record.

FIG. 9 is a flowchart illustrating an RRFDB2 program algorithm according to an embodiment of the present invention. When a storage path storing a database is entered as an argument value, the SQLSPCS file in the SQLDBDIR folder is accessed. In the SQLSPCS file, , CAT and LRG files are accessed. After CAT and LRG files are checked, CAT Method () and LRG Method () are executed. Here, CAT Method () is a flowchart of FIG. 7, and LRG Method () may be a flowchart of FIG.

More specifically, it searches the folders and files of the inputted DB2 path, and obtains the SQLSPCS file path by accessing the searched SQLDBDIR file. Then access the SQLSPCS file. The SQLSPCS file stores a system catalog table space and path information for an LRG table space for storing records. Through this, the system catalog table space is accessed to acquire column information for each table, and an unallocated area is identified through an extent map of the LRG table space. If there is an unallocated area, the data area is searched to extract the deleted record. At this time, the table field type obtained in the system catalog table space and the record size specified in the data area of the LRG table space can be calculated and extracted.

FIG. 10 is a block diagram showing a data restoration apparatus adopted by one embodiment of the present invention. The data restoration apparatus 90 includes a configuration corresponding to each process of FIG. 1 described above. Therefore, in order to avoid duplication of explanation, the function is outlined mainly in the detailed configuration of the system.

The input unit 91 receives the system file and the data file from the database.

The processing unit 92 searches the extent map in which the address of the data area is recorded in the data file, and derives a data area including the deleted record.

The extracting unit 93 retrieves the deleted record in the data area, thereby recovering the deleted record.

In addition, the processing unit 92 may derive information on one or more tables from the system file, and may use the column size and the data type of the deleted record to determine the column size of each column included in the information on the one or more tables And sequentially derives the table information of the deleted record.

The processing unit 92 retrieves the extent map using the first header value in the data file and derives a data area in which the record offset is changed due to the deletion of the record in the extent map, The extent of the extent map is distinguished from the extent according to the header value. When the record is deleted, the record offset may be changed to 0xFFFF.

The address of the data area may be derived by summing the start flag address included in the extent map and the record offset.

In addition, the table information area may be searched using the second header value in the system file, the table information area may be derived for each of the searched tables, and table information may be extracted for each table in the table information area, And stores the table information separately for each column size, data type, and column number included in the table information. The table information may include database privileges, schemas, tables, field names, and field types.

FIG. 11 is a diagram illustrating a result of a deleted record recovery experiment according to an embodiment of the present invention. The deleted record recovery tool of the IBM DB2 database is implemented. In this case, the implementation environment is implemented by console based on C language, and it is a program to retrieve deleted records by taking the storage path in which the database is installed as an argument value and using the relation of the corresponding database file. Here, although the storage path is used as an argument value, it is also possible to directly retrieve the data file and the system file to recover the deleted record. As shown in FIG. 10, a successfully deleted record can be recovered using a tool implemented in the data restoration method of the present invention, and it can be verified that the method proposed in the present invention is a normal method.

According to the present invention, data can be recovered even when there is no transaction log when a transaction log is deleted due to a company policy or a database setting. Furthermore, if the suspect deliberately deletes the data from the viewpoint of digital forensics, the data can be recovered and the evidence and deletion behavior can be verified.

Meanwhile, the embodiments of the present invention can be embodied as computer readable codes on a computer readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored.

Examples of the computer-readable recording medium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device and the like, and also a carrier wave (for example, transmission via the Internet) . In addition, the computer-readable recording medium may be distributed over network-connected computer systems so that computer readable codes can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the present invention can be easily deduced by programmers skilled in the art to which the present invention belongs.

The present invention has been described above with reference to various embodiments. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

90: Data recovery device
91:
92:
93:

Claims (13)

Receiving a system file and a data file from a DB2 database;
Retrieving an extent map in which an address of a data area is recorded in the data file to derive a data area in which a record offset is changed; And
And recovering the deleted record by extracting the deleted record from the data area,
The data recovery apparatus derives information on one or more tables from the system file, and uses each of the column sizes and data types included in the information on the one or more tables using the column size and the data type of the deleted record, And deriving table information of the deleted record by sequentially comparing the types of the deleted records. delete The method according to claim 1,
Wherein deriving the data region comprises:
Retrieving the extent map using the first header value in the data file; And
The data restoration device deriving a data area including the record offset changed due to deletion of a record in the extent map. The method of claim 3,
Wherein the data file distinguishes the extent map from the extent according to the first header value. The method of claim 3,
And when the record is deleted, the record offset is changed to 0xFFFF. The method according to claim 1,
Wherein the address of the data area is derived by summing a start flag address included in the extent map and a record offset. The method according to claim 1,
Deriving the table information area for each table by searching the table information area using the second header value in the system file;
Extracting table information for each of the tables in the table information area; And
Wherein the data restoring device stores the extracted table information according to a column size, a data type, and a column number included in the table information, respectively. 8. The method of claim 7,
Wherein the table information includes a database authority, a schema, a table, a field name, and a field type. An input unit for receiving system files and data files from a DB2 database;
A processing unit for retrieving an extent map in which an address of a data area is recorded in the data file to derive a data area in which a record offset is changed; And
And an extracting unit for extracting the deleted record in the data area, thereby recovering the deleted record,
The processing unit derives information on one or more tables from the system file, and uses the column size and the data type of the deleted record to determine the column size and the data type included in the information on the one or more tables And derives the table information of the deleted record by sequentially comparing the table information. delete 10. The method of claim 9,
Wherein,
Retrieving the extent map using a first header value in the data file and deriving a data area including the record offset changed due to record deletion in the extent map,
Wherein the data file distinguishes the extent map from the extent according to the first header value, and when the record is deleted, the record offset is changed to 0xFFFF. 10. The method of claim 9,
Wherein the address of the data area is derived by summing a start flag address included in the extent map and a record offset. 10. The method of claim 9,
Retrieving the table information area using the second header value in the system file, deriving the table information area for each of the retrieved tables, extracting table information in the table information area for each of the tables, Information is classified by the column size, the data type, and the number of columns included in the table information,
Wherein the table information includes a database authority, a schema, a table, a field name, and a field type.

Images