KR20200056357A - Technique for implementing change data capture in database management system - Google Patents

Abstract

Disclosed is a computer program stored in a computer-readable storage medium including encoded instructions. An objective of the present invention is to efficiently implement change data capture (CDC) without stopping a database. The computer program allows one or more processors of a source database server to perform steps for change data capture (CDC) if executed by the one or more processors. The steps include: a step of analyzing a log record including information for a transaction processed by the source database server to identify a plurality of structured query language (SQL) operations created for one or more objects associated with the transaction; a step of determining whether a previous SQL operation history for an object corresponding to an individual SQL operation exits in a CDC file based on an order in which the identified plurality of SQL operations are created; a step of determining information to be recorded in the CDC file based on whether the previous SQL operation history exists in the CDC file; a step of recording the determined information in the CDC file; and a step of determining to transmit the CDC file to a target database server.

Description

A technique for implementing change data capture in a database management system {TECHNIQUE FOR IMPLEMENTING CHANGE DATA CAPTURE IN DATABASE MANAGEMENT SYSTEM}

The present invention relates to a database management system (DBMS), and more particularly, to a change data capture (CDC).

Corporate business is rapidly expanding with the explosion of data and the emergence of various environments and platforms. With the advent of the new business environment, more efficient and flexible data services, information processing, and data management functions are needed. In response to these changes, research into databases to solve the problems of high performance, high availability, and scalability, which are the foundations of corporate business implementation, is continuing.

Data managed within an enterprise often needs to be migrated or copied from a source location to a target location and managed. For example, a database system for implementing a banking business may be classified into a database that can be accessed simultaneously by multiple external customers and a database that can be accessed by internal employees, depending on the characteristics of the client accessing. A solution for transferring change data from a source database system to a target database system is called change data capture (CDC). The CDC can be implemented, for example, by reading and interpreting log files in the source database system and replaying the change data in the source database system to the target database system to be replicated.

If you're doing data backup or data consolidation tasks, you have to deal with massive amounts of data. By selecting only recently changed data from the original source database system and moving it to another target database system, the load on the system can be reduced and the productivity of the overall operation can be improved. In particular, in the case of data integration or data warehouse work that regularly extracts a large amount of data from one system and moves it to another system, using CDC technology can significantly reduce the time required to extract and move data. have. In addition, in the case of a business system requiring 24 hours operation, if CDC technology is used, real-time backup and data integration may be possible without downtime.

Further, in implementing query offloading for improving the performance of the database, for example, only write / update is allowed in the master database, and at least part of the data in the master database is used in the staging database. Duplicate and copy and transfer the copied data to N slave databases. When using such query offloading, the write logic for the database is performed in the master database and the read logic can be performed in the slave database, so that separation according to the type of transaction can be possible. Accordingly, the performance of the database may be improved, such as an increase in the throughput of the database.

For the above reasons, major database companies are currently developing products for CDC solutions.

Methods for implementing the CDC include, for example, a row timestamp method, a row version method, a lock method, a row state indicator method, and a table trigger ) And event programming.

In particular, in a CDC solution, synchronization must be performed between both databases in order to maintain data integrity among a plurality of database systems. However, in order to implement such synchronization, it may incur overhead for database resources.

U.S. registered patent US6,999,977 U.S. registered patent US7,111,023 U.S. registered patent US7,657,576 U.S. registered patent US7,647,354 U.S. registered patent US9,727,624 US registered patent US9,442,995 US registered patent US8,510,270 US registered patent US9,298,878 U.S. registered patent US7,461,103 U.S. registered patent US7,065,538 U.S. registered patent US7,668,878 US registered patent US6,832,229 U.S. registered patent US8,799,213 US registered patent US9,230,002 U.S. registered patent US9,009,104 US registered patent US6,981,004 U.S. registered patent US6,976,022 U.S. registered patent US7,908,243 US registered patent US9,841,909 U.S. registered patent US9,495,252 US registered patent US8,676,759 US registered patent US9,646,042 U.S. registered patent US9,047,392 U.S. registered patent US7,831,574 U.S. registered patent US8,874,506 U.S. registered patent US8,385,657 United States Published Patent US2016-0314147 United States Published Patent US2018-0081924

Embodiments of the present disclosure are for efficiently implementing change data capture (CDC) without stopping the DB.

Embodiments of the present disclosure are for efficiently managing memory in a target DB.

Disclosed is a computer program stored in a computer readable storage medium including instructions encoded according to one embodiment of the present disclosure. The computer program, when executed by one or more processors of a source database server, causes the one or more processors to perform a method for change data capture (CDC). The method includes: identifying a plurality of structured query language (SQL) operations generated for one or more objects associated with the transaction by analyzing a log record including information about the transaction being processed at the source database server; Determining whether a previous SQL operation history for an object corresponding to an individual SQL operation exists in a CDC file based on the order in which the identified multiple SQL operations have occurred; Determining information to be written to the CDC file based on the existence of a previous SQL operation history in the CDC file; Recording the determined information in the CDC file; And determining to transmit the CDC file to the target database server.

A database server is disclosed that includes one or more processors for implementing Change Data Capture (CDC) in accordance with one embodiment of the present disclosure. The database server may include a source database server, or any type of agent server existing between a source database server and a target database server. The one or more processors: identify a plurality of Structured Query Language (SQL) operations generated for one or more objects associated with the transaction by analyzing log records containing information about the transaction being processed at the source database server action; Determining whether a previous SQL operation history for an object corresponding to an individual SQL operation exists in a CDC file based on the order in which the identified multiple SQL operations have occurred; Determining information to be recorded in the CDC file based on the existence of a previous SQL operation history in the CDC file; Recording the determined information in the CDC file; And determining to transmit the CDC file to the target database server.

In accordance with one embodiment of the present disclosure, a computer program stored in a computer readable storage medium including encoded instructions is disclosed. The computer program, when executed by one or more processors, causes one or more processors to perform a method for change data capture (CDC). The method comprises: receiving a CDC file from a source database server; Determining whether meta information corresponding to the target database server exists by reading meta information recorded in the CDC file; If the corresponding meta information does not exist, loading the meta information recorded in the CDC file into a memory; Reading an SQL operation recorded in a CDC file, and generating the SQL statement corresponding to the SQL operation by using the meta information on the memory corresponding to the read SQL operation; And applying the generated SQL statement to the target database server.

In accordance with one embodiment of the present disclosure, a database server is disclosed that includes one or more processors for implementing Change Data Capture (CDC). The database server may include a target database server, or any type of agent server existing between a source database server and a target database server. The one or more processors include: receiving a CDC file from a source database server; Determining whether meta information corresponding to the target database server exists by reading meta information recorded in the CDC file; If there is no corresponding meta information, loading the meta information recorded in the CDC file into a memory; Reading an SQL operation recorded in a CDC file, and generating the SQL statement corresponding to the SQL operation by using the meta information on the memory corresponding to the read SQL operation; And applying the generated SQL statement to the target database server.

According to an embodiment of the present disclosure, change data capture (CDC) can be efficiently implemented without stopping the DB.

According to an embodiment of the present disclosure, memory may be efficiently managed in a target DB.

Various embodiments will be described with reference to the drawings, in which like reference numbers are used collectively to refer to similar components or similar modules. In the following embodiments, for purposes of explanation, a number of specific details are presented for a comprehensive understanding of one or more embodiments. However, such embodiment (s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more embodiments.
1 exemplarily illustrates a database system according to an embodiment of the present disclosure.
2 exemplarily illustrates a source database server and a target database server in a database system according to an embodiment of the present disclosure.
3 is a flowchart exemplarily showing a CDC method performed in a source database server (or agent server) according to an embodiment of the present disclosure.
4 is a flowchart exemplarily illustrating a CDC method performed in a source database server (or agent server) according to an embodiment of the present disclosure.
5 is a flowchart exemplarily showing a CDC method performed in a target database server (or agent server) according to an embodiment of the present disclosure.
6 schematically illustrates CDC operations performed in a database system according to one embodiment of the present disclosure.
7 schematically illustrates CDC operations performed in a database system according to an embodiment of the present disclosure.
8 shows a block diagram of an exemplary computing device for implementing a CDC solution in accordance with one embodiment of the present disclosure.

Various embodiments and / or aspects are now disclosed with reference to the drawings. In the following description, for purposes of explanation, a number of specific details are disclosed to assist in the overall understanding of one or more aspects. However, it will also be appreciated by those skilled in the art that this aspect (s) can be practiced without these specific details. The following description and the annexed drawings set forth in detail certain illustrative aspects of the one or more aspects. However, these aspects are exemplary and some of the various methods in the principles of the various aspects may be used, and the descriptions described are intended to include all such aspects and their equivalents.

In addition, various aspects and features will be presented by a system that may include multiple devices, components and / or modules, and the like. The various systems may also include additional devices, components and / or modules, and / or may not include all of the devices, components, modules, etc. discussed in connection with the drawings. It must be understood and recognized.

As used herein, "an embodiment", "yes", "a good", "an example", etc. may not be construed as any aspect or design described being better or more advantageous than the other aspect or designs. . The terms 'component', 'module', 'system', and 'interface' used in the following generally mean a computer-related entity, for example, a combination of hardware, hardware and software, And software.

In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise or unclear in context, "X uses A or B" is intended to mean one of the natural inclusive substitutions. That is, X uses A; X uses B; Or, if X uses both A and B, "X uses A or B" can be applied in either of these cases. It should also be understood that the term “and / or” as used herein refers to and includes all possible combinations of one or more of the listed related items.

Also, the terms “comprises” and / or “comprising” mean that the feature and / or component is present, but excludes the presence or addition of one or more other features, elements, and / or groups thereof. It should be understood as not. In addition, unless otherwise specified or contextually unclear as indicating a singular form, the singular in the specification and claims should generally be construed to mean "one or more."

Computer-readable media as used herein may include any kind of storage media in which programs and data are stored so that they can be read by a computer system. According to an aspect of the present invention, such a medium includes ROM (read only memory), RAM (random access memory), CD (compact disk) -ROM, DVD (digital video disk) -ROM, magnetic tape, floppy disk, optical data It may include a storage device. Additionally, such media may be distributed over networked systems to store computer readable codes and / or instructions in a distributed fashion.

It should be noted that, prior to explaining the specific contents for carrying out the present invention, a configuration not directly related to the technical subject matter of the present invention has been omitted without detracting from the technical subject matter of the present invention. In addition, the terms or words used in the specification and claims are based on the principle that the inventor can define the concept of appropriate terms in order to explain his or her invention in the best way. It should be interpreted as a concept.

1 shows a schematic diagram of a database system 100 according to an embodiment of the present invention.

As shown in FIG. 1, the database system 100 may include a source database server 110, a target database server 120 and / or an agent server 130.

Although not shown in FIG. 1, the database system 100 may further include a client. A client can refer to any type of node (s) in a system having a mechanism for communicating with database servers. For example, such clients may include PCs, laptop computers, workstations, terminals, and / or any electronic device with network connectivity. In addition, the client may include any server implemented by at least one of an agent, an application programming interface (API), and a plug-in.

In an embodiment of the present invention, operations to be described below of the source database server 110, the target database server 120 and / or the agent server 130 may be performed according to a query issued from a client.

The database servers 110 and 120 may include any type of computer system or computer device, such as, for example, a microprocessor, mainframe computer, digital single processor, portable device and device controller, and the like. Each of these database servers 110 and 120, although not shown, may include a database management system (DBMS) and / or persistent storage.

The source database server 110 and the target database server 120 in the present specification may refer to any type of nodes in the database system 100. As a further embodiment, the source database server 110 and the target database server 120 may be integrated and managed and / or clustered in one database server. The source database server 110 and the target database server 120 may be integrated into one database server to configure multiple databases linked with each other.

In an embodiment of the present invention, the source database server 110 and the target database server 120 may refer to heterogeneous database servers located remotely from each other. In addition, although FIG. 1 shows two database servers, more database servers may be included in the scope of the present invention.

Although not illustrated in FIG. 1, database servers 110 and 120 may include one or more memories including a buffer cache. In addition, although not shown in FIG. 1, the database servers 110 and 120 may include one or more processors. Thus, the DBMS in the database server can be operated by the processor on the memory.

Here, the memory is a main storage device directly accessed by a processor, such as dynamic random access memory (DRAM) or static random access memory (SRAM), and stored information when the power is turned off. Can mean a volatile storage device that is instantly erased, but is not limited to these. This memory can be operated by a processor. The memory may store data tables containing data values and / or log records according to a transaction. For example, log records may be stored in a separate component responsible for storing a separate transaction log in memory. A transaction in the present specification may generally mean a continuous processing unit for a series of operations such as information exchange or database update. Such a transaction represents a basic unit of work for completing the requested work in a state where the integrity of the database is guaranteed. The log record in the present disclosure means a record for a redo log, and changes to the structure and organization of data in the database (eg, table, column, row, data type, index, etc.) It may contain data records that identify the relevant changes.

In one embodiment of the present disclosure, data values and / or log records of a data table may be written from memory to a permanent storage medium. In a further aspect, the memory includes a buffer cache, where such data and / or log records may be stored in a block of the buffer cache. The data and / or log records can be written to a permanent storage medium by a background process.

The permanent storage medium in the database server is, for example, a magnetic disk, an optical disk and a magneto-optical storage device, as well as a storage device based on flash memory and / or battery-backed memory, Refers to a non-volatile storage medium capable of continuously performing arbitrary data. The permanent storage medium can communicate with the processor and memory of the database servers 110 and 120 through various communication means. In additional embodiments, such permanent storage media may be located outside the database servers 110 and 120 to communicate with the database servers 110 and 120.

DBMS is a program for allowing the database server 110 and 120 to perform operations such as retrieving, inserting, modifying, deleting, and / or managing log records, and the like, as described above, the database servers 110 and 120 ) In memory.

The client and the database servers 110 and 120 or the database servers 110 and 120 may communicate with each other through a network (not shown). The network according to an embodiment of the present invention is a public switched telephone network (PSTN), x Digital Subscriber Line (xDSL), Rate Adaptive DSL (RADSL), Multi Rate DSL (MDSL), Very High Speed DSL (VDSL) ), UADSL (Universal Asymmetric DSL), HDSL (High Bit Rate DSL), and various wired communication systems such as a local area network (LAN).

In addition, the network proposed in this specification is CDMA (Code Division Multi Access), TDMA (Time Division Multi Access), FDMA (Frequency Division Multi Access), OFDMA (Orthogonal Frequency Division Multi Access), SC-FDMA (Single Carrier-FDMA) ) And other systems. As a further embodiment, the network herein may include a database link (dblink), whereby the database servers 110, 120 communicate with each other via this database link to thereby or from other database servers. / You can also import log records. The techniques described herein can be used in the networks mentioned above, as well as other networks.

As shown in FIG. 1, the source database server 110 may be located remotely of the target database server 120. Also, the source database server 110 and the target database server 120 may refer to heterogeneous database servers that are servers of the same type or are not compatible with each other.

Additionally, the source database server 110 may include, but is not limited to, a device including a processor and memory for executing and storing instructions as any type of database. That is, the source database may include software, firmware and hardware, or a combination thereof. The software may include application (s) for creating, deleting and modifying database tables, schemas, indexes and / or data. Source database server 110 may receive transactions from a client or other computing device, and exemplary transactions search, add, modify, and / or retrieve data, tables and / or indexes, etc. from source database server 110 And deleting.

The target database server 120 refers to a database server in which data changes generated in the source database server 110 are replicated or synchronized, and may include at least a part of the characteristics of the source database server 110 described above. For example, the target database server 120 may store a copy of data, data types, tables, indexes and / or log records of the source database server 110.

The log record in the present specification may refer to a data record capable of identifying a structure of data in a database, changes to an organization, and / or changes related to tables, columns, data types, indexes, data, and the like. The log record may mean information for uniquely identifying a transaction or operation and / or information for identifying a data record changed according to the transaction or operation.

In one embodiment of the present invention, the agent server 130 may mean a separate entity for implementing CDC between the source database server 110 and the target database server 120. Thus, the agent server 130 can perform any operations to implement CDC features. For example, the agent server 130 receives and processes data from the source database server 110 in the present disclosure, and then transmits the data to the target database server 120 so that the change data in the target database server 120 is performed. Can be allowed to apply.

The agent server 130 is a server of any type and may include, but is not limited to, a device including a processor and memory for executing and storing instructions. The agent server 130 may include software, firmware and hardware, or a combination thereof. For example, software that implements the operations of the agent server 130 may be installed in the source database 110 and / or target database 120. For example, the agent server 130 may operate as any type of CDC module. In this example, the CDC module is installed on the source database server 120 and / or the target database server 130 to allow CDC features between the source database server 120 and the target database server 130 to be implemented. have.

The functions of the agent server 130 shown in FIG. 1 may be integrated as part of the source database server 110 and / or the target database server 120. For example, the CDC function of the agent server 130 may be replaced by the target database server 120.

2 exemplarily illustrates a source database server 110 and a target database server 120 in a database system 100 according to an embodiment of the present disclosure.

The components of the database servers 110 and 120 shown in FIG. 2 are exemplary, and additional components may exist, or some of the components may be omitted or integrated.

As illustrated in FIG. 2, the source database server 110 may include an extraction module 210, a recording module 220, a reading module 230, a transmitting / receiving module 240 and a storage module 250. The above-described modules may refer to a collection of functions performed by one or more processors of the source database server 110. Further, the operations and functions performed by the above-described modules may be performed by one or more threads or processes.

The extraction module 210 may obtain a log record including information about a transaction processed by the source database server 110. The extraction module 210 may receive a redo log from the source database server 110 or access the redo log to the source database server 110. When changes to data, tables, and / or indexes occur in the source database server 110 according to a transaction initiated by a client, log records for the transaction may be recorded in the source database server 110. In this case, the extraction module 210 may obtain a log record for change data by checking and analyzing a redo log for a transaction recorded in a log buffer and / or log file in the source database server 110. In this case, the extraction module 210 may extract only the changed data by analyzing the redo log. The extraction module 210 may analyze the extracted log records based on one or more rules or based on any type of deep learning algorithm.

Additionally, the extraction module 210 may sort the log records based on the order according to when they occur. For example, the extraction module 210 may sort log records based on a System Change Number (SCN). That is, the recording module 210 may sort log records of the source database server 110 in time series.

The extraction module 210 may identify a plurality of SQL operations generated for one or more objects associated with a transaction. In the present specification, the SQL operation may mean any type of operation written in SQL. The SQL operation may include, for example, DML (Data Manipulation Language) operation, DDL (Data Definition Language) operation, and / or DCL (Data Control Language) operation. Additionally, the extraction module 210 may arrange the identified SQL operations in the order in which they occurred and transfer them to the recording module 220.

The recording module 220 may sort the log records based on the order according to when they occur. For example, the recording module 220 may sort log records based on a System Change Number (SCN). That is, the recording module 220 may sort the log records of the source database server 110 in time series. Therefore, a log record preceded by an SCN can be recorded before a log record having a subsequent SCN. The recording module 220 may determine whether a previous SQL operation history for an object corresponding to an individual SQL operation exists in a CDC file based on the order in which the identified multiple SQL operations have occurred. In the present specification, the CDC file may mean a file arranged in the order of transactions (computation), which is transferred from the source database server 110 to the target database server 120. The recording module 220 may determine information to be recorded in the CDC file based on the existence of a previous SQL operation history in the CDC file, and record the determined information in the CDC file.

For example, the recording module 220 determines whether or not a previous SQL operation history exists in the CDC file based on whether meta information about an object (eg, a table) corresponding to the SQL operation exists in the CDC file. Can be. Here, the meta information may include at least one of table user information, table name information, column name information, column order information, and column type information. Also, the recording module 220 may determine whether the previous SQL operation history exists in the CDC file based on whether a DML operation or a DDL operation has been previously performed on an object corresponding to the SQL operation. The above-described determination of the history of the previous SQL operation of the recording module 220 may be performed in the order in which the SQL operation occurs (eg, according to the temporal prognostic relationship of the SCN) for all objects associated with the transaction.

When the previous SQL operation history in the CDC file does not exist, the recording module 220 generates meta information about the object using DD (Data Dictionary) information for the object, and transfers the CDC file. When an SQL operation history exists, it may be decided not to generate meta information about the corresponding object. In addition, when the meta information for the object is generated, the recording module 220 determines to record the SQL operation and the meta information related to the object in the CDC file, and the meta information for the object is If not generated, it may be determined to record the SQL operation related to the object in the CDC file.

The reading module 230 may transmit the read CDC file or information recorded in the CDC file to the transmitting / receiving module 240 to allow the CDC file to be read and transmitted to the target database server. The reading module 230 may convert the CDC file or information recorded in the CDC file into a format suitable for the target database server 120.

The transmission / reception module 240 may provide a communication function of the database servers 110 and 120 and / or a communication function with a client. For example, when the transmission / reception module 240 is located outside the source database server 110, the extracted log records may be received from the source database server 110. The transmission / reception module 240 may allow communication between the database servers 110 and 120 using any network and / or database link. The transmission / reception module 240 may receive input from a client. For example, the transmission / reception module 240 may receive a request related to data storage, change, and query, and index build, change, and query from the client. Additionally, the transmit / receive module 240 may allow the transfer of information between database servers by invoking a procedure with the database server. In addition, the transmission / reception module 240 may provide a function of transmitting / receiving any data / information transmitted between database servers in relation to database replication.

The transmitting / receiving module 240 may transmit the received CDC file or information recorded in the CDC file to the target database server 120. The transmission / reception module 240 may convert the CDC file or information recorded in the CDC file into a format suitable for the target database server 120 and transmit the converted format to the target database server 120.

The storage module 250 may store any data stored in connection with performing CDC features according to embodiments of the present disclosure, such as storing extracted log records. The storage module 250 may be included in the DBMS and / or permanent storage media. Additionally, the storage module 250 can perform storage related to the update request. The storage module 250 may determine to store data tables, index tables, and the like. The storage module 250 may determine the storage location on the data table and the storage location on the permanent storage medium for data.

As shown in FIG. 2, the target database server 120 may include a transmit / receive module 310, a write module 320, a read module 330, a change and reflect module 340, and a storage module 350 have.

The transmission / reception module 310 may receive a CDC file or information stored in the CDC file from the source database server 110 or the agent server 130. The transmission / reception module 310 may provide a communication function of the same type as the transmission / reception module 240 of the source database server 110 described above.

The recording module 320 may record CDC file or CDC file information received from the source database server 110 in the CDC file of the target database server 120. For example, the recording module 320 determines to use the same file as the CDC file received from the source database server 110 as its own CDC file, or writes the same information as the CDC file information to the CDC file. Can be. In a further embodiment, when the CDC file received from the source database server 110 is employed as it is, the recording module 320 in the target database server 120 may be replaced with the transmission / reception module 310.

The reading module 330 may read a CDC file existing in the target database server 120. The reading module 330 may transfer the read CDC file to the change and reflection module 340. The reading module 330 may modify the CDC file to match the format of the target database server 120 and transfer it to the change and reflection module 340. The reading module 330 can read the CDC files in the order recorded by the source database server 110.

Additionally, the reading module 330 may determine data to be changed and reflected in the target database server 120 based on the read CDC file. In this case, the reading module 330 may perform an operation of comparing data reflected in the target database server 120 and data included in the read CDC file. Accordingly, the reading module 330 may control the change and reflection module 340 to reflect only the minimum data to the target database server 120.

Additionally, the reading module 330 may determine whether there is meta information corresponding to the target database server 120 by reading the meta information recorded in the CDC file.

The change and reflection module 340 may check whether meta information about the object is recorded in the CDC file. The change and reflection module 340 may determine whether there is meta information corresponding to the target database server 120 by reading meta information recorded in the CDC file. The change and reflection module 340 may load the meta information in the memory when the meta information does not exist and use the existing meta information when the meta information exists. That is, the change and reflection module 340 determines whether to load the meta information based on whether the corresponding meta information is loaded in the memory of the target database server 120, and when the corresponding meta information exists, It is possible to determine to use the corresponding meta information loaded in the target database server 120 without loading the meta information recorded in the CDC file into memory.

The change and reflection module 340 reads the SQL operation recorded in the CDC file, and generates meta-statement corresponding to the SQL operation by using meta information on the memory corresponding to the read SQL operation. Can be. Also, the change and reflection module 340 applies the generated SQL statement to the target database server 120 so that the change data in the source database server 110 can be finally reflected in the target database server 120. Allow.

For example, the change and reflection module 340 first recognizes metadata in the received CDC file, loads the metadata into memory, and then uses the loaded metadata after recognizing the SQL operation in the CDC file. By doing so, you can create an SQL statement for the corresponding SQL operation. After reflecting the generated SQL statement to the target database server 120, the change and reflect module 340 may recognize the commit for the transaction in the corresponding CDC file and reflect the commit to the target database server 120.

3 is a flowchart exemplarily showing a CDC method performed in a source database server (or agent server) according to an embodiment of the present disclosure.

The steps shown in FIG. 3 are exemplary, and additional steps may be present or some of the steps may be omitted. The steps illustrated in FIG. 3 may be performed on the source database server 110 or the agent server 130. For convenience of description, it will be described below on the assumption that it is performed in the source database server 110.

The source database server 110 may identify SQL operations generated for one or more objects associated with the transaction by analyzing a log record including information about the transaction processed by the source database server 110 ( 410). When changes to data, tables, and / or indexes occur in the source database server 110 according to a transaction initiated by a client, log records for the transaction may be recorded in the source database server 110. In this case, the source database server 110 may extract change data by analyzing log records recorded in the log buffer and / or log files in the source database server 110. For example, when DML occurs in the source table, the source database server 110 may extract new changed data after the most recently acquired / extracted changed data as change data. As another example, when the DDL for the source table is generated, the source database server 110 may recognize the DDL for the table as change data and extract it as change data to be reflected in the target database server 120. . Additionally, the source database server 110 may sort change data in time series based on the SCN value of the change data.

The source database server 110 may determine whether a previous SQL operation history for an object corresponding to an individual SQL operation exists in a CDC file based on the order in which the identified multiple SQL operations have occurred (420). Then, the source database server 110 may determine information to be recorded in the CDC file based on the existence of a previous SQL operation history in the CDC file (430). For example, when the source database server 110 extracts change data representing operations on the first DB object, the source database server 110 has previously performed a DML or DDL operation on the first DB object. Can determine whether In this example, the source database server 110, if DML or DDL operation has not been previously performed on the first DB object, meta information about the first DB object from memory (eg, Data Dictionary (DD) information) Can receive The source database server 110 may generate meta information about the first DB object by using DD information for the first DB object. If the DML or DDL operation was previously performed on the first DB object, the source database server 110 will not generate additional meta information because there will be meta information about the first DB object. In the present disclosure, for example, meta information may include at least one of table user information, table name information, column name information, column order information, and column type information. In one embodiment, the source database server 110, in the order in which SQL operations are performed for all objects associated with a specific transaction, the history of previous SQL operations for each object that is a target of the corresponding SQL operation exists in the CDC file Can determine whether or not.

The source database server 110 may record the determined information in a CDC file (440). In step 430, it may be determined whether meta information generated by generating meta information is recorded in a CDC file. In step 440, the source database server 110 may record both meta information and SQL operation information in a CDC file, or only SQL operation information in a CDC file. In one embodiment, the source database server 110 may record meta information and SQL operation information in a CDC file in the CDC file in front of the SQL operation information. Further, according to an embodiment of the present disclosure, when the first transaction is committed before the second transaction, the source database server 110 may include the SQL operation included in the first transaction and the SQL included in the second transaction. You can write to the beginning of the CDC file rather than the operation. According to the above-described recording rules, the source database server 110 and the target database server 120 can efficiently implement CDC while recording both meta information and SQL operation information in a single file.

When recording according to the above-described recording rules, when reading the CDC file received from the target database server 120 and applying the file to the target database server 120, the meta information about a specific object is first read. Then, the SQL statement corresponding to the SQL operation information related to the meta information can be easily written using the meta information.

As described above, according to an embodiment of the present disclosure, since SQL operations and meta information can be recorded together in a single CDC file, compared to an embodiment in which a separate file managing only meta information exists, CDC can be implemented in an efficient manner. For example, in the embodiment in which a separate file for recording only SQL operation information and recording and managing meta information exists in the CDC file, meta information for all objects must be stored in the file for recording meta information. . Furthermore, when only the meta information is managed separately, when DDL occurs, since the meta information needs to be corrected, there is no choice but to stop operating in the database server, which may be referred to as “Stop The World”. In this case, since the meta information is managed as a meta file from the viewpoint of the target database server 120, a meta file storing meta information about all objects must be loaded in its memory. Therefore, according to this embodiment, there is a disadvantage that the usage of the memory is maximized. However, if meta information and SQL operation information are managed as one file according to an embodiment of the present disclosure, data is used to implement CDC while reducing memory usage between the source database server 110 and the target database server 120. Latency can also be minimized. According to an embodiment of the present disclosure, since only meta information about a table in which DML or DDL has occurred is recorded in one CDC file, memory usage can be significantly reduced. In addition, according to an embodiment of the present disclosure, memory loading is performed in units of metadata for a specific table, and after the metadata for the specific table is loaded into memory, SQL operations on the specific table are performed. By recording, it is possible to eliminate the factor of performance degradation in implementing CDC in the database server.

The source database server 110 may determine to transmit the CDC file to the target database server 120 (450). Communication between the source database server 110 and the target database server 120 may be performed by any form of communication network and / or any form of dblink.

4 is a flowchart exemplarily illustrating a CDC method performed in a source database server (or agent server) according to an embodiment of the present disclosure.

The steps shown in FIG. 4 are exemplary, and additional steps may be present or some of the steps may be omitted. The steps illustrated in FIG. 4 may be performed at the source database server 110 or agent server 130. For convenience of description, it will be described below on the assumption that it is performed in the source database server 110.

4 exemplarily shows embodiments for a case in which DML operation is performed and embodiments for a case in which DDL operation is performed.

As shown in FIG. 4, the source database server 110 analyzes log records that contain information about transactions processed by the source database server 110, thereby generating SQL operations on one or more objects associated with the transaction. Can be identified (510). When changes to data, tables, and / or indexes occur in the source database server 110 according to a transaction initiated by a client, log records for the transaction may be recorded in the source database server 110. In this case, the source database server 110 may extract change data by analyzing log records recorded in the log buffer and / or log files in the source database server 110. For example, when DML occurs in the source table, the source database server 110 may extract new changed data after the most recently acquired / extracted changed data as change data. As another example, when the DDL for the source table is generated, the source database server 110 may recognize the DDL for the table as change data and extract it as change data to be reflected in the target database server 120. . Additionally, the source database server 110 may sort change data in time series based on the SCN value of the change data.

The source database server 110 may determine a type for each of the identified plurality of SQL operations (520). For example, the source database server 110 may determine whether each of the identified plurality of SQL operations is a DML operation or a DDL operation. As described above, depending on the type of SQL operation, a method of recording information in a CDC file may be different.

If the type for the SQL operation is determined to be a DML operation, in step 530, the source database server 110 may determine that it is necessary to determine whether or not a previous SQL operation history for an object corresponding to the DML operation exists ( 530). Then, the source database server 110 may determine whether a previous SQL operation history exists in the CDC file.

When it is determined that the previous SQL operation history exists in the CDC file, the source database server 110 may generate meta information about the object using DD information for the object (550). If it is determined that the previous SQL operation history does not exist in the CDC file, the source database server 110 may determine to use the previously generated meta information without generating meta information about the corresponding object (550).

Then, when the meta information about the object is generated, the source database server 110 may determine to record the SQL operation related to the object and the generated meta information in a single CDC file (560). In addition, when it is determined that generation of meta information for the corresponding object is not necessary, the source database server 110 may determine to record the SQL operation in the single CDC file.

Then, the source database server 110 may determine to transmit the CDC file to the target database server 120 (570).

Returning to step 520, when the types of the identified plurality of SQL operations are determined to be DDL types, according to the characteristics of the DDL operations, new DD information for the corresponding object must be corrected according to the incoming DDL operation. Accordingly, when the type of the SQL operation is determined to be a DDL type, the source database server 110 may determine not to determine whether or not a previous SQL operation history for an object corresponding to the DDL operation exists in the CDC file (540). . Then, the source database server 110 may determine to generate meta information about the object corresponding to the DDL operation and record the generated meta information in the CDC file based on the received DDL operation (540). In one embodiment, meta information corresponding to the DDL operation may be recorded at a position subsequent to the recording position of other SQL operations performed before the DDL operation in the CDC file. Then, the source database server 110 may determine to transmit the CDC file in which the information is recorded to the target database server 120 (570).

5 is a flowchart exemplarily illustrating a CDC method performed in the target database server 120 (or agent server 130) according to an embodiment of the present disclosure.

The steps shown in FIG. 5 are exemplary, and additional steps may be present or some of the steps may be omitted. The steps illustrated in FIG. 5 may be performed on the target database server 120 or the agent server 130. For convenience of description, hereinafter, it is assumed that the target database server 120 is performed.

As illustrated in FIG. 5, the target database server 120 may receive a CDC file from the source database server 110 (1010). The target database server 120 may receive the CDC file generated by the source database server 110 and apply it to the target database server 120. Communication between the source database server 110 and the target database server 120 may be performed by any form of communication network and / or any form of dblink.

The target database server 120 may determine whether meta information corresponding to the target database server 120 exists in the memory by reading meta information recorded in the received CDC file (1020). CDC files may be read from the target database server 120 in the order recorded by the source database server 110. Accordingly, the target database server 120 reads the CDC files recorded according to a predetermined recording rule in the source database server 110 in the recording order and performs corresponding operations in the read order, thereby reducing memory usage. In addition, the CDC operation can be performed without latency.

When there is no corresponding meta information, the target database server 120 may load the meta information recorded in the CDC file into the memory (1030). In addition, when the corresponding meta information exists, the target database server 120 may determine not to newly load the meta information recorded in the CDC file, but to use the existing meta information (1030). For example, when meta information for a specific table is previously loaded in the memory of the target database server 120, since there is no need to newly load meta information into the memory, the target database server is used using the existing loaded meta information. A change data reflection operation to 120 may be performed.

The target database server 120 reads the SQL operations recorded in the CDC file in order, and generates the SQL statement corresponding to the SQL operation by using the meta information on the memory corresponding to the read SQL operation. Can (1040). The SQL statement generated by the target database server 120 may mean an SQL statement for generating an SQL operation performed by the source database server 110. The target database server 120 automatically reflects the change data to its DB by performing the same SQL operation performed by the source database server 110 using the SQL operation information and meta information recorded in the CDC file. I can do it.

Then, the target database server 120 may apply the generated SQL statement to the target database server. Through the above-described method, change data corresponding to the SQL operation performed automatically by the source database server 110 may be reflected in the target database server 120.

As described above, in the CDC file used when the target database server 120 reflects the change data in its DB, meta information about the object where the SQL operation occurred among the objects of the source database server 110 will be recorded. Can be. In this way, the target database server 120 does not need to load meta information for all objects in its memory, and only meta information for objects related to change data in the source database server 110 is stored. Since it is loaded in, the memory usage within the database server can be significantly reduced.

6 schematically illustrates CDC operations performed in a database system according to one embodiment of the present disclosure. In FIG. 6, operations performed between the source database server 110 and the target database server 120 are exemplarily represented.

As illustrated in FIG. 6, the source database server 110 may include a source DBMS 610 and a source processor 620. The source DBMS 610 may be operated by the source processor 620 on the memory of the source database server 110.

Here, the memory is a main storage device directly accessed by a processor, such as dynamic random access memory (DRAM) or static random access memory (SRAM), and stored information when the power is turned off. Can mean a volatile storage device that is instantly erased, but is not limited to these. Such a memory can be operated by the processor as described above. The memory can store any type of data, such as change data. Alternatively, the memory may store a data table including data values. In one embodiment of the present invention, change data and / or data values of the data table may be recorded from memory to a permanent storage medium. In a further aspect, the memory includes a buffer cache, and data may be stored in a data block of the buffer cache. The data can be recorded on a permanent storage medium by a background process.

Persistent storage media herein include, for example, magnetic disks, optical disks and magneto-optical storage devices, as well as flash memory and / or battery-backed memory based storage devices. , Means a non-volatile storage medium capable of continuously performing arbitrary data. The permanent storage medium may communicate with the processor and memory of the database servers 110 and 120 through various communication means. In additional embodiments, such permanent storage media may be located outside the database servers 110 and 120 to communicate with the database servers 110 and 120.

DBMS (610, 710) is a program for allowing the database server 110 and 120 to perform operations such as retrieving, inserting, modifying and / or deleting necessary data, and as described above, the database server 110 and It may be implemented by the processor (620, 720) in the memory of 120). In addition, the source DBMS 610 may determine to generate, manage and store redo logs for transactions occurring in the source database server 110. The source processor 620 extracts and analyzes the stored redo logs to implement the CDC operation (630), records the contents in the CDC file 670, and reads the CDC file 670 (650) to the network. It may be transmitted to the target database server 120 through 140 (660). Each of the extract 630, write 640, read 650, and transmit 660 operations of the source processor 620, as described above, extract module 210, write module 220 in FIG. The read module 230 and the transmit / receive module 240 may correspond to operations performed. Additionally, extract 630, write 640, read 650 and transmit 660 operations may each be performed by separate threads. Further, a plurality of extract 630, write 640, read 650 and transmit 660 operations may be performed by a single thread. Also, the operations of extracting 630, writing 640, reading 650 and transmitting 660 may be performed by separate processes, or a process may perform a plurality of operations among the above operations. Hereinafter, for convenience of description, it is assumed that one process performs one module operation, and CDC features according to embodiments of the present disclosure will be described.

In one embodiment of the present disclosure, when a Commit operation for a transaction is performed, a CDC operation in the source processor 620 may be initiated. For example, when the Commit operation of the transaction is performed, the source processor 620 may perform the extraction operation 630. As another example, the source processor 620 may perform a CDC operation for a plurality of transactions related to corresponding Commit operations when a predetermined number of Commit operations are performed (eg, when Commit operations are performed for two transactions). Can be initiated. In another embodiment, CDC operation of the source processor 620 may be initiated according to a predetermined time period or a predetermined SCN period.

As shown in FIG. 6, transactions 680 for the T1 object and the T2 object may be fetched from the source DBMS 610. The transactions 680 may include a first transaction and a second transaction. The first transaction may include a Delete operation and a Commit operation on the T1 object. The second transaction may include an Insert operation on the T1 object, an Update operation on the T2 object, and a Commit operation. The SQL operations 680 performed on the source DBMS 610 may be sorted in time series and on a transaction basis based on when the Commit operation is performed. In FIG. 6, since the Commit operation for the first transaction is performed before the Commit operation for the second transaction, the SQL operations for the first transaction may be disposed in front of the SQL operations for the second transaction.

The source processor 620 (eg, the extract 630 thread) may extract the Delete operation and the Commit operation for the T1 object from the redo log, sort them in chronological order, and deliver them to the read 640 thread, for example. The read 640 thread may check the Delete operation (that is, Delete T1) for the T1 object that is disposed first, and determine whether a previous SQL operation history for the T1 object exists in the CDC file 670. . In one example, the read 640 thread may determine whether a previous DML or DDL for the T1 object has been made. As shown in FIG. 6, since the previous SQL operation has not been performed on the T1 object, the read 640 thread uses the DD (Data Dictionary) information held in the memory and meta information about T1 (ie, T1 DD). Then, the read 640 thread may write T1 DD, which is meta information about T1, and Delete T1, which is a Delete operation on T1, to the CDC file 670. In this case, the meta information T1 DD may be recorded in a CDC file in front of Delete T1 which is SQL operation information. Additionally, the read 640 thread can write a commit operation on the T1 object to the CDC file 670. In this case, the Commit operation may be recorded in a portion after the Delete T1 in the CDC file 670 is recorded.

In one embodiment of the present disclosure, the extracting 630 thread may extract the Insert operation for the T1 object, the Update operation for the T2 object, and the Commit operation for the second transaction included in the second transaction in the redo log. . The extraction 630 thread may be arranged in the order of Insert T1, Update T2, and Commit operations according to the order of occurrence of SQL operations. Since the second transaction is committed after the first transaction, among the SQL operations 680 performed in the source DBMS 610, SQL operations related to the first transaction are placed before SQL operations related to the second transaction. It can be arranged as much as possible. The read 640 thread will read Delete T1 and Commit operations for the first transaction, and then read operations related to transaction 2. The read 640 thread reads the Insert operation on the T1 object (ie, Insert T1) and whether the DML or DDL for the T1 object has occurred in the CDC file 670 (i.e., whether a previous SQL operation history exists). Can judge. Since the DD information for the T1 object is recorded in the CDC file 670 in processing the operations related to the first transaction (ie, Delete T1), the read 640 thread is assigned to the T1 object in the CDC file 670. It will be judged that there is a previous SQL operation history. In this situation, the read 640 thread may write an Insert operation (ie, Insert T1) on the T1 object to the next recording location in the CDC file 670 without generating meta information for the T1 object. Then, the read 640 thread can recognize the Update operation on the T2 object. The read 640 thread will determine whether the previous SQL operation exists for the T2 object by checking the CDC file 670, and since the previous SQL operation does not exist, the DD for the T2 object stored in the memory Meta information (ie, T2 DD) for the T2 object may be generated using the information. The read 640 thread can then write meta information about the T2 object to the next location in the CDC file 670. Then, the read 640 thread may record an Update operation (that is, Update T2) for the T2 object at a subsequent position of the location where the meta information for the T2 object is recorded. Additionally, the read 640 thread can write a Commit operation for the T2 object to the CDC file 670. In this case, the Commit operation may be recorded in a portion after the Update T2 in the CDC file 670 is recorded. Information 690 may be recorded in the CDC file 670 based on the Commit time for transactions and the occurrence time of operations in the above-described manner. Since both meta information and SQL operation information can be recorded in a single CDC file 670 in this manner, the CDC can be implemented in an efficient manner. In addition, only the meta information where the Commmit has occurred can be loaded from the memory in the source database server 110, and the CDC file 670 contains information 690 in order according to the recording rules according to embodiments of the present disclosure. Since it is recorded, the target database server 120 can easily reflect the changed data in its DB while reading in the order recorded in the single CDC file 670 created by the source database server 110. That is, meta information about an object in which an SQL operation occurs among objects of the source database server 110 may be recorded in a CDC file used when the target database server 120 reflects change data in its DB. In this way, the target database server 120 does not need to load meta information for all objects in its memory, and only meta information for objects related to change data in the source database server 110 is stored. Since it is loaded in, the memory usage within the database server can be significantly reduced.

In a further aspect of the disclosure, the client 110 and the database servers 120 and 130 or the database servers 120 and 130 can communicate with each other via a network (not shown). The network according to an embodiment of the present invention is a public switched telephone network (PSTN), x Digital Subscriber Line (xDSL), Rate Adaptive DSL (RADSL), Multi Rate DSL (MDSL), Very High Speed DSL (VDSL) ), UADSL (Universal Asymmetric DSL), HDSL (High Bit Rate DSL), and various wired communication systems such as a local area network (LAN).

In addition, the network proposed in this specification is CDMA (Code Division Multi Access), TDMA (Time Division Multi Access), FDMA (Frequency Division Multi Access), OFDMA (Orthogonal Frequency Division Multi Access), SC-FDMA (Single Carrier-FDMA) ) And other systems. In addition, the network in this specification may include a database link (dblink), so that the source database server 110 and the target database server 120 (or agent server 130) communicate with each other through such a database link. Data from another database server. In one example, the database link may include a database link from the source database server 110 to the target database server 120. The techniques described herein can be used in the networks mentioned above, as well as other networks.

6, the target database server 120 may include a target DBMS 710 and a target processor 720. The target DBMS 710 may be operated by the target processor 720 on the memory of the target database server 120. Since the hardware configurations of the target database server 120 and the description of the target DBMS 710 are the same as the hardware configurations of the source database server 110 and the configuration of the source DBMS 610 described above, the corresponding description is here. Will be omitted from.

The target processor 720 receives (730) the CDC file 670 to implement the CDC operation, records the contents of the CDC file 770 (740) (or receives the received CDC file 670). The CDC file 770 may be used as it is, and the CDC file 770 may be read 750 to reflect 760 the change data to the target DBMS 710. Each of the receive 730, write 740, read 750, and change / reflect 760 operations of the target processor 720, as described above, receive module 310, write module 320 in FIG. ), And may correspond to operations performed by the read module 330 and the change / reflect module 340. Additionally, receive 730, write 740, read 750 and change / reflect 760 operations may each be performed by separate threads. Further, a plurality of receive 730, write 740, read 750 and change / reflect 760 operations may be performed by a single thread. In addition, the receive 730, write 740, read 750 and change / reflect 760 operations may each be performed by separate processes, or a process may perform multiple operations among the above operations. Hereinafter, for convenience of description, it is assumed that one process performs one module operation, and CDC features according to embodiments of the present disclosure will be described.

The target processor 720 of the target database server 120 (eg, the receiving 730 thread) may receive the CDC file 670 from the source database server 110. The target processor 720 of the target database server 120 records 740 the received CDC file 670 in the same way as its CDC file 770, or records the received CDC file 670 in its CDC file (670). 770). The read 750 thread of the target processor 720 may read the information 780 recorded in the CDC file 770 and transfer it to the change / reflect 760 thread.

The change / reflect 760 thread may read the meta information called T1 DD first recorded in the CDC file 770 to determine whether DD meta information for the T1 object exists in its memory. When meta information about the T1 object does not exist in the memory of the target database server 120, the target database server 120 may load the T1 DD meta information into its memory. Then, the change / reflect 760 thread can confirm Delete T1 recorded after the information T1 DD in the CDC file 770. The change / reflect 760 thread may automatically generate an SQL statement for performing a Delete operation on the T1 object by using the T1 DD meta information loaded on the memory and reflect it on the target DBMS 710. Then, the change / reflect 760 thread can confirm the Commit and reflect the Commit to the target DBMS 710. Then, the change / reflect 760 thread can check Insert T1 which is the next recorded information in the CDC file 770. Since it is an operation on the T1 object, the change / reflect 760 thread can generate an SQL statement for performing an Insert operation on the T1 object using meta information about the T1 object loaded in memory.

The change / reflect 760 thread may check the T2 DD meta information recorded at the next position in the CDC file 770. The change / reflect 760 thread may check whether DD meta information for the T2 object exists in the memory of the target database server 120. The change / reflect 760 thread loads meta information about the T2 object (that is, T2 DD meta information) into the memory of the target database server 120 when it is determined that there is no meta information about the T2 object loaded in its memory. can do. The change / reflect 760 thread can then recognize the Update T2 recorded at the next location in the CDC file 770. The change / reflect 760 thread may load meta information about the T2 object from the memory and automatically generate an SQL statement corresponding to the Update operation for the T2 object by using the meta information. Then, the change / reflect 760 thread can reflect the SQL statement for performing the Update operation on the T2 object in its DBMS 710. Then, the change / reflect 760 thread can confirm the commit and reflect it to the DBMS 710.

According to an embodiment of the present disclosure, a recording rule for a CDC file may include recording meta information about a specific object in a first order and subsequently recording DML or DDL for a specific table. According to an embodiment of the present disclosure, a recording rule for a CDC file determines the order of transactions to be recorded according to the order in which the commits occur, and records meta information in the SQL operation information before, for a single CDC file. Through delivery, CDC can be easily achieved. According to an embodiment of the present disclosure, memory usage may be significantly reduced compared to a configuration in which all meta information is loaded into memory and CDC is implemented (ie, a configuration in which meta information and SQL operation information are managed by individual files). In addition, a situation in which the operation of the database server stops in a situation such as DDL occurrence can be prevented. In addition, CDC features according to an embodiment of the present disclosure can significantly reduce memory usage compared to an existing structure in reflecting DML or DDL for a plurality of tables.

CDC implementations that separately manage meta information and SQL operation information share a separate file that records meta information about all objects while transmitting and receiving between the two database servers. Accordingly, these implementation methods require that the target database server 120 also retains DD information for an object in which DML has not occurred in memory. That is, the target database server 120 should retain DD information for as many objects as possible in memory according to all objects (eg, tables) or memory capacity. In addition, in this case, when DDL occurs, the source database server 110 is idle until the transmission of the meta file is completed even if the file that records the meta information must be manually generated and transmitted or the file that records the meta information is automatically transmitted. You must wait in the (idle) state. However, CDC implementations according to an embodiment of the present disclosure do not need to separately generate and transmit a meta file in which meta information is stored, and do not generate an idle state of the source database server 110. Accordingly, CDC implementation schemes according to an embodiment of the present disclosure may allow real-time DDL synchronization. Furthermore, since CDC implementations according to an embodiment of the present disclosure manage DD information for a table in which DML has occurred, memory management in the target database server 120 can be efficiently performed. For example, since a DD for a CDC file is managed with respect to read / write and a DD for a DML-generated object with respect to change / reflection will be managed, a more resource-efficient CDC implementation may be possible. have.

7 schematically illustrates CDC operations performed in a database system according to an embodiment of the present disclosure.

The embodiment shown in FIG. 7 is a DDL feature added to the embodiment shown in FIG. 6, and contents common to the embodiments in FIG. 6 will be omitted below for convenience of description. For example, the extract 830, write 840, read 850, and transmit 860 operations in FIG. 7 include extract 630, write 640, read 650, respectively, in FIG. And transmit 660 operations. In addition, the receive 930, write 940, read 950, and change / reflect 960 operations in FIG. 7 include receive 730, write 740, and read 750 in FIG. 6, respectively. And change / reflect 760 operations. In addition, the source DBMS 810, the source processor 820, the target DBMS 910, and the target processor 920 in FIG. 7 are the source DBMS 610, the source processor 620, and the target DBMS in FIG. 6, respectively. 710) and the target processor 720.

As shown in FIG. 7, transactions 880 may be imported into the source DBMS 810. In the example in FIG. 7, the transactions 880 include a first transaction including Insert T1, Update T2 and Commit, a second transaction including Delete T3 and Commit, and a third transaction including DDL T1 can do. The source processor 820 may arrange operations included in the incoming transactions in the order of occurrence time, as indicated by reference numeral 880. For example, the extracting 830 thread may analyze the redo log of transactions generated in the source DBMS 810, extract information about the changed data as reference number 880, and sort the extracted data.

Even if the second transaction is started later than the first transaction, since the commit time of the second transaction is faster than the commit time of the first transaction, the source processor 820 may perform SQL operations related to the second transaction and SQL related to the first transaction. The CDC file 870 can be written before operations. SQL operations related to transactions may be recorded in the CDC file 870 according to the time sequence generated within the transaction.

As shown in FIG. 7, the record 840 thread can recognize that a Delete operation has been performed on the T3 object in the second transaction. The record 840 thread may check whether meta information about the T3 object exists in the CDC file 870. That is, the record 840 thread can check in the CDC file 870 whether there is a previous SQL execution history for the T3 object. Since there is no meta information for the T3 object, the recording 840 thread generates meta information for the T3 object by using the DD information loaded on the memory, and the generated meta information (ie, T3 DD # 1) ) In the CDC file 870. Then, the record 840 thread may record a Delete operation on the T3 object (ie, Delete T3) in the CDC file 870. Additionally, the record 840 thread may write a Commit operation for the second transaction to the CDC file 870. The recording position of the Commit operation is later than that of Delete T3.

The record 840 thread may begin writing to the CDC file 870 for the first transaction after completing writing to the CDC file 870 for the second transaction. The record 840 thread may check Insert T1 and check whether meta information about the T1 object exists in the CDC file 870. As shown in FIG. 7, since only the meta information for the T3 object is recorded in the current CDC file 870, the record 840 thread stores the meta information for the T3 object in DD information (eg, a T3 object) in memory. DD information for. Then, the recording 840 thread may record meta information (ie, TT DD # 1) for the created T3 object as a CDC file 870. Then, the record 840 thread can record the Insert T1 operation previously identified in the CDC file 870 after the location where the meta information is recorded. The record 840 thread can check the Update T2 operation, which is the SQL operation generated after Insert T1 in the first transaction. The record 840 thread may check whether meta information about the T2 object exists in the CDC file 870. Since the meta information about the T3 object and the meta information about the T2 object are recorded in the current CDC file 870, the record 840 thread can determine that there is no meta information about the T2 object. In this case, the recording 840 thread may generate meta information about the T2 object by referring to the DD information about the T2 object loaded on the memory. Then, the recording 840 thread may record meta information of the generated T2 object as a CDC file 870. Meta information of the T2 object may be recorded at a position subsequent to the recording position of the insert T1 recorded immediately before. Then, the recording 840 thread may record the Update T2 operation corresponding to the recorded meta information subsequent to the CDC file 870. Then, the record 840 thread can record the Commit operation for the first transaction in the CDC file 870. The recording position of the Commit operation is later than that of Update T2.

The record 840 thread may check the third transaction (including DDL T1) after all operations for the first transaction are reflected. The record 840 thread may determine the type of the SQL operation, and determine that it is a DDL type. That is, when it is determined that the type of the SQL operation is a DML operation, the record 840 thread determines to determine whether or not the previous SQL operation history for the object corresponding to the DML operation exists in the CDC file 870. Can be. In addition, when it is determined that the type of the SQL operation is a DDL operation, the record 840 thread does not determine whether a previous SQL operation history for an object corresponding to the DDL operation exists in the CDC file 870, and the Based on the DDL operation, it is possible to generate meta information about an object corresponding to the DDL operation and to record the generated meta information in the CDC file. Accordingly, the recording 840 thread may generate meta information corresponding to the DDL operation for T1 and record the DDL T1 in the CDC file 870 as illustrated in FIG. 7.

The read 850 thread can read the CDC file 870 recorded by the write 840 thread and deliver it to the send 860 thread. The transmission 860 thread may transmit the received CDC file 870 to the target database server 120 through the network 140.

The target processor 920 of the target database server 120 may receive the CDC file 870 by a receive 930 thread. The record 940 thread of the target processor 920 may record the information recorded in the CDC file 870 received in its CDC file 970 in the same order. Alternatively, the recording 940 thread of the target processor 920 may use the received CDC file 870 as its own CDC file 970. Therefore, the CDC file 970 of the target database server 120 may include information in the order recorded by the source database server 110 as shown by reference numeral 980.

The read 950 thread of the target database server 120 may transfer the information 980 recorded in the CDC file 970 to the change / reflect 920 thread, and the change / reflect 920 thread may receive the received information. Reflecting on the target DBMS 910, synchronization of the target DBMS 910 and the source DBMS 810 may be performed. The change / reflect 920 thread may perform reflection to the target DBMS 910 in the order of recording the information expressed by reference number 980. Since the meta information for a specific SQL operation is first recorded in the CDC file 970, and the corresponding SQL operation information can be recorded thereafter, and the corresponding meta information is recorded for the DDL operation, the target database server 120 itself It is not necessary to load meta information about many objects in the memory of. It can process reflection by loading meta information about the object where DML has occurred. Since the detailed reflection method has been described above with reference to FIG. 6, a description thereof will be omitted in FIG. 7.

8 shows a block diagram of an exemplary computing device for implementing a CDC solution in accordance with one embodiment of the present disclosure.

Although the present invention has been described above in general with respect to computer-executable instructions that may be executed on one or more computers, those skilled in the art will appreciate that the present invention may be implemented in combination with other program modules and / or a combination of hardware and software. will be.

Generally, program modules include routines, procedures, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In addition, those of ordinary skill in the art may find that the method of the present invention includes single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc. It will be appreciated that it may be implemented with other computer system configurations, including those that may operate in conjunction with one or more associated devices.

The described embodiments of the invention may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Computers typically include a variety of computer readable media. Any computer-readable medium can be a computer-readable medium, and the computer-readable medium can include a computer-readable storage medium and a computer-readable transmission medium. Such computer-readable storage media include volatile and non-volatile media, removable and non-removable media. Computer readable storage media includes volatile and nonvolatile media, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer-readable storage media may include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital video disk (DVD) or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage Devices, or any other medium that can be accessed by a computer and used to store desired information.

Computer readable transmission media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism. Includes information delivery media. The term modulated data signal means a signal in which one or more of the characteristics of the signal are set or changed to encode information in the signal. By way of example, and not limitation, computer readable transmission media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above-described media are also intended to be included within the scope of computer-readable transmission media.

An exemplary environment 1100 is shown that implements various aspects of the present invention, including a computer 1102, which includes a processing unit 1104, a system memory 1106, and a system bus 1108. do. System bus 1108 connects system components, including, but not limited to, system memory 1106 to processing device 1104. The processing device 1104 can be any of a variety of commercial processors. Dual processor and other multiprocessor architectures may also be used as the processing unit 1104.

The system bus 1108 can be any of several types of bus structures that can be further interconnected to a memory bus, peripheral bus, and local bus using any of a variety of commercial bus architectures. System memory 1106 includes read-only memory (ROM) 1110 and random access memory (RAM) 1112. A basic input / output system (BIOS) is stored in a non-volatile memory 1110 such as ROM, EPROM, EEPROM, etc., and this BIOS is basic to help transfer information between components in the computer 1102 at the same time as during startup. Contains routines. The RAM 1112 may also include high-speed RAM, such as static RAM for caching data.

Computer 1102 also has an internal hard disk drive (HDD) 1114 (eg, EIDE, SATA) —this internal hard disk drive 1114 can also be configured for external use within a suitable chassis (not shown). Yes, magnetic floppy disk drive (FDD) 1116 (e.g., for reading from or writing to removable diskette 1118), and optical disk drive 1120 (e.g., CD-ROM Disc 1122, or for reading from or writing to other high-capacity optical media such as DVDs). The hard disk drive 1114, the magnetic disk drive 1116, and the optical disk drive 1120 are the system bus 1108 by the hard disk drive interface 1124, the magnetic disk drive interface 1126, and the optical drive interface 1128, respectively. ). The interface 1124 for implementing an external drive includes at least one of USB (Universal Serial Bus) and IEEE 1394 interface technology, or both.

These drives and their associated computer-readable media provide non-volatile storage of data, data structures, computer-executable instructions, and the like. In the case of computer 1102, drives and media correspond to storing any data in a suitable digital format. Although the above description of computer readable media refers to HDDs, removable magnetic disks, and removable optical media such as CDs or DVDs, those of ordinary skill in the art can use zip drives, magnetic cassettes, flash memory cards, cartridges, etc. It will be appreciated that other types of media readable by a computer, etc., may also be used in the exemplary operating environment and any such media may include computer-executable instructions for performing the methods of the present invention.

A number of program modules may be stored in the drive and RAM 1112, including the operating system 1130, one or more application programs 1132, other program modules 1134, and program data 1136. All or part of the operating system, applications, modules, and / or data may also be cached in RAM 1112. It will be appreciated that the present invention can be implemented in various commercially available operating systems or combinations of operating systems.

The user may input commands and information to the computer 1102 through one or more wired / wireless input devices, for example, pointing devices such as a keyboard 1138 and a mouse 1140. Other input devices (not shown) may include a microphone, IR remote control, joystick, game pad, stylus pen, touch screen, etc. These and other input devices are often connected to the processing unit 1104 through an input device interface 1142 connected to the system bus 1108, but the parallel port, IEEE 1394 serial port, game port, USB port, IR interface, And other interfaces.

The monitor 1144 or other type of display device is also connected to the system bus 1108 through an interface such as a video adapter 1146. In addition to the monitor 1144, the computer generally includes other peripheral output devices (not shown) such as speakers, printers, and the like.

The computer 1102 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer (s) 1148 via wired and / or wireless communication. The remote computer (s) 1148 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other conventional network node, typically for computer 1102. It includes many or all of the described components, but for simplicity, only the memory storage device 1150 is shown. The illustrated logical connections include wired / wireless connections to a local area network (LAN) 1152 and / or a larger network, such as a wide area network (WAN) 1154. Such LAN and WAN networking environments are common in offices and companies, and facilitate enterprise-wide computer networks such as intranets, all of which can be connected to computer networks around the world, for example, the Internet.

When used in a LAN networking environment, the computer 1102 is connected to the local network 1152 via a wired and / or wireless communication network interface or adapter 1156. The adapter 1156 may facilitate wired or wireless communication to the LAN 1152, which also includes a wireless access point installed therein to communicate with the wireless adapter 1156. When used in a WAN networking environment, the computer 1102 may include a modem 1158, connect to a communication server on the WAN 1154, or otherwise establish communication over the WAN 1154, such as through the Internet. Have a means The modem 1158, which may be an internal or external and wired or wireless device, is connected to the system bus 1108 via a serial port interface 1142. In a networked environment, program modules described for the computer 1102 or portions thereof may be stored in the remote memory / storage device 1150. It will be appreciated that the network connections shown are exemplary and other means of establishing a communication link between computers can be used.

The computer 1102 is associated with any wireless device or object that is deployed and operates in wireless communication, such as a printer, scanner, desktop and / or portable computer, a portable data assistant (PDA), communication satellite, or wireless detectable tag. It operates to communicate with any equipment or place and telephone. This includes at least Wi-Fi and Bluetooth wireless technology. Accordingly, the communication may be a predefined structure as in a conventional network or simply ad hoc communication between at least two devices.

Wi-Fi (Wireless Fidelity) enables a connection to the Internet or the like without a wired connection. Wi-Fi is a wireless technology such as a cell phone that allows a computer, for example, a computer to transmit and receive data indoors and outdoors, ie anywhere within the base station's coverage area. Wi-Fi networks use a wireless technology called IEEE 802.11 (a, b, g, etc.) to provide a secure, reliable and high-speed wireless connection. Wi-Fi can be used to connect computers to each other, to the Internet, and to a wired network (using IEEE 802.3 or Ethernet). Wi-Fi networks can operate in unlicensed 2.4 and 5 GHz radio bands, for example, at 11 Mbps (802.11a) or 54 Mbps (802.11b) data rates, or in products that include both bands (dual band). have.

A person of ordinary skill in the art of the present invention may provide various exemplary logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the embodiments disclosed herein with electronic hardware, (convenience For the sake of understanding, it may be implemented by various forms of program or design code (referred to herein as “software”) or a combination of both. To clearly illustrate this interoperability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art of the present invention may implement the functions described in various ways for each specific application, but such implementation decisions should not be interpreted as being outside the scope of the present invention.

Various embodiments presented herein can be implemented as a method, apparatus, or article of manufacture using standard programming and / or engineering techniques. The term “manufactured article” includes a computer program, carrier, or media accessible from any computer-readable device. For example, computer-readable media include magnetic storage devices (eg, hard disks, floppy disks, magnetic strips, etc.), optical disks (eg, CDs, DVDs, etc.), smart cards, and flash memory Devices (eg, EEPROMs, cards, sticks, key drives, etc.), but are not limited to these. In addition, various storage media presented herein include one or more devices and / or other machine-readable media for storing information. The term “machine-readable medium” includes, but is not limited to, wireless channels and various other media capable of storing, retaining, and / or transferring command (s) and / or data.

It is understood that the specific order or hierarchy of steps in the processes presented is an example of exemplary approaches. Based on design priorities, it is understood that within the scope of the present invention, a specific order or hierarchy of steps in the processes may be rearranged. The accompanying method claims provide elements of the various steps in a sample order, but are not meant to be limited to the specific order or hierarchy presented.

The description of the presented embodiments is provided to enable any person of ordinary skill in the art to use or practice the present invention. Various modifications to these embodiments will be apparent to those skilled in the art of the present invention, and the general principles defined herein can be applied to other embodiments without departing from the scope of the present invention. Thus, the present invention should not be limited to the embodiments presented herein, but should be interpreted in the broadest scope consistent with the principles and novel features presented herein.

Claims (1)

A computer program stored on a computer readable storage medium including encoded instructions.

Images