WO2020101343A1 - 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법 - Google Patents

데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법 Download PDF

Info

Publication number
WO2020101343A1
WO2020101343A1 PCT/KR2019/015429 KR2019015429W WO2020101343A1 WO 2020101343 A1 WO2020101343 A1 WO 2020101343A1 KR 2019015429 W KR2019015429 W KR 2019015429W WO 2020101343 A1 WO2020101343 A1 WO 2020101343A1
Authority
WO
WIPO (PCT)
Prior art keywords
database server
cdc
meta information
cdc file
sql
Prior art date
Application number
PCT/KR2019/015429
Other languages
English (en)
French (fr)
Inventor
조오욱
윤정일
강승훈
이형도
Original Assignee
주식회사 실크로드소프트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 실크로드소프트 filed Critical 주식회사 실크로드소프트
Priority to US16/965,282 priority Critical patent/US11314719B2/en
Publication of WO2020101343A1 publication Critical patent/WO2020101343A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275—Synchronous replication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP

Definitions

  • the present invention relates to a database management system (DBMS), and more particularly, to a change data capture (CDC).
  • DBMS database management system
  • CDC change data capture
  • 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.
  • query offloading for improving the performance of the database
  • 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.
  • 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.
  • 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.
  • Patent Document 1 US Registered Patent US6,999,977
  • Patent Document 2 US Registered Patent US7,111,023
  • Patent Document 3 US Registered Patent US7,657,576
  • Patent Document 4 US Registered Patent US7,647,354
  • Patent Document 5 US Registered Patent US9,727,624
  • Patent Document 6 US Registered Patent US9,442,995
  • Patent Document 7 US Registered Patent US8,510,270
  • Patent Document 8 US Registered Patent US9,298,878
  • Patent Document 9 U.S. Registered Patent US7,461,103
  • Patent Document 10 US Registered Patent US7,065,538
  • Patent Document 11 US Registered Patent US7,668,878
  • Patent Document 12 US Registered Patent US6,832,229
  • Patent Document 13 US Registered Patent US8,799,213
  • Patent Document 14 US Registered Patent US9,230,002
  • Patent Document 15 U.S. Registered Patent US9,009,104
  • Patent Document 16 US Registered Patent US6,981,004
  • Patent Document 17 US Registered Patent US6,976,022
  • Patent Document 18 U.S. Registered Patent US7,908,243
  • Patent Document 19 US Registered Patent US9,841,909
  • Patent Document 20 US Registered Patent US9,495,252
  • Patent Document 21 US Registered Patent US8,676,759
  • Patent Document 22 US Registered Patent US9,646,042
  • Patent Document 23 US Registered Patent US9,047,392
  • Patent Document 24 US Registered Patent US7,831,574
  • Patent Document 25 US Registered Patent US8,874,506
  • Patent Document 26 US Registered Patent US8,385,657
  • Patent Document 27 US Patent Publication US2016-0314147
  • Patent Document 28 US 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.
  • 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).
  • CDC change data capture
  • 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.
  • SQL structured query language
  • a database server 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.
  • SQL Structured Query Language
  • a computer program stored in a computer readable storage medium including encoded instructions 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.
  • CDC change data capture
  • a database server 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.
  • CDC Change Data Capture
  • change data capture can be efficiently implemented without stopping the DB.
  • memory may be efficiently managed in a target DB.
  • FIG. 1 exemplarily illustrates a database system according to an embodiment of the present disclosure.
  • FIG. 2 exemplarily illustrates a source database server and a target database server in a database system according to an embodiment of the present disclosure.
  • FIG. 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.
  • FIG. 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.
  • FIG. 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.
  • FIG. 6 schematically illustrates CDC operations performed in a database system according to one embodiment of the present disclosure.
  • FIG. 7 schematically illustrates CDC operations performed in a database system according to an embodiment of the present disclosure.
  • FIG. 8 shows a block diagram of an exemplary computing device for implementing a CDC solution in accordance with one embodiment of the present disclosure.
  • an embodiment 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.
  • 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.
  • 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.
  • FIG. 1 shows a schematic diagram of a database system 100 according to an embodiment of the present invention.
  • the database system 100 may include a source database server 110, a target database server 120 and / or an agent server 130.
  • 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.
  • such clients may include PCs, laptop computers, workstations, terminals, and / or any electronic device with network connectivity.
  • the client may include any server implemented by at least one of an agent, an application programming interface (API), and a plug-in.
  • API application programming interface
  • 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.
  • DBMS database management system
  • 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.
  • 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.
  • the source database server 110 and the target database server 120 may refer to heterogeneous database servers located remotely from each other.
  • FIG. 1 shows two database servers, more database servers may be included in the scope of the present invention.
  • database servers 110 and 120 may include one or more memories including a buffer cache.
  • the database servers 110 and 120 may include one or more processors.
  • the DBMS in the database server can be operated by the processor on the memory.
  • 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.
  • 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.
  • data values and / or log records of a data table may be written from memory to a permanent storage medium.
  • 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 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).
  • PSTN public switched telephone network
  • xDSL Digital Subscriber Line
  • RADSL Rate Adaptive DSL
  • MDSL Multi Rate DSL
  • VDSL Very High Speed DSL
  • UADSL Universal Asymmetric DSL
  • HDSL High Bit Rate DSL
  • LAN local area network
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the agent server 130 may mean a separate entity for implementing CDC between the source database server 110 and the target database server 120.
  • the agent server 130 can perform any operations to implement CDC features.
  • 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.
  • software that implements the operations of the agent server 130 may be installed in the source database 110 and / or target database 120.
  • the agent server 130 may operate as any type of CDC module.
  • 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.
  • agent server 130 may be integrated as part of the source database server 110 and / or the target database server 120.
  • the CDC function of the agent server 130 may be replaced by the target database server 120.
  • FIG. 2 exemplarily illustrates a source database server 110 and a target database server 120 in a database system 100 according to one 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.
  • 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.
  • log records for the transaction may be recorded in the source database server 110.
  • 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.
  • 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.
  • 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.
  • SCN System Change Number
  • the extraction module 210 may identify a plurality of SQL operations generated for one or more objects associated with a transaction.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the recording module 220 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.
  • DD Data Dictionary
  • 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.
  • 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.
  • the transmit / receive module 240 may allow the transfer of information between database servers by invoking a procedure with the database server.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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).
  • log records for the transaction may be recorded in the source database server 110.
  • 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.
  • 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.
  • the source database server 110 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.
  • meta information may include at least one of table user information, table name information, column name information, column order information, and column type information.
  • 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.
  • 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.
  • CDC 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”.
  • meta information 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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).
  • log records for the transaction may be recorded in the source database server 110.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the source database server 110 may determine to transmit the CDC file to the target database server 120 (570).
  • 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).
  • 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).
  • FIG. 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.
  • 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.
  • 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.
  • the target database server 120 may apply the generated SQL statement to the target database server.
  • change data corresponding to the SQL operation performed automatically by the source database server 110 may be reflected in the target database server 120.
  • 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.
  • 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.
  • FIG. 6 schematically illustrates CDC operations performed in a database system according to one embodiment of the present disclosure.
  • operations performed between the source database server 110 and the target database server 120 are exemplarily represented.
  • 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.
  • 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.
  • a memory can be operated by the processor as described above.
  • the memory can store any type of data, such as change data.
  • the memory may store a data table including data values.
  • change data and / or data values of the data table may be recorded from memory to a permanent storage medium.
  • 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.
  • 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).
  • 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).
  • extract module 210 write module 220 in FIG.
  • the read module 230 and the transmit / receive module 240 may correspond to operations performed.
  • extract 630, write 640, read 650 and transmit 660 operations may each be performed by separate threads.
  • a plurality of extract 630, write 640, read 650 and transmit 660 operations may be performed by a single thread.
  • 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.
  • a CDC operation in the source processor 620 may be initiated.
  • the source processor 620 may perform the extraction operation 630.
  • 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.
  • CDC operation of the source processor 620 may be initiated according to a predetermined time period or a predetermined SCN period.
  • 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.
  • the SQL operations for the first transaction 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 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.
  • 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.
  • T1 DD may be recorded in a CDC file in front of Delete T1 which is SQL operation information.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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).
  • PSTN public switched telephone network
  • xDSL Digital Subscriber Line
  • RADSL Rate Adaptive DSL
  • MDSL Multi Rate DSL
  • VDSL Very High Speed DSL
  • UADSL Universal Asymmetric DSL
  • HDSL High Bit Rate DSL
  • LAN local area network
  • 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.
  • 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.
  • the database link may include a database link from the source database server 110 to the target database server 120.
  • 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.
  • a plurality of receive 730, write 740, read 750 and change / reflect 760 operations may be performed by a single thread.
  • 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.
  • the target processor 720 of the target database server 120 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.
  • the target database server 120 may load the T1 DD meta information into its memory.
  • 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.
  • 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.
  • the change / reflect 760 thread can reflect the SQL statement for performing the Update operation on the T2 object in its DBMS 710.
  • the change / reflect 760 thread can confirm the commit and reflect it to the DBMS 7
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • transactions 880 may be imported into the source DBMS 810.
  • 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.
  • 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.
  • 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.
  • 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.
  • the record 840 thread stores the meta information for the T3 object in DD information (eg, a T3 object) in memory. DD information for.
  • the recording 840 thread may record meta information (ie, TT DD # 1) for the created T3 object as a CDC file 870.
  • 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.
  • 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.
  • the record 840 thread 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.
  • 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.
  • FIG. 8 shows a block diagram of an exemplary computing device for implementing a CDC solution in accordance with one embodiment of the present disclosure.
  • program modules include routines, procedures, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules include routines, procedures, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • routines include routines, procedures, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules include routines, procedures, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules include routines, procedures, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • ROM read-only memory
  • RAM random access memory
  • 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).
  • HDD hard disk drive
  • FDD magnetic floppy disk drive
  • 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.
  • drives and their associated computer-readable media provide non-volatile storage of data, data structures, computer-executable instructions, and the like.
  • drives and media correspond to storing any data in a suitable digital format.
  • 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 may include a microphone, IR remote control, joystick, game pad, stylus pen, touch screen, etc.
  • 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.
  • 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.
  • 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.
  • the computer 1102 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.
  • 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.
  • 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.
  • PDA portable data assistant
  • Wi-Fi Wireless Fidelity
  • 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.
  • software program or design code
  • 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.
  • 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.
  • the present invention relates to a database management system (DBMS), and more particularly, to a change data capture (CDC).
  • DBMS database management system
  • CDC change data capture

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 개시의 일 실시예에 따라 인코딩된 명령들을 포함하는 컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램이 개시된다. 상기 컴퓨터 프로그램은 소스(source) 데이터베이스 서버의 하나 이상의 프로세서에 의해 실행되는 경우, 상기 하나 이상의 프로세서로 하여금 변경 데이터 캡쳐(CDC:Change Data Capture)를 위한 단계들을 수행하도록 한다. 상기 단계들은: 소스 데이터베이스 서버에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 분석함으로써, 상기 트랜잭션과 연관되는 하나 이상의 객체들에 대하여 발생된 복수의 SQL(Structured Query Language) 연산들을 식별하는 단계; 식별된 복수의 SQL 연산들이 발생한 순서에 기반하여, 개별 SQL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력(previous SQL operation history)이 CDC 파일에 존재하는지 여부를 판단하는 단계; CDC 파일에서의 이전 SQL 연산 이력의 존재 여부에 기초하여, 상기 CDC 파일에 기록할 정보를 결정하는 단계; 결정된 정보를 상기 CDC 파일에 기록하는 단계; 및 CDC 파일을 타겟(target) 데이터베이스 서버로 전송할 것을 결정하는 단계를 포함할 수 있다.

Description

[규칙 제26조에 의한 보정 29.11.2019]　데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법
본 발명은 데이터베이스 관리 시스템(DBMS)에 관한 것으로, 보다 구체적으로 변경 데이터 캡쳐(CDC:Change Data Capture)에 관한 것이다.
기업의 비즈니스는 폭발적인 데이터의 증가와 다양한 환경 및 플랫폼의 등장으로 빠르게 확장되고 있다. 새로운 비즈니스 환경이 도래함에 따라서, 보다 더 효율적이고 유연한 데이터 서비스와 정보의 처리, 데이터 관리 기능이 필요하게 되었다. 이러한 변화에 맞춰서 기업 비즈니스 구현의 기반이 되는 고성능, 고가용성 및 확장성의 문제를 해결하기 위한 데이터베이스에 대한 연구가 계속되고 있다.
기업 내에서 관리되는 데이터는 종종 소스(source) 위치로부터 타겟(target) 위치로 마이그레이션 또는 복제되어 관리할 필요가 있다. 예를 들어, 은행 업무를 구현하기 위한 데이터베이스 시스템은, 액세스하는 클라이언트의 특성에 따라서 다수의 외부 고객들이 동시에 액세스할 수 있는 데이터베이스 및 내부 직원들이 액세스할 수 있는 데이터베이스로 분류될 수 있다. 소스 데이터베이스 시스템으로부터의 변경 데이터를 타겟 데이터베이스 시스템으로 넘겨주는 솔루션은 변경 데이터 캡쳐(CDC:Change Data Capture)라 지칭된다. CDC는 예를 들어 소스 데이터베이스 시스템에서의 로그 파일을 판독 및 해석하여 소스 데이터베이스 시스템에서의 변경 데이터를 복제하고자 하는 타겟 데이터베이스 시스템에 리플레이(replay)시키는 방식으로 구현될 수 있다.
데이터 백업이나 데이터 통합 작업을 수행하는 경우 방대한 데이터를 다뤄야한다. 원본 소스 데이터베이스 시스템에서 최근 변경된 데이터만 선택하여 다른 타겟 데이터베이스 시스템으로 옮기게 되면, 시스템의 로드를 줄일 수 있을 뿐만 아니라 전체적인 작업의 생산성이 향상될 수 있다. 특히, 하나의 시스템에 있는 대량의 데이터를 정기적으로 추출하여 다른 시스템으로 이동시키는 데이터 통합 혹은 데이터 웨어하우스의 업무의 경우, CDC 기술을 이용하게 되면 데이터를 추출하고 이동시키는데 소요되는 시간이 크게 줄어들 수 있다. 또한, 24시간 운영이 요구되는 업무 시스템의 경우에도 CDC 기술을 이용하게 되면, 다운타임 없이 실시간 백업과 데이터 통합이 가능할 수 있다.
나아가, 데이터베이스의 성능향상을 위한 쿼리 오프로딩(query offloading)을 구현하는데 있어서, 예를 들어 마스터(master) 데이터베이스에서는 쓰기/업데이트만을 허용하고, 스테이징(staging) 데이터베이스에서는 마스터 데이터베이스의 데이터의 적어도 일부를 복제하고 그리고 N개의 슬레이브(slave) 데이터베이스로 복제된 데이터를 복사하여 전달한다. 이러한 쿼리 오프로딩을 사용하는 경우, 데이터베이스에 대한 쓰기 로직은 마스터 데이터베이스에서 수행되고 그리고 읽기 로직은 슬레이브 데이터베이스에서 수행될 수 있어서, 트랜잭션의 종류에 따른 분리가 가능해질 수 있다. 이에 따라 데이터베이스의 처리량이 증가되는 등과 같이 데이터베이스의 성능이 향상될 수 있다.
전술한 이유들 때문에, 주요 데이터베이스 업체들이 현재 CDC 솔루션에 대한 제품을 지속적으로 개발하고 있다.
이러한 CDC를 구현하기 위한 방식은 예를 들어, 로우 타임스탬프(row timestamp) 방식, 로우 버전(row version) 방식, 락(lock) 방식, 로우 상태 지시자(row state indicator) 방식, 테이블 트리거(table trigger) 방식 및 이벤트 프로그래밍(event programming) 방식이 존재할 수 있다.
특히 CDC 솔루션에 있어서, 복수개의 데이터베이스 시스템들 간의 데이터의 정합성을 유지하기 위해서는 양 데이터베이스들 간에 동기화가 이루어져야 한다. 하지만, 이러한 동기화를 구현하기 위해서는 데이터베이스 리소스들에 대한 오버헤드를 초래할 수 있다.
본 발명의 선행기술문헌은 하기와 같다.
(특허문헌 1) 미국 등록 특허 US6,999,977
(특허문헌 2) 미국 등록 특허 US7,111,023
(특허문헌 3) 미국 등록 특허 US7,657,576
(특허문헌 4) 미국 등록 특허 US7,647,354
(특허문헌 5) 미국 등록 특허 US9,727,624
(특허문헌 6) 미국 등록 특허 US9,442,995
(특허문헌 7) 미국 등록 특허 US8,510,270
(특허문헌 8) 미국 등록 특허 US9,298,878
(특허문헌 9) 미국 등록 특허 US7,461,103
(특허문헌 10) 미국 등록 특허 US7,065,538
(특허문헌 11) 미국 등록 특허 US7,668,878
(특허문헌 12) 미국 등록 특허 US6,832,229
(특허문헌 13) 미국 등록 특허 US8,799,213
(특허문헌 14) 미국 등록 특허 US9,230,002
(특허문헌 15) 미국 등록 특허 US9,009,104
(특허문헌 16) 미국 등록 특허 US6,981,004
(특허문헌 17) 미국 등록 특허 US6,976,022
(특허문헌 18) 미국 등록 특허 US7,908,243
(특허문헌 19) 미국 등록 특허 US9,841,909
(특허문헌 20) 미국 등록 특허 US9,495,252
(특허문헌 21) 미국 등록 특허 US8,676,759
(특허문헌 22) 미국 등록 특허 US9,646,042
(특허문헌 23) 미국 등록 특허 US9,047,392
(특허문헌 24) 미국 등록 특허 US7,831,574
(특허문헌 25) 미국 등록 특허 US8,874,506
(특허문헌 26) 미국 등록 특허 US8,385,657
(특허문헌 27) 미국 공개 특허 US2016-0314147
(특허문헌 28) 미국 공개 특허 US2018-0081924
본 개시내용의 실시예들은 DB의 중단 없이 효율적으로 변경 데이터 캡쳐(CDC)를 구현하기 위한 것이다.
본 개시내용의 실시예들은 타겟 DB에서 메모리를 효율적으로 관리하기 위한 것이다.
본 개시내용의 일 실시예에 따라 인코딩된 명령들을 포함하는 컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램이 개시된다. 상기 컴퓨터 프로그램은 소스(source) 데이터베이스 서버의 하나 이상의 프로세서에 의해 실행되는 경우, 상기 하나 이상의 프로세서로 하여금 변경 데이터 캡쳐(CDC:Change Data Capture)를 위한 방법을 수행하도록 한다. 상기 방법은: 소스 데이터베이스 서버에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 분석함으로써, 상기 트랜잭션과 연관되는 하나 이상의 객체들에 대하여 발생된 복수의 SQL(Structured Query Language) 연산들을 식별하는 단계; 식별된 복수의 SQL 연산들이 발생한 순서에 기반하여, 개별 SQL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력(previous SQL operation history)이 CDC 파일에 존재하는지 여부를 판단하는 단계; CDC 파일에서의 이전 SQL 연산 이력의 존재 여부에 기초하여, 상기 CDC 파일에 기록할 정보를 결정하는 단계; 결정된 정보를 상기 CDC 파일에 기록하는 단계; 및 CDC 파일을 타겟(target) 데이터베이스 서버로 전송할 것을 결정하는 단계를 포함할 수 있다.
본 개시내용의 일 실시예에 따라 변경 데이터 캡쳐(CDC:Change Data Capture)를 구현하기 위한 하나 이상의 프로세서를 포함하는 데이터베이스 서버가 개시된다. 상기 데이터베이스 서버는, 소스 데이터베이스 서버, 또는 소스 데이터베이스 서버와 타겟 데이터베이스 서버 사이에 존재하는 임의의 형태의 에이전트 서버를 포함할 수 있다. 상기 하나 이상의 프로세서는: 소스 데이터베이스 서버에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 분석함으로써, 상기 트랜잭션과 연관되는 하나 이상의 객체들에 대하여 발생된 복수의 SQL(Structured Query Language) 연산들을 식별하는 동작; 식별된 복수의 SQL 연산들이 발생한 순서에 기반하여, 개별 SQL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력(previous SQL operation history)이 CDC 파일에 존재하는지 여부를 판단하는 동작; CDC 파일에서의 이전 SQL 연산 이력의 존재 여부에 기초하여, 상기 CDC 파일에 기록할 정보를 결정하는 동작; 결정된 정보를 상기 CDC 파일에 기록하는 동작; 및 CDC 파일을 타겟(target) 데이터베이스 서버로 전송할 것을 결정하는 동작을 수행할 수 있다.
본 개시내용의 일 실시예에 따라, 인코딩된 명령들을 포함하는 컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램이 개시된다. 상기 컴퓨터 프로그램은 하나 이상의 프로세서에 의해 실행되는 경우, 하나 이상의 프로세서로 하여금 변경 데이터 캡쳐(CDC:Change Data Capture)를 위한 방법을 수행하도록 한다. 상기 방법은: 소스 데이터베이스 서버로부터 CDC 파일을 수신하는 단계; CDC 파일에 기록된 메타 정보를 판독함으로써, 상기 타겟 데이터베이스 서버에 대응되는 메타 정보가 존재하는지 여부를 판단하는 단계; 대응되는 메타 정보가 존재하지 않는 경우, 상기 CDC 파일에 기록된 메타 정보를 메모리에 로딩하는 단계; CDC 파일에 기록된 SQL 연산을 판독하고, 그리고 상기 판독된 SQL 연산과 대응되는 상기 메모리 상에서의 상기 메타 정보를 사용함으로써 상기 SQL 연산과 대응되는 SQL 문(statement)을 생성하는 단계; 및 생성된 SQL 문을 상기 타겟 데이터베이스 서버에 적용시키는 단계를 포함할 수 있다.
본 개시내용의 일 실시예에 따라, 변경 데이터 캡쳐(CDC:Change Data Capture)를 구현하기 위한 하나 이상의 프로세서를 포함하는 데이터베이스 서버가 개시된다. 상기 데이터베이스 서버는, 타겟 데이터베이스 서버, 또는 소스 데이터베이스 서버와 타겟 데이터베이스 서버 사이에 존재하는 임의의 형태의 에이전트 서버를 포함할 수 있다. 상기 하나 이상의 프로세서는: 소스 데이터베이스 서버로부터 CDC 파일을 수신하는 동작; CDC 파일에 기록된 메타 정보를 판독함으로써, 상기 타겟 데이터베이스 서버에 대응되는 메타 정보가 존재하는지 여부를 판단하는 동작; 대응되는 메타 정보가 존재하지 않는 경우, 상기 CDC 파일에 기록된 메타 정보를 메모리에 로딩하는 동작; CDC 파일에 기록된 SQL 연산을 판독하고, 그리고 상기 판독된 SQL 연산과 대응되는 상기 메모리 상에서의 상기 메타 정보를 사용함으로써 상기 SQL 연산과 대응되는 SQL 문(statement)을 생성하는 동작; 및 생성된 SQL 문을 상기 타겟 데이터베이스 서버에 적용시키는 동작을 수행할 수 있다.
본 개시내용의 일 실시예에 따라 DB의 중단 없이 효율적으로 변경 데이터 캡쳐(CDC)가 구현될 수 있다.
본 개시내용의 일 실시예에 따라 타겟 DB에서 메모리가 효율적으로 관리될 수 있다.
다양한 실시예들이 도면을 참조하여 기재될 것이며, 여기서 유사한 참조번호들은 총괄적으로 유사한 구성요소 혹은 유사한 모듈을 지칭하는데 사용된다. 이하의 실시예들에서, 설명의 목적을 위하여, 다수의 특정한 세부사항들이 하나 이상의 실시예들에 대한 총체적 이해를 위해 제시된다. 하지만, 이러한 실시예(들)이 이러한 특정한 세부사항들 없이 실시될 수도 있다. 다른 예시들에서, 공지의 구조들 및 장치들이 하나 이상의 실시예들에 대한 설명을 용이하게 하기 위하여 블록도 형태로 도시된다.
도 1은 본 개시내용의 일 실시예에 따른 데이터베이스 시스템을 예시적으로 도시한다.
도 2는 본 개시내용의 일 실시예에 따른 데이터베이스 시스템에서의 소스 데이터베이스 서버 및 타겟 데이터베이스 서버를 예시적으로 도시한다.
도 3은 본 개시내용의 일 실시예에 따라 소스 데이터베이스 서버(혹은 에이전트 서버)에서 수행되는 CDC 방법을 예시적으로 도시하는 순서도이다.
도 4는 본 개시내용의 일 실시예에 따라 소스 데이터베이스 서버(혹은 에이전트 서버)에서 수행되는 CDC 방법을 예시적으로 도시하는 순서도이다.
도 5는 본 개시내용의 일 실시예에 따라 타겟 데이터베이스 서버(혹은 에이전트 서버)에서 수행되는 CDC 방법을 예시적으로 도시하는 순서도이다.
도 6은 본 개시내용의 일 실시예에 따라 데이터베이스 시스템에서 수행되는 CDC 동작들을 개략적으로 도시한다.
도 7은 본 개시내용의 일 실시예에 따라 데이터베이스 시스템에서 수행되는 CDC 동작들을 개략적으로 도시한다.
도 8은 본 개시내용의 일 실시예에 따라 CDC 솔루션을 구현하기 위한 예시적인 컴퓨팅 장치에 대한 블록도를 도시한다.
다양한 실시예들 및/또는 양상들이 이제 도면들을 참조하여 개시된다. 하기 설명에서는 설명을 목적으로, 하나 이상의 양상들의 전반적 이해를 돕기 위해 다수의 구체적인 세부사항들이 개시된다. 그러나, 이러한 양상(들)은 이러한 구체적인 세부사항들 없이도 실행될 수 있다는 점 또한 본 발명의 기술 분야에서 통상의 지식을 가진 자에게 인식될 수 있을 것이다. 이후의 기재 및 첨부된 도면들은 하나 이상의 양상들의 특정한 예시적인 양상들을 상세하게 기술한다. 하지만, 이러한 양상들은 예시적인 것이고 다양한 양상들의 원리들에서의 다양한 방법들 중 일부가 이용될 수 있으며, 기술되는 설명들은 그러한 양상들 및 그들의 균등물들을 모두 포함하고자 하는 의도이다.
또한, 다양한 양상들 및 특징들이 다수의 디바이스들, 컴포넌트들 및/또는 모듈들 등을 포함할 수 있는 시스템에 의하여 제시될 것이다. 다양한 시스템들이, 추가적인 장치들, 컴포넌트들 및/또는 모듈들 등을 포함할 수 있다는 점 그리고/또는 도면들과 관련하여 논의된 장치들, 컴포넌트들, 모듈들 등 전부를 포함하지 않을 수도 있다는 점 또한 이해되고 인식되어야 한다.
본 명세서에서 사용되는 "실시예", "예", "양상", "예시" 등은 기술되는 임의의 양상 또는 설계가 다른 양상 또는 설계들보다 양호하다거나, 이점이 있는 것으로 해석되지 않을 수도 있다. 아래에서 사용되는 용어들 '컴포넌트', '모듈', '시스템', '인터페이스' 등은 일반적으로 컴퓨터 관련 엔티티(computer-related entity)를 의미하며, 예를 들어, 하드웨어, 하드웨어와 소프트웨어의 조합, 및 소프트웨어를 의미할 수 있다.
더불어, 용어 "또는"은 배타적 "또는"이 아니라 내포적 "또는"을 의미하는 것으로 의도된다. 즉, 달리 특정되지 않거나 문맥상 명확하지 않은 경우에, "X는 A 또는 B를 이용한다"는 자연적인 내포적 치환 중 하나를 의미하는 것으로 의도된다. 즉, X가 A를 이용하거나; X가 B를 이용하거나; 또는 X가 A 및 B 모두를 이용하는 경우, "X는 A 또는 B를 이용한다"가 이들 경우들 어느 것으로도 적용될 수 있다. 또한, 본 명세서에 사용된 "및/또는"이라는 용어는 열거된 관련 아이템들 중 하나 이상의 아이템의 가능한 모든 조합을 지칭하고 포함하는 것으로 이해되어야 한다.
또한, "포함한다" 및/또는 "포함하는"이라는 용어는, 해당 특징 및/또는 구성요소가 존재함을 의미하지만, 하나 이상의 다른 특징, 구성요소 및/또는 이들의 그룹의 존재 또는 추가를 배제하지 않는 것으로 이해되어야 한다. 또한, 달리 특정되지 않거나 단수 형태를 지시하는 것으로 문맥상 명확하지 않은 경우에, 본 명세서와 청구범위에서 단수는 일반적으로 "하나 또는 그 이상"을 의미하는 것으로 해석되어야 한다.
본 명세서에서의 컴퓨터 판독가능 매체는 컴퓨터 시스템에 의해서 판독될 수 있도록 프로그램 및 데이터가 저장되는 모든 종류의 저장 매체를 포함할 수 있다. 본 발명의 일 양상에 따르면, 이러한 매체는 ROM(판독 전용 메모리), RAM(랜덤 액세스 메모리), CD(컴팩트 디스크)-ROM, DVD(디지털 비디오 디스크)-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장장치 등을 포함할 수 있다. 추가적으로, 이러한 매체는 네트워크로 연결된 시스템에 분산되어, 분산 방식으로 컴퓨터가 판독가능한 코드들 및/또는 명령들을 저장할 수도 있다.
본 발명의 실시를 위한 구체적인 내용을 설명하기에 앞서, 본 발명의 기술적 요지와 직접적 관련이 없는 구성에 대해서는 본 발명의 기술적 요지를 흩뜨리지 않는 범위 내에서 생략하였음에 유의하여야 할 것이다. 또한, 본 명세서 및 청구범위에 사용된 용어 또는 단어는 발명자가 자신의 발명을 최선의 방법으로 설명하기 위해 적절한 용어의 개념을 정의할 수 있다는 원칙에 입각하여 본 발명의 기술적 사상에 부합하는 의미와 개념으로 해석되어야 할 것이다.
도 1은 본 발명의 일 실시예에 따른 데이터베이스 시스템(100)에 대한 개략도를 도시한다.
도 1에서 도시되는 바와 같이, 데이터베이스 시스템(100)은 소스 데이터베이스 서버(110), 타겟 데이터베이스 서버(120) 및/또는 에이전트 서버(130)를 포함할 수 있다.
도 1에서 도시되지는 않았지만, 데이터베이스 시스템(100)은 클라이언트를 더 포함할 수 있다. 클라이언트는 데이터베이스 서버들과 통신하기 위한 매커니즘을 갖는 시스템에서의 임의의 형태의 노드(들)를 의미할 수 있다. 예를 들어, 이러한 클라이언트는 PC, 랩탑 컴퓨터, 워크스테이션, 단말 및/또는 네트워크 접속성을 갖는 임의의 전자 디바이스를 포함할 수 있다. 또한, 클라이언트는 에이전트, API(Application Programming Interface) 및 플러그-인(Plug-in) 중 적어도 하나에 의해 구현되는 임의의 서버를 포함할 수도 있다.
본 발명의 일 실시예에서, 클라이언트로부터 발행된 쿼리에 따라서, 소스 데이터베이스 서버(110), 타겟 데이터베이스 서버(120) 및/또는 에이전트 서버(130)의 후술될 동작들이 수행될 수 있다.
데이터베이스 서버들(110 및 120)은, 예를 들어, 마이크로프로세서, 메인프레임 컴퓨터, 디지털 싱글 프로세서, 휴대용 디바이스 및 디바이스 제어기 등과 같은 임의의 타입의 컴퓨터 시스템 또는 컴퓨터 디바이스를 포함할 수 있다. 이러한 데이터베이스 서버들(110 및 120) 각각은, 도시되지는 않았지만, DBMS(Database Management System) 및/또는 영구 저장 매체(persistent storage)를 포함할 수 있다.
본 명세서에서의 소스 데이터베이스 서버(110) 및 타겟 데이터베이스 서버(120)는 데이터베이스 시스템(100)에서의 임의의 형태의 노드(node)들을 의미할 수 있다. 추가적인 실시예로서, 소스 데이터베이스 서버(110) 및 타겟 데이터베이스 서버(120)는 하나의 데이터베이스 서버에 통합되어 관리 및/또는 클러스터링될 수도 있다. 소스 데이터베이스 서버(110) 및 타겟 데이터베이스 서버(120)는 하나의 데이터베이스 서버에 통합되어 서로 연계된 다중 데이터베이스를 구성할 수도 있다.
본 발명의 일 실시예에서, 소스 데이터베이스 서버(110) 및 타겟 데이터베이스 서버(120)는 서로 원격에 위치한 이종의 데이터베이스 서버를 의미할 수도 있다. 더불어, 도 1에서는 2개의 데이터베이스 서버들을 도시하고 있으나, 이보다 많은 데이터베이스 서버들 또한 본 발명의 범위에 포함될 수도 있다.
도 1에서는 도시되지 않았지만, 데이터베이스 서버들(110 및 120)은 버퍼 캐시를 포함하는 하나 이상의 메모리를 포함할 수 있다. 또한, 도 1에서는 도시되지 않았지만, 데이터베이스 서버(110 및 120)는 하나 이상의 프로세서를 포함할 수 있다. 따라서, 데이터베이스 서버 내의 DBMS는 상기 메모리 상에서 상기 프로세서에 의하여 동작될 수 있다.
여기서, 메모리는 동적 램(DRAM, dynamic random access memory), 정적 램(SRAM, static random access memory) 등의 랜덤 액세스 메모리(RAM)와 같은, 프로세서가 직접 접근하는 주된 저장 장치로서 전원이 꺼지면 저장된 정보가 순간적으로 지워지는 휘발성(volatile) 저장 장치를 의미할 수 있지만, 이들로 한정되는 것은 아니다. 이러한 메모리는 프로세서에 의하여 동작 될 수 있다. 메모리는 데이터 값을 포함하는 데이터 테이블 및/또는 트랜잭션에 따른 로그 레코드들을 저장할 수 있다. 예를 들어, 로그 레코드들을 메모리의 별도의 트랜잭션 로그 저장을 담당하는 별도의 구성요소에 저장될 수도 있다. 본 명세서에서의 트랜잭션이란, 통상적으로 정보의 교환이나 데이타베이스 업데이트 등과 같은 일련의 작업들에 대한 연속적인 처리단위를 의미할 수 있다. 이러한 트랜잭션은, 데이타베이스의 무결성(integrity)이 보장되는 상태에서 요청된 작업을 완수하기 위한 작업의 기본 단위를 나타낸다. 본 개시내용에서의 로그 레코드는 리두로그에 대한 레코드를 의미하며, 데이터베이스 내에서의 데이터의 구조 및 조직에 대한 변경내용(예컨대, 테이블, 컬럼(column), 로우(row), 데이터 타입, 인덱스 등에 관련 변경 내용을 식별할 수 있는 데이터 레코드를 포함할 수 있다.
본 개시내용의 일 실시예에서 데이터 테이블의 데이터 값 및/또는 로그 레코드들은 메모리로부터 영구 저장 매체에 기록될 수 있다. 추가적인 양상에서, 메모리는 버퍼 캐시를 포함하며, 상기 버퍼 캐시의 블록에는 이러한 데이터 및/또는 로그 레코드들이 저장될 수 있다. 상기 데이터 및/또는 로그 레코드들은 백그라운드 프로세스에 의하여 영구 저장 매체에 기록될 수 있다.
데이터베이스 서버 내의 영구 저장 매체는, 예를 들어 자기(magnetic) 디스크, 광학(optical) 디스크 및 광자기(magneto-optical) 저장 디바이스뿐만 아니라 플래시 메모리 및/또는 배터리-백업 메모리에 기초한 저장 디바이스와 같은, 임의의 데이터를 지속적으로 할 수 있는 비-휘발성(non-volatile) 저장 매체를 의미한다. 이러한 영구 저장 매체는 다양한 통신 수단을 통하여 데이터베이스 서버들(110 및 120)의 프로세서 및 메모리와 통신할 수 있다. 추가적인 실시예에서, 이러한 영구 저장 매체는 데이터베이스 서버(110 및 120) 외부에 위치하여 데이터베이스 서버(110 및 120)와 통신가능할 수도 있다.
DBMS는 데이터베이스 서버(110 및 120)에서 필요한 데이터를 검색, 삽입, 수정, 삭제 및/또는 로그 레코드 관리 등과 같은 동작들을 수행하는 것을 허용하기 위한 프로그램으로서, 전술한 바와 같이, 데이터베이스 서버(110 및 120)의 메모리에서 프로세서에 의하여 구현될 수 있다.
클라이언트와 데이터베이스 서버들(110 및 120) 또는 데이터베이스 서버들(110 및 120)은 네트워크(미도시)를 통하여 서로 통신할 수 있다. 본 발명의 일 실시예에 따른 네트워크는 공중전화 교환망(PSTN:Public Switiched Telephone Network), xDSL(x Digital Subscriber Line), RADSL(Rate Adaptive DSL), MDSL(Multi Rate DSL), VDSL(Very High Speed DSL), UADSL(Universal Asymmetric DSL), HDSL(High Bit Rate DSL) 및 근거리 통신망(LAN) 등과 같은 다양한 유선 통신 시스템들을 사용할 수 있다.
또한, 본 명세서에서 제시되는 네트워크는 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) 및 다른 시스템들과 같은 다양한 무선 통신 시스템들을 사용할 수 있다. 추가적인 실시예로서, 본 명세서에서의 네트워크는 데이터베이스 링크(dblink)를 포함할 수도 있으며, 이에 따라 데이터베이스 서버들(110, 120)은 이러한 데이터베이스 링크를 통해 서로 통신하여 이로부터 또는 다른 데이터베이스 서버로부터의 데이터/로그 레코드들을 가져올 수도 있다. 본 명세서에서 설명된 기술들은 위에서 언급된 네트워크들뿐만 아니라, 다른 네트워크들에서도 사용될 수 있다.
도 1에서 도시되는 바와 같이, 소스 데이터베이스 서버(110)는 타겟 데이터베이스 서버(120)의 원격에 위치할 수 있다. 또한, 소스 데이터베이스 서버(110) 및 타겟 데이터베이스 서버(120)는 동일 타입의 서버들이거나 또는 서로 호환되지 않는 이기종의(heterogeneous) 데이터베이스 서버를 의미할 수 있다.
추가적으로, 소스 데이터베이스 서버(110)는 임의의 타입의 데이터베이스로서 명령들을 실행 및 저장하기 위한 프로세서 및 메모리를 포함하는 디바이스를 포함할 수 있으나 이로 한정되지는 않는다. 즉, 소스 데이터베이스는 소프트웨어, 펌웨어 및 하드웨어 또는 이들의 조합을 포함할 수도 있다. 소프트웨어는 데이터베이스 테이블, 스키마, 인덱스 및/또는 데이터를 생성, 삭제 및 수정하기 위한 애플리케이션(들)을 포함할 수 있다. 소스 데이터베이스 서버(110)는 클라이언트 또는 다른 컴퓨팅 디바이스로부터의 트랜잭션들을 수신할 수 있으며, 예시적인 트랜잭션들은 소스 데이터베이스 서버(110)에서의 데이터, 테이블 및/또는 인덱스 등을 검색, 추가, 수정 및/또는 삭제하는 것을 포함할 수 있다.
타겟 데이터베이스 서버(120)는 소스 데이터베이스 서버(110)에서 발생된 데이터 변경 내용이 복제 또는 동기화되는 데이터베이스 서버를 의미하며, 전술한 소스 데이터베이스 서버(110)의 특징의 적어도 일부분을 포함할 수 있다. 예를 들어, 타겟 데이터베이스 서버(120)는 소스 데이터베이스 서버(110)의 데이터, 데이터 타입들, 테이블들, 인덱스들 및/또는 로그 레코드들에 대한 복사본을 저장할 수 있다.
본 명세서에서의 로그 레코드는 데이터베이스 내의 데이터의 구조, 조직에 대한 변경내용 및/또는 테이블, 컬럼, 데이터 타입, 인덱스, 데이터 등과 관련된 변경 내용을 식별할 수 있는 데이터 레코드를 의미할 수 있다. 이러한 로그 레코드는 트랜잭션 혹은 연산을 고유하게 식별하기 위한 정보 및/또는 상기 트랜잭션 혹은 연산에 따라 변경된 데이터 레코드를 식별하기 위한 정보를 의미할 수 있다.
본 발명의 일 실시예에서, 에이전트 서버(130)는 소스 데이터베이스 서버(110)와 타겟 데이터베이스 서버(120)간의 CDC를 구현하기 위한 별도의 엔티티를 의미할 수 있다. 따라서, 에이전트 서버(130)는 CDC 특징들을 구현하기 위한 임의의 동작들을 수행할 수 있다. 예를 들어, 에이전트 서버(130)는 본 개시내용에서 소스 데이터베이스 서버(110)로부터 데이터를 수신 및 처리한 다음에, 타겟 데이터베이스 서버(120)로 송신하여, 타겟 데이터베이스 서버(120)에서 변경 데이터가 적용될 수 있도록 허용할 수 있다.
에이전트 서버(130)는 임의의 타입의 서버로서 명령들을 실행 및 저장하기 위한 프로세서 및 메모리를 포함하는 디바이스를 포함할 수 있으나 이로 한정되지는 않는다. 에이전트 서버(130)는 소프트웨어, 펌웨어 및 하드웨어 또는 이들의 조합을 포함할 수도 있다. 예를 들어, 에이전트 서버(130)의 동작들을 구현하는 소프트웨어는 소스 데이터베이스(110) 및/또는 타겟 데이터베이스(120)에 설치될 수 있다. 예를 들어, 에이전트 서버(130)는 임의의 형태의 CDC 모듈로서 동작할 수 있다. 이러한 예시에서, CDC 모듈은 소스 데이터베이스 서버(120) 및/또는 타겟 데이터베이스 서버(130)에 설치되어, 소스 데이터베이스 서버(120)와 타겟 데이터베이스 서버(130) 간의 CDC 특징들이 구현될 수 있도록 허용할 수 있다.
도 1에서 도시되는 에이전트 서버(130)의 기능들은 소스 데이터베이스 서버(110) 및/또는 타겟 데이터베이스 서버(120)에 일부분으로 통합될 수도 있다. 예를 들어, 에이전트 서버(130)의 CDC 기능은 타겟 데이터베이스 서버(120)에 의해 대체될 수 있다.
도 2는 본 개시내용의 일 실시예에 따른 데이터베이스 시스템(100)에서의 소스 데이터베이스 서버(110) 및 타겟 데이터베이스 서버(120)를 예시적으로 도시한다.
도 2에서 도시되는 데이터베이스 서버들(110 및 120)의 컴포넌트들을 예시적인 것이며, 추가적인 컴포넌트들이 존재하거나, 혹은 상기 컴포넌트들 중 일부는 생략되거나 통합될 수도 있다.
도 2에서 도시되는 바와 같이, 소스 데이터베이스 서버(110)는 추출 모듈(210), 기록 모듈(220), 판독 모듈(230), 송수신 모듈(240) 및 저장 모듈(250)을 포함할 수 있다. 전술한 모듈들은 소스 데이터베이스 서버(110)의 하나 이상의 프로세서들이 수행하는 기능들에 대한 집합체를 의미할 수 있다. 또한, 전술한 모듈들에 의해 수행되는 동작들 및 기능들은 하나 이상의 스레드(thread) 혹은 프로세스에 의해 수행될 수 있다.
추출 모듈(210)은 소스 데이터베이스 서버(110)에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 획득할 수 있다. 추출 모듈(210)은 소스 데이터베이스 서버(110)로부터 리두 로그를 수신할 수 있거나 혹은 소스 데이터베이스 서버(110)에 리두 로그에 액세스할 수 있다. 클라이언트에 의해 개시된 트랜잭션에 따라 소스 데이터베이스 서버(110)에서 데이터, 테이블 및/또는 인덱스 등에 대한 변경이 발생되는 경우, 해당 트랜잭션에 대한 로그 레코드가 소스 데이터베이스 서버(110)에 기록될 수 있다. 이러한 경우, 추출 모듈(210)은 소스 데이터베이스 서버(110)에서의 로그 버퍼 및/또는 로그 파일 등에 기록된 트랜잭션에 대한 리두 로그를 확인 및 분석함으로써, 변경 데이터에 대한 로그 레코드를 획득할 수 있다. 이러한 경우, 추출 모듈(210)은 리두 로그를 분석함으로써 변경된 데이터만을 추출할 수 있다. 추출 모듈(210)은 하나 이상의 규칙에 기초하여 혹은 임의의 형태의 딥러닝 알고리즘에 기초하여, 추출된 로그 레코드를 분석할 수 있다.
추가적으로, 추출 모듈(210)은 로그 레코드들의 발생 시점에 따른 순서에 기초하여 정렬시킬 수 있다. 예를 들어, 추출 모듈(210)은 SCN(System Change Number)에 기초하여 로그 레코드들을 정렬시킬 수 있다. 즉, 기록 모듈(210)는 소스 데이터베이스 서버(110)의 로그 레코드들을 시계열적으로 정렬할 수 있다.
추출 모듈(210)은 트랜잭션과 연관되는 하나 이상의 객체들에 대해서 발생된 복수의 SQL 연산들을 식별할 수 있다. 본 명세서에서 SQL 연산은 SQL로 작성된 임의의 형태의 연산을 의미할 수 있다. SQL 연산은 예를 들어, DML(Data Manipulation Language) 연산, DDL(Data Definition Language) 연산 및/또는 DCL(Data Control Language) 연산을 포함할 수 있다. 추가적으로, 추출 모듈(210)은 식별된 SQL 연산들을 발생한 순서대로 정리하여 기록 모듈(220)에 전달할 수 있다.
기록 모듈(220)은 로그 레코드들의 발생 시점에 따른 순서에 기초하여 정렬시킬 수 있다. 예를 들어, 기록 모듈(220)은 SCN(System Change Number)에 기초하여 로그 레코드들을 정렬시킬 수 있다. 즉, 기록 모듈(220)는 소스 데이터베이스 서버(110)의 로그 레코드들을 시계열적으로 정렬할 수 있다. 따라서, SCN이 앞선 로그 레코드는 그 보다 후속하는 SCN을 가진 로그 레코드 보다 먼저 기록될 수 있다. 기록 모듈(220)은 식별된 복수의 SQL 연산들이 발생한 순서에 기초하여, 개별 SQL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력이 CDC 파일에 존재하는지 여부를 판단할 수 있다. 본 명세서에서 CDC 파일은 소스 데이터베이스 서버(110)로부터 타겟 데이터베이스 서버(120)로 전달되는, 트랜잭션(연산) 순서대로 정리된 파일을 의미할 수 있다. 기록 모듈(220)은 CDC 파일에서의 이전 SQL 연산 이력의 존재 여부에 기초하여, 상기 CDC 파일에 기록할 정보를 결정하고 그리고 결정된 정보를 CDC 파일에 기록할 수 있다.
예를 들어, 기록 모듈(220)은 SQL 연산에 대응되는 객체(예컨대, 테이블)에 대한 메타 정보가 CDC 파일에 존재하는지 여부에 기초하여, 이전 SQL 연산 이력이 CDC 파일에 존재하는지 여부를 판단할 수 있다. 여기에서의 메타 정보는, 테이블 유저 정보, 테이블 이름 정보, 컬럼 이름 정보, 컬럼 순서 정보 및 컬럼 타입 정보 중 적어도 하나를 포함할 수 있다. 또한, 기록 모듈(220)은 SQL 연산에 대응되는 객체에 대해서 이전에 DML 연산 혹은 DDL 연산이 수행되었는지 여부에 기초하여, 상기 이전 SQL 연산 이력이 상기 CDC 파일에 존재하는지 여부를 판단할 수 있다. 전술한 기록 모듈(220)의 이전 SQL 연산 이력에 대한 판단은, 트랜잭션과 연관되는 객체들 전체에 대해서 상기 SQL 연산이 발생한 순서대로(예컨대, SCN의 시간적 선후 관계에 따라서) 수행될 수 있다.
기록 모듈(220)은 CDC 파일에서의 이전 SQL 연산 이력이 존재하지 않는 경우, 해당 객체에 대한 DD(Data Dictionary) 정보를 사용하여 해당 객체에 대한 메타 정보를 생성하고, 그리고 상기 CDC 파일에서의 이전 SQL 연산 이력이 존재하는 경우, 상기 해당 객체에 대한 메타 정보를 생성하지 않을 것을 결정할 수 있다. 또한, 기록 모듈(220)은 해당 객체에 대한 메타 정보가 생성된 경우, 상기 해당 객체와 관련된 SQL 연산 및 상기 메타 정보를 상기 CDC 파일에 기록할 것을 결정하고, 그리고 상기 해당 객체에 대한 메타 정보가 생성되지 않은 경우, 상기 해당 객체와 관련된 SQL 연산을 상기 CDC 파일에 기록할 것을 결정할 수 있다.
판독 모듈(230)은 CDC 파일을 판독하여 CDC 파일을 타겟(target) 데이터베이스 서버로 전송하는 것을 허용하기 위하여 판독된 CDC 파일 혹은 CDC 파일에 기록된 정보를 송수신 모듈(240)로 전달할 수 있다. 판독 모듈(230)은 CDC 파일 또는 CDC 파일에 기록된 정보가 타겟 데이터베이스 서버(120)에 적합한 포맷으로 변환할 수도 있다.
송수신 모듈(240)은 데이터베이스 서버들(110 및 120)의 통신 기능 그리고/또는 클라이언트와의 통신 기능을 제공할 수 있다. 예를 들어, 송수신 모듈(240)은 소스 데이터베이스 서버(110)의 외부에 위치하는 경우, 추출된 로그 레코드들을 소스 데이터베이스 서버(110)로부터 수신할 수 있다. 송수신 모듈(240)은 임의의 네트워크 및/또는 데이터베이스 링크를 이용하여 데이터베이스 서버들(110 및 120) 간의 통신을 허용할 수 있다. 송수신 모듈(240)은 클라이언트로부터의 입력을 수신할 수 있다. 예를 들어, 송수신 모듈(240)은 클라이언트로부터 데이터 저장, 변경 및 조회 그리고 인덱스 빌드, 변경 및 조회와 관련된 요청을 수신할 수 있다. 추가적으로, 송수신 모듈(240)은 데이터베이스 서버로 프로시저를 호출하는 방식으로 데이터베이스 서버들 간의 정보 전달을 허용할 수 있다. 또한, 송수신 모듈(240)은 데이터베이스 복제와 관련하여 데이터베이스 서버들 간에 전달되는 임의의 데이터/정보를 송수신하는 기능을 제공할 수 있다.
송수신 모듈(240)은 전달받은 CDC 파일 혹은 CDC 파일에 기록된 정보를 타겟 데이터베이스 서버(120)로 송신할 수 있다. 송수신 모듈(240)은 CDC 파일 또는 CDC 파일에 기록된 정보가 타겟 데이터베이스 서버(120)에 적합한 포맷으로 변환하고 변환된 포맷을 타겟 데이터베이스 서버(120)로 송신할 수도 있다.
저장 모듈(250)은 추출된 로그 레코드를 저장하는 등과 같이 본 개시내용의 실시예들에 따른 CDC 특징을 수행하는 것과 관련되어 저장되는 임의의 데이터를 저장할 수 있다. 저장 모듈(250)은 DBMS 및/또는 영구저장매체에 포함될 수 있다. 추가적으로, 저장 모듈(250)은 업데이트 요청과 관련된 저장을 수행할 수 있다. 저장 모듈(250)은 데이터 테이블 및 인덱스 테이블 등을 저장할 것을 결정할 수 있다. 저장 모듈(250)은 데이터에 대해서 데이터 테이블 상에서의 저장 위치 그리고 영구저장매체 상에서의 저장 위치를 결정할 수도 있다.
도 2에서 도시되는 바와 같이, 타겟 데이터베이스 서버(120)는 송수신 모듈(310), 기록 모듈(320), 판독 모듈(330), 변경 및 반영 모듈(340) 및 저장 모듈(350)을 포함할 수 있다.
송수신 모듈(310)은 소스 데이터베이스 서버(110) 혹은 에이전트 서버(130)로부터 CDC 파일 혹은 CDC 파일에 저장된 정보를 수신할 수 있다. 송수신 모듈(310)은 전술한 소스 데이터베이스 서버(110)의 송수신 모듈(240)과 동일한 형태의 통신 기능을 제공할 수 있다.
기록 모듈(320)은 소스 데이터베이스 서버(110)로부터 수신된 CDC 파일 혹은 CDC 파일에 대한 정보를 타겟 데이터베이스 서버(120)의 CDC 파일에 기록할 수 있다. 예를 들어, 기록 모듈(320)은 소스 데이터베이스 서버(110)로부터 수신된 CDC 파일과 동일한 파일을 그대로 자신의 CDC 파일로 사용할 것을 결정하거나 또는 CDC 파일에 대한 정보와 동일한 정보를 CDC 파일에 기록할 수 있다. 추가적인 실시예에서, 소스 데이터베이스 서버(110)로부터 수신된 CDC 파일을 그대로 채용하는 경우, 타겟 데이터베이스 서버(120)에서의 기록 모듈(320)은 송수신 모듈(310)로 대체될 수도 있다.
판독 모듈(330)은 타겟 데이터베이스 서버(120)에 존재하는 CDC 파일을 판독할 수 있다. 판독 모듈(330)은 판독된 CDC 파일을 변경 및 반영 모듈(340)로 전달할 수 있다. 판독 모듈(330)은 CDC 파일을 타겟 데이터베이스 서버(120)의 형식에 맞도록 수정하여 변경 및 반영 모듈(340)로 전달할 수도 있다. 판독 모듈(330)은 소스 데이터베이스 서버(110)에 의해 기록된 순서대로 CDC 파일을 판독할 수 있다.
추가적으로, 판독 모듈(330)은 판독된 CDC 파일에 기초하여, 타겟 데이터베이스 서버(120)에서 변경 및 반영되어야 할 데이터를 결정할 수도 있다. 이러한 경우, 판독 모듈(330)은 타겟 데이터베이스 서버(120)에 반영되어 있는 데이터와 판독한 CDC 파일에 포함된 데이터를 비교하는 동작을 수행할 수 있다. 이에 따라 판독 모듈(330)은 변경 및 반영 모듈(340)이 타겟 데이터베이스 서버(120)로 최소한의 데이터만을 반영할 수 있도록 제어할 수 있다.
추가적으로, 판독 모듈(330)은 CDC 파일에 기록된 메타 정보를 판독함으로써, 타겟 데이터베이스 서버(120)에 대응되는 메타 정보가 존재하는지 여부를 판단할 수도 있다.
변경 및 반영 모듈(340)은 객체에 대한 메타 정보가 CDC 파일에 기록되었는지 여부를 확인할 수 있다. 변경 및 반영 모듈(340)은 CDC 파일에 기록된 메타 정보를 판독함으로써, 타겟 데이터베이스 서버(120)에 대응되는 메타 정보가 존재하는지 여부를 판단할 수 있다. 변경 및 반영 모듈(340)은 메타 정보가 존재하지 않는 경우 메모리 상에 메타 정보를 로딩하고 그리고 메타 정보가 존재하는 경우 존재하는 메타 정보를 그대로 사용할 수 있다. 즉, 변경 및 반영 모듈(340)은 대응되는 메타 정보가 타겟 데이터베이스 서버(120)의 메모리에 로딩되어 있는지 여부에 기초하여 메타 정보의 로딩 여부를 결정하며, 그리고 대응되는 메타 정보가 존재하는 경우, CDC 파일에 기록된 메타 정보를 메모리에 로딩하지 않고 타겟 데이터베이스 서버(120)의 로딩되어 있는 상기 대응되는 메타 정보를 사용할 것을 결정할 수 있다.
변경 및 반영 모듈(340)은 CDC 파일에 기록된 SQL 연산을 판독하고, 그리고 상기 판독된 SQL 연산과 대응되는 메모리 상에서의 메타 정보를 사용함으로써 상기 SQL 연산과 대응되는 SQL 문(statement)을 생성할 수 있다. 또한, 변경 및 반영 모듈(340)은 상기 생성된 SQL 문을 타겟 데이터베이스 서버(120)에 적용시킴으로써, 타겟 데이터베이스 서버(120)에 소스 데이터베이스 서버(110)에서의 변경 데이터가 최종적으로 반영될 수 있도록 허용할 수 있다.
예를 들어, 변경 및 반영 모듈(340)은 전달받은 CDC 파일에서 최초로 메타 데이터를 인식하고 해당 메타 데이터를 메모리에 로딩시킨 후, 그 다음 SQL 연산을 CDC 파일에서 인식한 뒤 로딩된 메타 데이터를 이용하여 해당 SQL 연산에 대한 SQL 문을 생성할 수 있다. 생성된 SQL 문을 타겟 데이터베이스 서버(120)에 반영한 이후, 변경 및 반영 모듈(340)은 해당 CDC 파일에서 트랜잭션에 대한 commit을 인식하고 commit을 타겟 데이터베이스 서버(120)에 반영할 수 있다.
도 3은 본 개시내용의 일 실시예에 따라 소스 데이터베이스 서버(혹은 에이전트 서버)에서 수행되는 CDC 방법을 예시적으로 도시하는 순서도이다.
도 3에서 도시되는 단계들은 예시적인 것이며, 추가적인 단계가 존재할 수 있거나 혹은 해당 단계들 중 일부가 생략될 수도 있다. 도 3에서 도시되는 단계들은 소스 데이터베이스 서버(110) 또는 에이전트 서버(130)에서 수행될 수 있다. 설명의 편의를 위해, 이하에서는 소스 데이터베이스 서버(110)에서 수행되는 것을 가정하여 설명하기로 한다.
소스 데이터베이스 서버(110)는, 소스 데이터베이스 서버(110)에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 분석함으로써, 트랜잭션과 연관되는 하나 이상의 객체들에 대해 발생된 SQL 연산들을 식별할 수 있다(410). 클라이언트에 의해 개시된 트랜잭션에 따라 소스 데이터베이스 서버(110)에서 데이터, 테이블 및/또는 인덱스에 대한 변경이 발생되는 경우, 해당 트랜잭션에 대한 로그 레코드가 소스 데이터베이스 서버(110)에 기록될 수 있다. 이러한 경우, 소스 데이터베이스 서버(110)는 소스 데이터베이스 서버(110)에서의 로그 버퍼 및/또는 로그 파일에 기록된 로그 레코드를 분석함으로써 변경 데이터를 추출할 수 있다. 예를 들어, 소스 데이터베이스 서버(110)는 소스 테이블에서 DML이 발생된 경우 가장 최근에 획득/추출한 변경 데이터 이후 신규 변경된 데이터를 변경 데이터로서 추출할 수 있다. 다른 예시로, 소스 데이터베이스 서버(110)는 소스 테이블에 대한 DDL이 발생된 경우, 해당 테이블에 대한 DDL을 변경 데이터로 인식하여, 타겟 데이터베이스 서버(120)에 반영되어야 하는 변경 데이터로서 추출할 수 있다. 추가적으로, 소스 데이터베이스 서버(110)는 변경 데이터들의 SCN 값을 기초로 하여 변경 데이터들을 시계열적으로 정렬할 수도 있다.
소스 데이터베이스 서버(110)는, 식별된 복수의 SQL 연산들이 발생한 순서에 기반하여, 개별 SQL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력이 CDC 파일에 존재하는지 여부를 판단할 수 있다(420). 그리고나서, 소스 데이터베이스 서버(110)는, CDC 파일에서의 이전 SQL 연산 이력의 존재 여부에 기초하여, 상기 CDC 파일에 기록할 정보를 결정할 수 있다(430). 예를 들어, 소스 데이터베이스 서버(110)가 제 1 DB 객체에 대한 연산들을 나타내는 변경 데이터를 추출한 경우, 소스 데이터베이스 서버(110)는 기존에 제 1 DB 객체에 대하여 이전에 DML 혹은 DDL 연산이 수행되었는지 여부를 판단할 수 있다. 이러한 예시에서, 소스 데이터베이스 서버(110)는 DML 혹은 DDL 연산이 상기 제 1 DB 객체에 대해서 이전에 수행되지 않았다면, 메모리로부터 상기 제 1 DB 객체에 대한 메타 정보(예컨대, DD(Data Dictionary) 정보)를 받아올 수 있다. 소스 데이터베이스 서버(110)는 제 1 DB 객체에 대한 DD 정보를 사용하여 제 1 DB 객체에 대한 메타 정보를 생성할 수 있다. 소스 데이터베이스 서버(110)는 DML 혹은 DDL 연산이 상기 제 1 DB 객체에 대해서 이전에 수행되었다면, 제 1 DB 객체 대한 메타 정보가 존재할 것이기 때문에 메타 정보를 추가로 생성하지 않을 것이다. 본 개시내용에서, 예를 들어, 메타 정보는 테이블 유저 정보, 테이블 이름 정보, 컬럼 이름 정보, 컬럼 순서 정보 및 컬럼 타입 정보 중 적어도 하나를 포함할 수 있다. 일 실시예에서, 소스 데이터베이스 서버(110)는, 특정 트랜잭션과 연관되는 객체들 전체에 대해서 SQL 연산이 발생한 순서대로, 해당 SQL 연산의 대상이 되는 객체 각각에 대한 이전 SQL 연산 이력이 CDC 파일에 존재하는지 여부를 판단할 수 있다.
소스 데이터베이스 서버(110)는 결정된 정보를 CDC 파일에 기록할 수 있다(440). 단계 430에서는 메타 정보를 생성하여 생성된 메타 정보가 CDC 파일에 기록될지 여부가 결정될 수 있다. 단계 440에서는, 소스 데이터베이스 서버(110)가 메타 정보와 SQL 연산 정보를 모두 CDC 파일에 기록하거나, 혹은 SQL 연산 정보만을 CDC 파일에 기록할 수 있다. 일 실시예에서, 소스 데이터베이스 서버(110)는 메타 정보 및 SQL 연산 정보를 CDC 파일에 기록하는데 있어서, 해당 객체에 대한 메타 정보를 SQL 연산 정보보다 CDC 파일에서의 앞 부분에 기록할 수 있다. 또한, 본 개시내용의 일 실시예에 따라서, 소스 데이터베이스 서버(110)는 제 1 트랜잭션이 제 2 트랜잭션 보다 먼저 커밋된 경우, 상기 제 1 트랜잭션에 포함된 SQL 연산을 상기 제 2 트랜잭션에 포함된 SQL 연산 보다 CDC 파일에서의 앞 부분에 기록할 수 있다. 전술한 기록 규칙들에 의해서, 소스 데이터베이스 서버(110)와 타겟 데이터베이스 서버(120)는 단일의 파일에 메타 정보 및 SQL 연산 정보를 모두 기록하면서도 효율적으로 CDC를 구현할 수 있다.
전술한 기록 규칙들에 따라 기록되는 경우, 타겟 데이터베이스 서버(120)에서 전달 받은 CDC 파일을 판독하고 해당 파일을 타겟 데이터베이스 서버(120)에 적용할 때, 특정 객체에 대한 메타 정보를 먼저 판독하고난 뒤, 해당 메타 정보와 관련된 SQL 연산 정보에 대응되는 SQL 문을 해당 메타 정보를 이용하여 용이하게 작성할 수 있게 된다.
전술한 바와 같이, 본 개시내용의 일 실시예에 따라서, SQL 연산 및 메타 정보가 단일의 CDC 파일에 함께 기록될 수 있기 때문에, 메타 정보만을 따로 관리하는 별도의 파일이 존재하는 실시예에 비해서, 효율적인 방식으로 CDC를 구현할 수 있다. 예를 들어, CDC 파일에는 SQL 연산 정보만을 기록하고 메타 정보를 기록 및 관리하는 별도의 파일이 존재하는 실시예의 경우, 메타 정보를 기록하는 파일에 모든 객체에 대한 메타 정보가 필수적으로 저장되어 있어야 한다. 나아가, 메타 정보만을 따로 관리하는 경우에는 DDL이 발생하는 경우, 메타 정보의 수정이 이루어져야 하기 때문에, 일명 "Stop The World"라 지칭될 수 있는 데이터베이스 서버에서의 작동 중단이 발생될 수 밖에 없다. 이러한 경우, 타겟 데이터베이스 서버(120)의 입장에서는 메타 정보가 메타 파일로 관리되기 때문에, 모든 객체들에 대한 메타 정보를 저장하는 메타 파일을 자신의 메모리에 로딩시켜놓아야 한다. 따라서, 이러한 실시예에 따르면 메모리의 사용량이 극대화된다는 단점이 존재한다. 하지만, 본 개시내용의 일 실시예에 따라서 메타 정보 및 SQL 연산 정보를 하나의 파일로 관리하면, 소스 데이터베이스 서버(110)와 타겟 데이터베이스 서버(120) 간에 메모리 사용량을 줄이면서 CDC를 구현하는데 있어서 데이터 레이턴시 또한 최소화시킬 수 있게 된다. 본 개시내용의 일 실시예에 따르면, 하나의 CDC 파일에 DML 혹은 DDL이 발생한 테이블에 대한 메타 정보만을 기록해 놓기 때문에, 메모리 사용량이 획기적으로 줄어들 수 있게 된다. 더불어, 본 개시내용의 일 실시예에 따르면, 특정 테이블에 대한 메타 데이터 단위로 메모리 로딩을 수행하며, 그리고 상기 특정 테이블에 대한 메타 데이터가 메모리에 로딩이 된 다음에 해당 특정 테이블에 대한 SQL 연산을 기록하기 때문에, 데이터베이스 서버에서 CDC를 구현하는데 있어서 성능 저하의 요소를 제거시킬 수 있다.
소스 데이터베이스 서버(110)는 CDC 파일을 타겟 데이터베이스 서버(120)로 전송할 것을 결정할 수 있다(450). 소스 데이터베이스 서버(110)와 타겟 데이터베이스 서버(120) 간의 통신은, 임의의 형태의 통신 네트워크 및/또는 임의의 형태의 dblink에 의해 수행될 수 있다.
도 4는 본 개시내용의 일 실시예에 따라 소스 데이터베이스 서버(혹은 에이전트 서버)에서 수행되는 CDC 방법을 예시적으로 도시하는 순서도이다.
도 4에서 도시되는 단계들은 예시적인 것이며, 추가적인 단계가 존재할 수 있거나 혹은 해당 단계들 중 일부가 생략될 수도 있다. 도 4에서 도시되는 단계들은 소스 데이터베이스 서버(110) 또는 에이전트 서버(130)에서 수행될 수 있다. 설명의 편의를 위해, 이하에서는 소스 데이터베이스 서버(110)에서 수행되는 것을 가정하여 설명하기로 한다.
도 4는 DML 연산이 이루어진 경우에 대한 실시예들 및 DDL 연산이 이루어진 경우에 대한 실시예들을 예시적으로 도시한다.
도 4에서 도시되는 바와 같이, 소스 데이터베이스 서버(110)는 소스 데이터베이스 서버(110)에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 분석함으로써 트랜잭션과 연관되는 하나 이상의 객체들에 대해 발생된 SQL 연산들을 식별할 수 있다(510). 클라이언트에 의해 개시된 트랜잭션에 따라 소스 데이터베이스 서버(110)에서 데이터, 테이블 및/또는 인덱스에 대한 변경이 발생되는 경우, 해당 트랜잭션에 대한 로그 레코드가 소스 데이터베이스 서버(110)에 기록될 수 있다. 이러한 경우, 소스 데이터베이스 서버(110)는 소스 데이터베이스 서버(110)에서의 로그 버퍼 및/또는 로그 파일에 기록된 로그 레코드를 분석함으로써 변경 데이터를 추출할 수 있다. 예를 들어, 소스 데이터베이스 서버(110)는 소스 테이블에서 DML이 발생된 경우 가장 최근에 획득/추출한 변경 데이터 이후 신규 변경된 데이터를 변경 데이터로서 추출할 수 있다. 다른 예시로, 소스 데이터베이스 서버(110)는 소스 테이블에 대한 DDL이 발생된 경우, 해당 테이블에 대한 DDL을 변경 데이터로 인식하여, 타겟 데이터베이스 서버(120)에 반영되어야 하는 변경 데이터로서 추출할 수 있다. 추가적으로, 소스 데이터베이스 서버(110)는 변경 데이터들의 SCN 값을 기초로 하여 변경 데이터들을 시계열적으로 정렬할 수도 있다.
소스 데이터베이스 서버(110)는 식별된 복수의 SQL 연산들 각각에 대한 타입을 결정할 수 있다(520). 예를 들어, 소스 데이터베이스 서버(110)는 식별된 복수의 SQL 연산들 각각이 DML 연산이지 또는 DDL 연산인지를 결정할 수 있다. 전술한 바와 같이, SQL 연산의 타입에 따라서, CDC 파일에 정보를 기록하는 방식이 상이해질 수 있다.
SQL 연산에 대한 타입이 DML 연산인 것으로 결정된 경우, 단계 530에서, 소스 데이터베이스 서버(110)는 DML 연산과 대응되는 객체에 대한 이전 SQL 연산 이력이 존재하는지 여부에 대한 판단이 필요하다고 결정할 수 있다(530). 그리고나서, 소스 데이터베이스 서버(110)는 CDC 파일에서의 이전 SQL 연산 이력이 존재하는지 여부를 판단할 수 있다.
이전 SQL 연산 이력이 CDC 파일에서 존재한다고 결정된 경우, 소스 데이터베이스 서버(110)는 해당 객체에 대한 DD 정보를 사용하여 해당 객체에 대한 메타 정보를 생성할 수 있다(550). 이전 SQL 연산 이력이 CDC 파일에 존재하지 않는다고 결정된 경우, 소스 데이터베이스 서버(110)는 해당 객체에 대한 메타 정보를 생성하지 않고 기존에 생성된 메타 정보를 이용할 것을 결정할 수 있다(550).
그리고나서, 소스 데이터베이스 서버(110)는 해당 객체에 대한 메타 정보가 생성된 경우 해당 객체와 관련된 SQL 연산 및 생성된 메타 정보를 단일의 CDC 파일에 기록할 것을 결정할 수 있다(560). 또한, 소스 데이터베이스 서버(110)는 해당 객체에 대한 메타 정보의 생성이 필요하지 않다고 판단한 경우, SQL 연산을 상기 단일의 CDC 파일에 기록할 것을 결정할 수 있다.
그리고나서, 소스 데이터베이스 서버(110)는 CDC 파일을 타겟 데이터베이스 서버(120)로 전송할 것을 결정할 수 있다(570).
단계 520으로 되돌아가서, 식별된 복수의 SQL 연산에 대한 타입이 DDL 타입으로 결정되는 경우, DDL 연산의 특성에 따라서, 해당 객체에 대해서 새롭게 DD 정보가 인입된 DDL 연산에 따라 수정되어야 한다. 따라서, 소스 데이터베이스 서버(110)는 SQL 연산의 타입이 DDL 타입으로 결정된 경우, DDL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력이 CDC 파일에 존재하는지 여부를 판단하지 않을 것을 결정할 수 있다(540). 그리고나서, 소스 데이터베이스 서버(110)는 인입된 DDL 연산에 기초하여, DDL 연산에 대응되는 객체에 대한 메타 정보를 생성하고 그리고 생성된 메타 정보를 CDC 파일에 기록할 것을 결정할 수 있다(540). 일 실시예에서, DDL 연산에 대응되는 메타 정보는, CDC 파일에서 DDL 연산 이전에 수행된 다른 SQL 연산들의 기록 위치 보다 후속된 위치에 기록될 수 있다. 그리고나서, 소스 데이터베이스 서버(110)는 정보가 기록된 CDC 파일을 타겟 데이터베이스 서버(120)로 전송할 것을 결정할 수 있다(570).
도 5는 본 개시내용의 일 실시예에 따라 타겟 데이터베이스 서버(120)(혹은 에이전트 서버(130))에서 수행되는 CDC 방법을 예시적으로 도시하는 순서도이다.
도 5에서 도시되는 단계들은 예시적인 것이며, 추가적인 단계가 존재할 수 있거나 혹은 해당 단계들 중 일부가 생략될 수도 있다. 도 5에서 도시되는 단계들은 타겟 데이터베이스 서버(120) 또는 에이전트 서버(130)에서 수행될 수 있다. 설명의 편의를 위해, 이하에서는 타겟 데이터베이스 서버(120)에서 수행되는 것을 가정하여 설명하기로 한다.
도 5에서 도시되는 바와 같이, 타겟 데이터베이스 서버(120)는 소스 데이터베이스 서버(110)로부터 CDC 파일을 수신할 수 있다(1010). 타겟 데이터베이스 서버(120)는 소스 데이터베이스 서버(110)에 의해 생성된 CDC 파일을 수신하여, 타겟 데이터베이스 서버(120)에 적용시킬 수 있다. 소스 데이터베이스 서버(110)와 타겟 데이터베이스 서버(120) 간의 통신은, 임의의 형태의 통신 네트워크 및/또는 임의의 형태의 dblink에 의해 수행될 수 있다.
타겟 데이터베이스 서버(120)는 수신된 CDC 파일에 기록된 메타 정보를 판독함으로써, 타겟 데이터베이스 서버(120)에 대응되는 메타 정보가 메모리에 존재하는지 여부를 판단할 수 있다(1020). CDC 파일은, 소스 데이터베이스 서버(110)에 의해 기록된 순서대로 타겟 데이터베이스 서버(120)에서 판독될 수 있다. 따라서, 타겟 데이터베이스 서버(120)는 소스 데이터베이스 서버(110)에서 사전결정된 기록 규칙에 따라 기록된 CDC 파일을 그 기록 순서대로 판독하고 그리고 판독된 순서대로 대응되는 동작들을 수행함으로써, 메모리의 사용량을 줄일 수 있을 뿐만 아니라 레이턴시 없이 CDC 동작이 수행될 수 있다.
타겟 데이터베이스 서버(120)는, 대응되는 메타 정보가 존재하지 않는 경우, 상기 CDC 파일에 기록된 메타 정보를 메모리에 로딩할 수 있다(1030). 또한, 타겟 데이터베이스 서버(120)는 대응되는 메타 정보가 존재하는 경우, 상기 CDC 파일에 기록된 메타 정보를 새롭게 로딩하지 않고, 기존에 존재하는 메타 정보를 사용할 것을 결정할 수 있다(1030). 예를 들어, 타겟 데이터베이스 서버(120)의 메모리에 특정 테이블에 대한 메타 정보가 사전에 로딩된 경우, 새롭게 메모리에 메타 정보를 로딩할 필요가 없기 때문에, 기존 로딩된 메타 정보를 이용하여 타겟 데이터베이스 서버(120)로의 변경 데이터 반영 동작이 수행될 수 있다.
타겟 데이터베이스 서버(120)는 CDC 파일에 기록된 SQL 연산을 순서대로 판독하고, 그리고 상기 판독된 SQL 연산과 대응되는 상기 메모리 상에서의 상기 메타 정보를 사용함으로써, SQL 연산과 대응되는 SQL 문을 생성할 수 있다(1040). 타겟 데이터베이스 서버(120)에 의해 생성되는 SQL 문은 소스 데이터베이스 서버(110)에서 수행한 SQL 연산을 발생시키기 위한 SQL 문을 의미할 수 있다. 타겟 데이터베이스 서버(120)는 CDC 파일에 기록된 SQL 연산 정보 및 메타 정보를 사용하여, 소스 데이터베이스 서버(110)에서 수행한 SQL 연산과 동일한 SQL 연산을 수행함으로써 자신의 DB에 변경 데이터를 자동적으로 반영시킬 수 있다.
그리고나서, 타겟 데이터베이스 서버(120)는 생성된 SQL 문을 상기 타겟 데이터베이스 서버에 적용시킬 수 있다. 전술한 방식을 통해, 자동적으로 소스 데이터베이스 서버(110)에서 수행된 SQL 연산에 대응되는 변경 데이터가 타겟 데이터베이스 서버(120)에 반영될 수 있다.
전술한 바와 같이, 타겟 데이터베이스 서버(120)가 자신의 DB에 변경 데이터를 반영할 때 사용하는 CDC 파일에는, 소스 데이터베이스 서버(110)의 객체들 중 SQL 연산이 발생한 객체에 대한 메타 정보가 기록될 수 있다. 이러한 방식으로, 타겟 데이터베이스 서버(120)는 자신의 메모리에 모든 객체들에 대한 메타 정보를 로딩할 필요가 없으며, 소스 데이터베이스 서버(110)에서의 변경 데이터와 관련되는 객체들에 대한 메타 정보만을 메모리에 로딩하기 때문에, 데이터베이스 서버 내에서의 메모리 사용이 상당히 줄어들 수 있게 된다.
도 6은 본 개시내용의 일 실시예에 따라 데이터베이스 시스템에서 수행되는 CDC 동작들을 개략적으로 도시한다. 도 6에서는 소스 데이터베이스 서버(110)와 타겟 데이터베이스 서버(120) 간에 수행되는 동작들이 예시적으로 표현된다.
도 6에서 도시되는 바와 같이, 소스 데이터베이스 서버(110)는 소스 DBMS(610) 및 소스 프로세서(620)를 포함할 수 있다. 이러한 소스 DBMS(610)는 소스 데이터베이스 서버(110)의 메모리 상에서 소스 프로세서(620)에 의해 동작될 수 있다.
여기서, 메모리는 동적 램(DRAM, dynamic random access memory), 정적 램(SRAM, static random access memory) 등의 랜덤 액세스 메모리(RAM)와 같은, 프로세서가 직접 접근하는 주된 저장 장치로서 전원이 꺼지면 저장된 정보가 순간적으로 지워지는 휘발성(volatile) 저장 장치를 의미할 수 있지만, 이들로 한정되는 것은 아니다. 이러한 메모리는 전술한 바와 같이 프로세서에 의하여 동작 될 수 있다. 메모리는 변경 데이터 등과 같은 임의의 형태의 데이터를 저장할 수 있다. 또는 메모리는 데이터 값을 포함하는 데이터 테이블(data table) 등을 저장할 수 있다. 본 발명의 일 실시예에서 변경 데이터 및/또는 상기 데이터 테이블의 데이터 값은 메모리로부터 영구 저장 매체에 기록될 수 있다. 추가적인 양상에서, 메모리는 버퍼 캐시를 포함하며, 상기 버퍼 캐시의 데이터 블록에는 데이터가 저장될 수 있다. 상기 데이터는 백그라운드 프로세스에 의하여 영구 저장 매체에 기록될 수 있다.
본 명세서에서의 영구 저장 매체는, 예를 들어 자기(magnetic) 디스크, 광학(optical) 디스크 및 광자기(magneto-optical) 저장 디바이스뿐만 아니라 플래시 메모리 및/또는 배터리-백업 메모리에 기초한 저장 디바이스와 같은, 임의의 데이터를 지속적으로 할 수 있는 비-휘발성(non-volatile) 저장 매체를 의미한다. 이러한 영구 저장 매체는 다양한 통신 수단을 통하여 데이터베이스 서버(110 및 120)의 프로세서 및 메모리와 통신할 수 있다. 추가적인 실시예에서, 이러한 영구 저장 매체는 데이터베이스 서버(110 및 120) 외부에 위치하여 데이터베이스 서버(110 및 120)와 통신가능할 수도 있다.
DBMS(610, 710)는 데이터베이스 서버(110 및 120)에서 필요한 데이터를 검색, 삽입, 수정 및/또는 삭제 등과 같은 동작들을 수행하는 것을 허용하기 위한 프로그램으로서, 전술한 바와 같이, 데이터베이스 서버(110 및 120)의 메모리에서 프로세서(620, 720)에 의하여 구현될 수 있다. 또한, 소스 DBMS(610)는 소스 데이터베이스 서버(110)에서 발생되는 트랜잭션에 대한 리두 로그를 생성, 관리 및 저장하도록 결정할 수 있다. 소스 프로세서(620)는 CDC 동작을 구현하기 위하여 저장된 리두 로그를 추출하고 그리고 분석하며(630), CDC 파일(670)에 해당 내용을 기록하고, 그리고 CDC 파일(670)을 판독하여(650) 네트워크(140)를 통하여 타겟 데이터베이스 서버(120)로 송신할 수 있다(660). 소스 프로세서(620)의 추출(630), 기록(640), 판독(650) 및 송신(660) 동작들 각각은, 전술한 바와 같이 도 2에서의 추출 모듈(210), 기록 모듈(220), 판독 모듈(230) 및 송수신 모듈(240)이 수행하는 동작들에 대응될 수 있다. 추가적으로, 추출(630), 기록(640), 판독(650) 및 송신(660) 동작들은 각각 개별적인 스레드에 의해 수행될 수 있다. 또한, 추출(630), 기록(640), 판독(650) 및 송신(660) 동작들 중 복수개가 하나의 스레드에 의해 수행될 수도 있다. 또한, 추출(630), 기록(640), 판독(650) 및 송신(660) 동작들은 개별적인 프로세스에 의해 각각 수행되거나 혹은 하나의 프로세스가 상기 동작들 중 복수의 동작들을 수행할 수도 있다. 이하에서는 설명의 편의를 위하여 하나의 프로세스가 하나의 모듈 동작을 수행하는 것을 가정하여 본 개시내용의 실시예들에 따른 CDC 특징들을 기술하기로 한다.
본 개시내용의 일 실시예에서, 트랜잭션에 대한 Commit 연산이 수행되는 경우, 소스 프로세서(620)에서의 CDC 동작이 개시될 수 있다. 예를 들어, 소스 프로세서(620)는 트랜잭션의 Commit 연산이 수행되는 경우, 추출 동작(630)을 수행할 수 있다. 다른 예시로, 소스 프로세서(620)는 사전결정된 횟수의 Commit 연산이 수행되는 경우(예컨대, 2개의 트랜잭션에 대한 Commit 연산들이 수행된 경우), 해당 Commit 연산들과 관련된 복수의 트랜잭션들에 대한 CDC 동작을 개시할 수 있다. 다른 실시예에서, 사전결정된 시간 주기 혹은 사전결정된 SCN 주기에 따라서, 소스 프로세서(620)의 CDC 동작이 개시될 수 있다.
도 6에서 도시되는 바와 같이, 소스 DBMS(610)에서 T1 객체 및 T2 객체에 대한 트랜잭션들(680)이 인입될 수 있다. 상기 트랜잭션들(680)은 제 1 트랜잭션 및 제 2 트랜잭션을 포함할 수 있다. 제 1 트랜잭션은 T1 객체에 대한 Delete 연산 및 Commit 연산을 포함할 수 있다. 제 2 트랜잭션은 T1 객체에 대한 Insert 연산, T2 객체에 대한 Update 연산 및 Commit 연산을 포함할 수 있다. 소스 DBMS(610)에서 수행된 SQL 연산들(680)은 Commit 연산이 수행된 시점에 기초하여 시계열적으로 그리고 트랜잭션 단위로 정렬될 수 있다. 도 6에서는 제 1 트랜잭션에 대한 Commit 연산이 제 2 트랜잭션에 대한 Commit 연산 보다 먼저 이루어졌기 때문에, 제 1 트랜잭션에 대한 SQL 연산들이 제 2 트랜잭션에 대한 SQL 연산들 보다 앞 부분에 배치될 수 있다.
소스 프로세서(620)(예컨대, 추출(630) 스레드)는 리두 로그에서 T1 객체에 대한 Delete 연산 및 Commit 연산을 추출하여 시간 순서대로 정렬하고 이를 예컨대, 판독(640) 스레드로 전달할 수 있다. 판독(640) 스레드는 가장 앞서 배치되어 있는 T1 객체에 대한 Delete 연산(즉, Delete T1)을 확인하고 그리고 CDC 파일(670)에 T1 객체에 대한 이전 SQL 연산 이력이 존재하는지 여부를 판단할 수 있다. 일례로, 판독(640) 스레드는 T1 객체에 대한 이전 DML 혹은 DDL이 이루어졌는지 여부를 판단할 수 있다. 도 6에서 도시되는 바와 같이, T1 객체에 대해서는 이전 SQL 연산이 수행되지 않았기 때문에, 판독(640) 스레드는 메모리 상에 보유하고 있는 DD(Data Dictionary) 정보를 이용하여 T1에 대한 메타 정보(즉, T1 DD)를 생성할 수 있다. 그리고나서, 판독(640) 스레드는 T1에 대한 메타 정보인 T1 DD와 T1에 대한 Delete 연산인 Delete T1을 CDC 파일(670)에 기록할 수 있다. 이러한 경우, 메타 정보인 T1 DD는 SQL 연산 정보인 Delete T1 보다 CDC 파일에서의 앞 부분에 기록될 수 있다. 추가적으로, 판독(640) 스레드는 T1 객체에 대한 commit 연산을 CDC 파일(670)에 기록할 수 있다. 이러한 경우, Commit 연산은 CDC 파일(670)에서의 Delete T1이 기록된 부분 보다 뒷 부분에 기록될 수 있다.
본 개시내용의 일 실시예에서, 추출(630) 스레드는 리두로그에서 제 2 트랜잭션에 포함된, T1 객체에 대한 Insert 연산, T2 객체에 대한 Update 연산 및 제 2 트랜잭션의 Commit 연산을 추출할 수 있다. 추출(630) 스레드는 SQL 연산들의 발생 순서에 따라, Insert T1, Update T2 및 Commit 연산의 순서대로 배치할 수 있다. 제 2 트랜잭션이 제 1 트랜잭션 보다 이후에 Commit이 이루어졌기 때문에, 소스 DBMS(610)에서 수행된 SQL 연산들(680) 중 제 1 트랜잭션에 관한 SQL 연산들이 제 2 트랜잭션에 관한 SQL 연산들 보다 앞에 배치되도록 정렬될 수 있다. 판독(640) 스레드는 Delete T1 및 제 1 트랜잭션에 대한 Commit 연산을 판독 및 처리한 이후에, 트랜잭션 2와 관련된 연산들을 판독할 것이다. 판독(640) 스레드는 T1 객체에 대한 Insert 연산(즉, Insert T1)을 판독하고 CDC 파일(670)에 T1 객체에 대한 DML 혹은 DDL이 발생되었는지 여부(즉, 이전 SQL 연산 이력이 존재하는지 여부)를 판단할 수 있다. 상기 제 1 트랜잭션과 관련된 연산들(즉, Delete T1)을 처리하는데 있어서 CDC 파일(670)에 T1 객체에 대한 DD 정보가 기록되었기 때문에, 판독(640) 스레드는 CDC 파일(670)에 T1 객체에 대한 이전 SQL 연산 이력이 존재한다고 판단할 것이다. 이러한 상황에서, 판독(640) 스레드는 T1 객체에 대한 메타 정보를 생성하지 않고 T1 객체에 대한 Insert 연산(즉, Insert T1)을 CDC 파일(670)에서의 다음 기록 위치에 기록할 수 있다. 그리고나서, 판독(640) 스레드는 T2 객체에 대한 Update 연산을 인식할 수 있다. 판독(640) 스레드는 T2 객체에 대해서 이전 SQL 연산이 존재하는지 여부를 CDC 파일(670)을 체크하여 판단할 것이고, 이전 SQL 연산이 존재하지 않기 때문에, 메모리 상에 저장되어 있는 T2 객체에 대한 DD 정보를 이용하여 T2 객체에 대한 메타 정보(즉, T2 DD)를 생성할 수 있다. 그리고나서, 판독(640) 스레드는 T2 객체에 대한 메타 정보를 CDC 파일(670)의 다음 위치에 기록할 수 있다. 그리고나서, 판독(640)스레드는 T2 객체에 대한 메타 정보를 기록한 위치의 후속하는 위치에 T2 객체에 대한 Update 연산(즉, Update T2)을 기록할 수 있다. 추가적으로, 판독(640) 스레드는 T2 객체에 대한 Commit 연산을 CDC 파일(670)에 기록할 수 있다. 이러한 경우, Commit 연산은 CDC 파일(670)에서의 Update T2가 기록된 부분 보다 뒷 부분에 기록될 수 있다. 전술한 방식으로 트랜잭션들에 대한 Commit 시점 및 연산들의 발생 시점에 기초하여 CDC 파일(670)에 정보(690)가 기록될 수 있다. 이러한 방식으로 단일의 CDC 파일(670)에 메타 정보 및 SQL 연산 정보 모두가 기록될 수 있기 때문에, 효율적인 방식으로 CDC가 구현될 수 있다. 또한, Commmit이 발생한 메타 정보만이 소스 데이터베이스 서버(110)에서의 메모리에서 로딩될 수 있으며 그리고 CDC 파일(670)에는 본 개시내용의 실시예들에 따른 기록 규칙에 따른 순서대로 정보(690)가 기록되기 때문에, 타겟 데이터베이스 서버(120)는 소스 데이터베이스 서버(110)가 작성한 단일의 CDC 파일(670)에 기록된 순서대로 판독하면서 자신의 DB에 변경 데이터들을 용이하게 반영할 수 있다. 즉, 타겟 데이터베이스 서버(120)가 자신의 DB에 변경 데이터를 반영할 때 사용하는 CDC 파일에는, 소스 데이터베이스 서버(110)의 객체들 중 SQL 연산이 발생한 객체에 대한 메타 정보가 기록될 수 있다. 이러한 방식으로, 타겟 데이터베이스 서버(120)는 자신의 메모리에 모든 객체들에 대한 메타 정보를 로딩할 필요가 없으며, 소스 데이터베이스 서버(110)에서의 변경 데이터와 관련되는 객체들에 대한 메타 정보만을 메모리에 로딩하기 때문에, 데이터베이스 서버 내에서의 메모리 사용이 상당히 줄어들 수 있게 된다.
본 개시내용의 추가적인 양상에서, 클라이언트(110)와 데이터베이스 서버(120 및 130) 또는 데이터베이스 서버들(120 및 130)은 네트워크(미도시)를 통하여 서로 통신할 수 있다. 본 발명의 일 실시예에 따른 네트워크는 공중전화 교환망(PSTN:Public Switiched Telephone Network), xDSL(x Digital Subscriber Line), RADSL(Rate Adaptive DSL), MDSL(Multi Rate DSL), VDSL(Very High Speed DSL), UADSL(Universal Asymmetric DSL), HDSL(High Bit Rate DSL) 및 근거리 통신망(LAN) 등과 같은 다양한 유선 통신 시스템들을 사용할 수 있다.
또한, 본 명세서에서 제시되는 네트워크는 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) 및 다른 시스템들과 같은 다양한 무선 통신 시스템들을 사용할 수 있다. 또한, 본 명세서에서의 네트워크는 데이터베이스 링크(dblink)를 포함할 수 있으며, 이에 따라 소스 데이터베이스 서버(110) 및 타겟 데이터베이스 서버(120)(또는 에이전트 서버(130))는 이러한 데이터베이스 링크를 통해 서로 통신하여 다른 데이터베이스 서버로부터의 데이터를 가져올 수 있다. 일례로, 상기 데이터베이스 링크는 소스 데이터베이스 서버(110)로부터 타겟 데이터베이스 서버(120)로의 데이터베이스 링크를 포함할 수 있다. 본 명세서에서 설명된 기술들은 위에서 언급된 네트워크들뿐만 아니라, 다른 네트워크들에서도 사용될 수 있다.
도 6에서 도시되는 바와 같이, 타겟 데이터베이스 서버(120)는 타겟 DBMS(710) 및 타겟 프로세서(720)를 포함할 수 있다. 이러한 타겟 DBMS(710)는 타겟 데이터베이스 서버(120)의 메모리 상에서 타겟 프로세서(720)에 의해 동작될 수 있다. 타겟 데이터베이스 서버(120)의 하드웨어적 구성들 및 타겟 DBMS(710)에 대한 설명은 전술한 소스 데이터베이스 서버(110)의 하드웨어적 구성들 및 소스 DBMS(610) 구성과 동일하기 때문에, 해당 설명은 여기에서 생략될 것이다.
타겟 프로세서(720)는 CDC 동작을 구현하기 위하여 CDC 파일(670)을 수신(730)하고, 자신의 CDC 파일(770)에 해당 내용을 기록(740)하고(또는 수신된 CDC 파일(670)을 그대로 자신의 CDC 파일(770)로 사용하고), 그리고 CDC 파일(770)을 판독(750)하여, 타겟 DBMS(710)로 변경 데이터를 반영(760)시킬 수 있다. 타겟 프로세서(720)의 수신(730), 기록(740), 판독(750) 및 변경/반영(760) 동작들 각각은, 전술한 바와 같이 도 2에서의 수신 모듈(310), 기록 모듈(320), 판독 모듈(330) 및 변경/반영 모듈(340)이 수행하는 동작들에 대응될 수 있다. 추가적으로, 수신(730), 기록(740), 판독(750) 및 변경/반영(760) 동작들은 각각 개별적인 스레드에 의해 수행될 수 있다. 또한, 수신(730), 기록(740), 판독(750) 및 변경/반영(760) 동작들 중 복수개가 하나의 스레드에 의해 수행될 수도 있다. 또한, 수신(730), 기록(740), 판독(750) 및 변경/반영(760) 동작들은 개별적인 프로세스에 의해 각각 수행되거나 혹은 하나의 프로세스가 상기 동작들 중 복수의 동작들을 수행할 수도 있다. 이하에서는 설명의 편의를 위하여 하나의 프로세스가 하나의 모듈 동작을 수행하는 것을 가정하여 본 개시내용의 실시예들에 따른 CDC 특징들을 기술하기로 한다.
타겟 데이터베이스 서버(120)의 타겟 프로세서(720)(예컨대, 수신(730) 스레드)는 소스 데이터베이스 서버(110)로부터 CDC 파일(670)을 수신할 수 있다. 타겟 데이터베이스 서버(120)의 타겟 프로세서(720)는 수신된 CDC 파일(670)을 자신의 CDC 파일(770)에 동일하게 기록(740)하거나 혹은 수신된 CDC 파일(670)을 자신의 CDC 파일(770)으로 사용할 수도 있다. 타겟 프로세서(720)의 판독(750) 스레드는 CDC 파일(770)에 기록된 정보(780)를 판독하여 변경/반영(760) 스레드로 전달할 수 있다.
변경/반영(760) 스레드는 CDC 파일(770)에서 가장 먼저 기록된 T1 DD 라는 메타 정보를 판독하여, 자신의 메모리에 T1 객체에 대한 DD 메타 정보가 존재하는지 여부를 판단할 수 있다. 타겟 데이터베이스 서버(120)의 메모리에 T1 객체에 대한 메타 정보가 존재하지 않는 경우, 타겟 데이터베이스 서버(120)는 T1 DD 메타 정보를 자신의 메모리로 로딩할 수 있다. 그리고나서, 변경/반영(760) 스레드는 CDC 파일(770)에서 T1 DD라는 정보 이후에 기록된 Delete T1 확인할 수 있다. 변경/반영(760) 스레드는 메모리상에 로딩된 T1 DD 메타정보를 이용하여 T1 객체에 대한 Delete 연산을 수행하기 위한 SQL문을 자동으로 생성하여 타겟 DBMS(710)에 반영할 수 있다. 그리고나서, 변경/반영(760) 스레드는 Commit을 확인하고, Commit을 타겟 DBMS(710)에 반영할 수 있다. 그리고나서, 변경/반영(760) 스레드는 CDC 파일(770)에서의 다음번 기록된 정보인 Insert T1을 확인할 수 있다. T1 객체에 대한 연산이기 때문에, 변경/반영(760) 스레드는 메모리상에서 로딩된 T1 객체에 대한 메타정보를 이용하여 T1 객체에 Insert 연산을 수행하기 위한 SQL문을 생성할 수 있다.
변경/반영(760) 스레드는 CDC 파일(770)에서의 그 다음 위치에 기록되어 있는 T2 DD 메타정보를 확인할 수 있다. 변경/반영(760) 스레드는 T2 객체에 대한 DD 메타정보가 타겟 데이터베이스 서버(120)의 메모리에 존재하는지 여부를 검사할 수 있다. 변경/반영(760) 스레드는 자신의 메모리에 로딩되어 있는 T2 객체에 대한 메타 정보가 없다고 결정된 경우 T2 객체에 대한 메타 정보(즉, T2 DD 메타 정보)를 타겟 데이터베이스 서버(120)의 메모리에 로딩할 수 있다. 그리고나서, 변경/반영(760) 스레드는 CDC 파일(770)에서의 그 다음 위치에 기록되어 있는 Update T2를 인식할 수 있다. 변경/반영(760) 스레드는 T2 객체에 대한 메타 정보를 메모리에서 로딩할 수 있으며 그리고 상기 메타 정보를 이용함으로써 T2 객체에 대한 Update 연산과 대응되는 SQL 문을 자동으로 생성할 수 있다. 그리고나서, 변경/반영(760) 스레드는 T2 객체에 대한 Update 연산을 수행하기 위한 SQL 문을 자신의 DBMS(710)에 반영할 수 있다. 그리고나서, 변경/반영(760) 스레드는 Commit을 확인하고 이를 DBMS(710)에 반영할 수 있다.
본 개시내용의 일 실시예에 따라, CDC 파일에 대한 기록 규칙은 특정 객체에 대한 메타 정보를 1순위로 기록하고 특정 테이블에 대한 DML 혹은 DDL을 이에 후속하여 기록하는 것을 포함할 수 있다. 본 개시내용의 일 실시예에 따라, CDC 파일에 대한 기록 규칙은 Commit이 일어난 순서에 따라 기록될 트랜잭션들의 순서를 결정하고 그리고 메타 정보를 SQL 연산 정보에 앞에 기록함에 따라, 단일의 CDC 파일에 대한 전달을 통하여, CDC가 용이하게 이루어질 수 있다. 본 개시내용의 일 실시예에 따라, 모든 메타 정보를 메모리에 로딩시켜 놓고 CDC를 구현하는 구성(즉, 메타 정보와 SQL 연산 정보를 개별 파일에 의해 관리하는 구성)에 비해 메모리 사용량이 상당히 줄어들 수 있을 뿐만 아니라 DDL 발생 등의 상황에서 데이터베이스 서버의 동작이 멈추는 상황이 방지될 수 있다. 더불어, 본 개시내용의 일 실시예에 따른 CDC 특징들은 복수개의 테이블에 대한 DML 혹은 DDL을 반영하는데 있어서 기존 구조에 비해 메모리 사용량을 획기적으로 줄일 수 있다.
메타 정보와 SQL 연산 정보를 별도로 관리하는 CDC 구현 방식들은, 전체 객체들에 대한 메타 정보를 기록하는 별도의 파일을 양 데이터베이스 서버들 간에 송수신하면서 공유한다. 따라서, 이러한 구현 방식들은, 타겟 데이터베이스 서버(120)에서 DML이 발생하지 않은 객체에 대한 DD 정보도 메모리에 보유할 것을 요구한다. 즉, 타겟 데이터베이스 서버(120)는 모든 객체(예컨대, 테이블) 혹은 메모리 용량에 따라 최대한 많은 객체에 대한 DD 정보를 메모리에 보유하고 있어야 한다. 또한, 이러한 경우, DDL 발생시, 메타 정보를 기록한 파일을 수동으로 생성 및 전송해야하거나 또는 메타 정보를 기록한 파일을 자동으로 전송한다고 하더라도 소스 데이터베이스 서버(110)에서는 메타 파일의 전송이 완료될 때 까지 유휴(idle) 상태로 대기하여야 한다. 하지만, 본 개시내용의 일 실시예에 따른 CDC 구현 방식들은 메타 정보가 저장되는 메타 파일을 별도로 생성하여 전송할 필요가 없을 뿐만 아니라 소스 데이터베이스 서버(110)의 유휴 상태를 발생시키지 않는다. 따라서, 본 개시내용의 일 실시예에 따른 CDC 구현 방식들은 실시간 DDL 동기화를 허용할 수 있다. 나아가, 본 개시내용의 일 실시예에 따른 CDC 구현 방식들은 DML이 발생한 테이블에 대한 DD 정보를 관리하기 때문에 타겟 데이터베이스 서버(120)에서의 메모리 관리가 효율적으로 이루어질 수 있다. 예를 들어, 판독/기록과 관련하여 하나의 CDC 파일에 대한 DD를 관리하게 되며 그리고 변경/반영과 관련하여 DML 발생 객체에 대한 DD를 관리하게 될 것이기 때문에, 보다 리소스 효율적인 CDC 구현이 가능해질 수 있다.
도 7은 본 개시내용의 일 실시예에 따라 데이터베이스 시스템에서 수행되는 CDC 동작들을 개략적으로 도시한다.
도 7에서 도시되는 실시예는 도 6에서 도시되는 실시예에 DDL 특징이 추가된 것으로서, 도 6에서의 실시예들과 공통적인 내용들은 설명의 편의를 위해 이하에서는 생략될 것이다. 예를 들어, 도 7에서의 추출(830), 기록(840), 판독(850), 및 송신(860) 동작들은 각각 도 6에서의 추출(630), 기록(640), 판독(650), 및 송신(660) 동작들과 대응될 수 있다. 또한, 도 7에서의 수신(930), 기록(940), 판독(950), 및 변경/반영(960) 동작들은 각각 도 6에서의 수신(730), 기록(740), 판독(750), 및 변경/반영(760) 동작들과 대응될 수 있다. 또한, 도 7에서의 소스 DBMS(810), 소스 프로세서(820), 타겟 DBMS(910) 및 타겟 프로세서(920)는 각각 도 6에서의 소스 DBMS(610), 소스 프로세서(620), 타겟 DBMS(710) 및 타겟 프로세서(720)와 대응될 수 있다.
도 7에서 도시되는 바와 같이, 소스 DBMS(810)에 트랜잭션들(880)이 인입될 수 있다. 도 7에서의 예시에서, 상기 트랜잭션들(880)은 Insert T1, Update T2 및 Commit을 포함하는 제 1 트랜잭션, Delete T3 및 Commit을 포함하는 제 2 트랜잭션, 및 DDL T1을 포함하는 제 3 트랜잭션을 포함할 수 있다. 소스 프로세서(820)는 참조번호 880에서 도시되는 바와 같이, 인입된 트랜잭션들에 포함된 연산들을 발생 시간 순서대로 배치할 수 있다. 예를 들어, 추출(830) 스레드는 소스 DBMS(810)에서 발생된 트랜잭션들에 대한 리두 로그를 분석하여, 변경된 데이터에 대한 정보를 참조번호 880과 같이 추출하여 정렬시킬 수 있다.
제 2 트랜잭션이 제 1 트랜잭션보다 늦게 시작되었다고 하더라도 제 2 트랜잭션의 Commit 시점이 제 1 트랜잭션의 Commit 시점보다 빠르기 때문에, 소스 프로세서(820)는, 제 2 트랜잭션과 관련된 SQL 연산들을 제 1 트랜잭션과 관련된 SQL 연산들 보다 CDC 파일(870)에 먼저 기록할 수 있다. 트랜잭션들과 관련된 SQL 연산들은 트랜잭션 내에서 발생된 시간 순서에 따라 CDC 파일(870)에 기록될 수 있다.
도 7에 도시되는 바와 같이, 기록(840) 스레드는 제 2 트랜잭션에서 T3 객체에 대한 Delete 연산이 수행되었다는 것을 인식할 수 있다. 기록(840) 스레드는 T3 객체에 대한 메타 정보가 CDC 파일(870)에 존재하는지 여부를 확인할 수 있다. 즉, 기록(840) 스레드는 T3 객체에 대해 이전 SQL 수행 이력이 있는지 여부를 CDC 파일(870)에서 확인할 수 있다. T3 객체에 대한 메타 정보가 존재하지 않기 때문에, 기록(840) 스레드는 메모리 상에 로딩되어 있는 DD 정보를 이용함으로써 T3 객체에 대한 메타 정보를 생성하고 그리고 생성된 메타 정보(즉, T3 DD #1)를 CDC 파일(870)에 기록한다. 그리고나서, 기록(840) 스레드는 T3 객체에 대한 Delete 연산(즉, Delete T3)을 CDC 파일(870)에 기록할 수 있다. 추가적으로, 기록(840) 스레드는 제 2 트랜잭션에 대한 Commit 연산을 CDC 파일(870)에 기록할 수 있다. Commit 연산의 기록 위치는 Delete T3의 기록 위치 보다 뒷 부분이다.
기록(840) 스레드는 제 2 트랜잭션에 대한 CDC 파일(870)로의 기록을 완료한 후, 제 1 트랜잭션에 대한 CDC 파일(870)로의 기록을 시작할 수 있다. 기록(840) 스레드는 Insert T1을 확인하고 T1 객체에 대한 메타 정보가 CDC 파일(870)에 존재하는지 여부를 검사할 수 있다. 도 7에서 도시되는 바와 같이, 현재 CDC 파일(870)에는 T3 객체에 대한 메타 정보만이 기록되어 있기 때문에, 기록(840) 스레드는 T3 객체에 대한 메타 정보를 메모리의 DD 정보(예컨대, T3 객체에 대한 DD 정보)를 가지고 생성할 수 있다. 그리고나서, 기록(840) 스레드는 생성된 T3 객체에 대한 메타 정보(즉, TT DD #1)를 CDC 파일(870)로 기록할 수 있다. 그리고나서, 기록(840) 스레드는 이전에 확인한 Insert T1 연산을 CDC 파일(870)에서 메타 정보가 기록된 위치 이후의 위치에 기록할 수 있다. 기록(840) 스레드는 제 1 트랜잭션에서 Insert T1 다음에 발생된 SQL 연산인 Update T2 연산을 확인할 수 있다. 기록(840) 스레드는 T2 객체에 대한 메타 정보가 CDC 파일(870)에 존재하는지 여부를 검사할 수 있다. 현재 CDC 파일(870)에는 T3 객체에 대한 메타 정보 및 T2 객체에 대한 메타 정보가 기록되어 있기 때문에, 기록(840) 스레드는 T2 객체에 대한 메타 정보가 존재하지 않는다고 판단할 수 있다. 이러한 경우, 기록(840) 스레드는 메모리 상에 로딩되어 있는 T2 객체에 대한 DD 정보를 참고하여, T2 객체에 대한 메타 정보를 생성할 수 있다. 그리고나서, 기록(840) 스레드는 생성된 T2 객체의 메타 정보를 CDC 파일(870)로 기록할 수 있다. T2 객체의 메타 정보는 직전에 기록된 Insert T1의 기록 위치에 후속되는 위치에 기록될 수 있다. 그리고나서, 기록(840) 스레드는 기록된 메타 정보와 대응되는 Update T2 연산을 CDC 파일(870)에 후속해서 기록할 수 있다. 그리고나서 기록(840) 스레드는 제 1 트랜잭션에 대한 Commit 연산을 CDC 파일(870)에 기록할 수 있다. Commit 연산의 기록 위치는 Update T2의 기록 위치 보다 뒷 부분이다.
기록(840) 스레드는 제 1 트랜잭션에 대한 연산들을 모두 반영한 뒤에 제 3 트랜잭션(DDL T1을 포함함)을 확인할 수 있다. 기록(840) 스레드는 SQL 연산에 대한 타입을 확인하여, DDL 타입인 것으로 결정할 수 있다. 즉, 기록(840) 스레드는 SQL 연산에 대한 타입이 DML 연산인 것으로 결정된 경우, 상기 DML 연산과 대응되는 객체에 대한 상기 이전 SQL 연산 이력이 CDC 파일(870)에 존재하는지 여부를 판단하기로 결정할 수 있다. 또한, 기록(840) 스레드는 SQL 연산에 대한 타입이 DDL 연산인 것으로 결정된 경우, 상기 DDL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력이 CDC 파일(870)에 존재하는지 여부를 판단하지 않고, 상기 DDL 연산에 기초하여, 상기 DDL 연산에 대응되는 객체에 대한 메타 정보를 생성하고 그리고 생성된 메타 정보를 상기 CDC 파일에 기록할 것을 결정할 수 있다. 따라서, 기록(840) 스레드는 T1에 대한 DDL 연산에 대응되는 메타 정보를 생성하여 DDL T1을 CDC 파일(870)에 도 7에서 도시되는 바와 같이 기록할 수 있다.
판독(850) 스레드는 기록(840) 스레드에 의해 기록된 CDC 파일(870)을 판독하여 송신(860) 스레드로 전달할 수 있다. 송신(860) 스레드는 전달받은 CDC 파일(870)을 네트워크(140)를 통해 타겟 데이터베이스 서버(120)로 전송할 수 있다.
타겟 데이터베이스 서버(120)의 타겟 프로세서(920)는 수신(930) 스레드에 의해 CDC 파일(870)을 수신할 수 있다. 타겟 프로세서(920)의 기록(940) 스레드는 자신의 CDC 파일(970)에 수신된 CDC 파일(870)에 기록된 정보를 동일한 순서로 기록할 수 있다. 또는, 타겟 프로세서(920)의 기록(940) 스레드는 수신된 CDC 파일(870)을 그대로 자신의 CDC 파일(970)로 사용할 수도 있다. 따라서, 타겟 데이터베이스 서버(120)의 CDC 파일(970)은 참조번호 980과 같이 소스 데이터베이스 서버(110)에서 기록한 순서대로 정보들을 포함할 수 있다.
타겟 데이터베이스 서버(120)의 판독(950) 스레드는 CDC 파일(970)에 기록된 정보(980)를 변경/반영(920) 스레드로 전달할 수 있으며, 변경/반영(920) 스레드는 전달 받은 정보를 타겟 DBMS(910)에 반영하여, 타겟 DBMS(910)와 소스 DBMS(810)의 동기화를 수행할 수 있다. 변경/반영(920) 스레드는 참조번호 980로 표현된 정보의 기록 순서대로 타겟 DBMS(910)로의 반영을 수행할 수 있다. CDC 파일(970)에는 특정 SQL 연산에 대한 메타 정보가 먼저 기록되고 그 뒤에 대응되는 SQL 연산 정보가 기록될 수 있으며 그리고 DDL 연산에 대해서는 해당 메타 정보가 기록되기 때문에, 타겟 데이터베이스 서버(120)는 자신의 메모리에 많은 객체들에 대한 메타 정보를 로딩시킬 필요가 없으며, DML이 발생한 객체에 대한 메타 정보를 로딩시켜 반영을 처리할 수 있다. 구체적인 반영 방식에 대해서는 도 6과 관련하여 상술되었기 때문에, 도 7에서는 이에 대한 설명을 생략하기로 한다.
도 8은 본 개시내용의 일 실시예에 따라 CDC 솔루션을 구현하기 위한 예시적인 컴퓨팅 장치에 대한 블록도를 도시한다.
본 발명이 일반적으로 하나 이상의 컴퓨터 상에서 실행될 수 있는 컴퓨터 실행가능 명령어와 관련하여 전술되었지만, 당업자라면 본 발명이 기타 프로그램 모듈들과 결합되어 및/또는 하드웨어와 소프트웨어의 조합으로 구현될 수 있다는 것을 잘 알 것이다.
일반적으로, 프로그램 모듈은 특정의 태스크를 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로시져, 프로그램, 컴포넌트, 데이터 구조, 기타 등등을 포함한다. 또한, 당업자라면 본 발명의 방법이 단일-프로세서 또는 멀티프로세서 컴퓨터 시스템, 미니컴퓨터, 메인프레임 컴퓨터는 물론 퍼스널 컴퓨터, 핸드헬드 컴퓨팅 장치, 마이크로프로세서-기반 또는 프로그램가능 가전 제품, 기타 등등(이들 각각은 하나 이상의 연관된 장치와 연결되어 동작할 수 있음)을 비롯한 다른 컴퓨터 시스템 구성으로 실시될 수 있다는 것을 잘 알 것이다.
본 발명의 설명된 실시예들은 또한 어떤 태스크들이 통신 네트워크를 통해 연결되어 있는 원격 처리 장치들에 의해 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 장치 둘다에 위치할 수 있다.
컴퓨터는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터에 의해 액세스 가능한 매체는 그 어떤 것이든지 컴퓨터 판독가능 매체가 될 수 있고, 컴퓨터 판독가능 매체는 컴퓨터 판독가능 저장 매체 및 컴퓨터 판독가능 전송 매체를 포함할 수 있다. 이러한 컴퓨터 판독가능 저장 매체는 휘발성 및 비휘발성 매체, 이동식 및 비-이동식 매체를 포함한다. 컴퓨터 판독가능 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보를 저장하는 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성 매체, 이동식 및 비이동식 매체를 포함한다. 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital video disk) 또는 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 컴퓨터에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함하지만, 이에 한정되지 않는다.
컴퓨터 판독가능 전송 매체는 통상적으로 반송파(carrier wave) 또는 기타 전송 메커니즘(transport mechanism)과 같은 피변조 데이터 신호(modulated data signal)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터등을 구현하는 정보 전달 매체를 포함한다. 피변조 데이터 신호라는 용어는 신호 내에 정보를 인코딩하도록 그 신호의 특성들 중 하나 이상을 설정 또는 변경시킨 신호를 의미한다. 제한이 아닌 예로서, 컴퓨터 판독가능 전송 매체는 유선 네트워크 또는 직접 배선 접속(direct-wired connection)과 같은 유선 매체, 그리고 음향, RF, 적외선, 기타 무선 매체와 같은 무선 매체를 포함한다. 상술된 매체들 중 임의의 것의 조합도 역시 컴퓨터 판독가능 전송 매체의 범위 안에 포함되는 것으로 한다.
컴퓨터(1102)를 포함하는 본 발명의 여러가지 측면들을 구현하는 예시적인 환경(1100)이 나타내어져 있으며, 컴퓨터(1102)는 처리 장치(1104), 시스템 메모리(1106) 및 시스템 버스(1108)를 포함한다. 시스템 버스(1108)는 시스템 메모리(1106)(이에 한정되지 않음)를 비롯한 시스템 컴포넌트들을 처리 장치(1104)에 연결시킨다. 처리 장치(1104)는 다양한 상용 프로세서들 중 임의의 프로세서일 수 있다. 듀얼 프로세서 및 기타 멀티프로세서 아키텍처도 역시 처리 장치(1104)로서 이용될 수 있다.
시스템 버스(1108)는 메모리 버스, 주변장치 버스, 및 다양한 상용 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스에 추가적으로 상호 연결될 수 있는 몇가지 유형의 버스 구조 중 임의의 것일 수 있다. 시스템 메모리(1106)는 판독 전용 메모리(ROM)(1110) 및 랜덤 액세스 메모리(RAM)(1112)를 포함한다. 기본 입/출력 시스템(BIOS)은 ROM, EPROM, EEPROM 등의 비휘발성 메모리(1110)에 저장되며, 이 BIOS는 시동 중과 같은 때에 컴퓨터(1102) 내의 구성요소들 간에 정보를 전송하는 일을 돕는 기본적인 루틴을 포함한다. RAM(1112)은 또한 데이터를 캐싱하기 위한 정적 RAM 등의 고속 RAM을 포함할 수 있다.
컴퓨터(1102)는 또한 내장형 하드 디스크 드라이브(HDD)(1114)(예를 들어, EIDE, SATA)―이 내장형 하드 디스크 드라이브(1114)는 또한 적당한 섀시(도시 생략) 내에서 외장형 용도로 구성될 수 있음―, 자기 플로피 디스크 드라이브(FDD)(1116)(예를 들어, 이동식 디스켓(1118)으로부터 판독을 하거나 그에 기록을 하기 위한 것임), 및 광 디스크 드라이브(1120)(예를 들어, CD-ROM 디스크(1122)를 판독하거나 DVD 등의 기타 고용량 광 매체로부터 판독을 하거나 그에 기록을 하기 위한 것임)를 포함한다. 하드 디스크 드라이브(1114), 자기 디스크 드라이브(1116) 및 광 디스크 드라이브(1120)는 각각 하드 디스크 드라이브 인터페이스(1124), 자기 디스크 드라이브 인터페이스(1126) 및 광 드라이브 인터페이스(1128)에 의해 시스템 버스(1108)에 연결될 수 있다. 외장형 드라이브 구현을 위한 인터페이스(1124)는 USB(Universal Serial Bus) 및 IEEE 1394 인터페이스 기술 중 적어도 하나 또는 그 둘다를 포함한다.
이들 드라이브 및 그와 연관된 컴퓨터 판독가능 매체는 데이터, 데이터 구조, 컴퓨터 실행가능 명령어, 기타 등등의 비휘발성 저장을 제공한다. 컴퓨터(1102)의 경우, 드라이브 및 매체는 임의의 데이터를 적당한 디지털 형식으로 저장하는 것에 대응한다. 상기에서의 컴퓨터 판독가능 매체에 대한 설명이 HDD, 이동식 자기 디스크, 및 CD 또는 DVD 등의 이동식 광 매체를 언급하고 있지만, 당업자라면 집 드라이브(zip drive), 자기 카세트, 플래쉬 메모리 카드, 카트리지, 기타 등등의 컴퓨터에 의해 판독가능한 다른 유형의 매체도 역시 예시적인 운영 환경에서 사용될 수 있으며 또 임의의 이러한 매체가 본 발명의 방법들을 수행하기 위한 컴퓨터 실행가능 명령어를 포함할 수 있다는 것을 잘 알 것이다.
운영 체제(1130), 하나 이상의 애플리케이션 프로그램(1132), 기타 프로그램 모듈(1134) 및 프로그램 데이터(1136)을 비롯한 다수의 프로그램 모듈이 드라이브 및 RAM(1112)에 저장될 수 있다. 운영 체제, 애플리케이션, 모듈 및/또는 데이터의 전부 또는 그 일부분이 또한 RAM(1112)에 캐싱될 수 있다. 본 발명이 여러가지 상업적으로 이용가능한 운영 체제 또는 운영 체제들의 조합에서 구현될 수 있다는 것을 잘 알 것이다.
사용자는 하나 이상의 유선/무선 입력 장치, 예를 들어, 키보드(1138) 및 마우스(1140) 등의 포인팅 장치를 통해 컴퓨터(1102)에 명령 및 정보를 입력할 수 있다. 기타 입력 장치(도시 생략)로는 마이크, IR 리모콘, 조이스틱, 게임 패드, 스타일러스 펜, 터치 스크린, 기타 등등이 있을 수 있다. 이들 및 기타 입력 장치가 종종 시스템 버스(1108)에 연결되어 있는 입력 장치 인터페이스(1142)를 통해 처리 장치(1104)에 연결되지만, 병렬 포트, IEEE 1394 직렬 포트, 게임 포트, USB 포트, IR 인터페이스, 기타 등등의 기타 인터페이스에 의해 연결될 수 있다.
모니터(1144) 또는 다른 유형의 디스플레이 장치도 역시 비디오 어댑터(1146) 등의 인터페이스를 통해 시스템 버스(1108)에 연결된다. 모니터(1144)에 부가하여, 컴퓨터는 일반적으로 스피커, 프린터, 기타 등등의 기타 주변 출력 장치(도시 생략)를 포함한다.
컴퓨터(1102)는 유선 및/또는 무선 통신을 통한 원격 컴퓨터(들)(1148) 등의 하나 이상의 원격 컴퓨터로의 논리적 연결을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(들)(1148)는 워크스테이션, 서버 컴퓨터, 라우터, 퍼스널 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서-기반 오락 기기, 피어 장치 또는 기타 통상의 네트워크 노드일 수 있으며, 일반적으로 컴퓨터(1102)에 대해 기술된 구성요소들 중 다수 또는 그 전부를 포함하지만, 간략함을 위해, 메모리 저장 장치(1150)만이 도시되어 있다. 도시되어 있는 논리적 연결은 근거리 통신망(LAN)(1152) 및/또는 더 큰 네트워크, 예를 들어, 원거리 통신망(WAN)(1154)에의 유선/무선 연결을 포함한다. 이러한 LAN 및 WAN 네트워킹 환경은 사무실 및 회사에서 일반적인 것이며, 인트라넷 등의 전사적 컴퓨터 네트워크(enterprise-wide computer network)를 용이하게 해주며, 이들 모두는 전세계 컴퓨터 네트워크, 예를 들어, 인터넷에 연결될 수 있다.
LAN 네트워킹 환경에서 사용될 때, 컴퓨터(1102)는 유선 및/또는 무선 통신 네트워크 인터페이스 또는 어댑터(1156)를 통해 로컬 네트워크(1152)에 연결된다. 어댑터(1156)는 LAN(1152)에의 유선 또는 무선 통신을 용이하게 해줄 수 있으며, 이 LAN(1152)은 또한 무선 어댑터(1156)와 통신하기 위해 그에 설치되어 있는 무선 액세스 포인트를 포함하고 있다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(1102)는 모뎀(1158)을 포함할 수 있거나, WAN(1154) 상의 통신 서버에 연결되거나, 또는 인터넷을 통하는 등, WAN(1154)을 통해 통신을 설정하는 기타 수단을 갖는다. 내장형 또는 외장형 및 유선 또는 무선 장치일 수 있는 모뎀(1158)은 직렬 포트 인터페이스(1142)를 통해 시스템 버스(1108)에 연결된다. 네트워크화된 환경에서, 컴퓨터(1102)에 대해 설명된 프로그램 모듈들 또는 그의 일부분이 원격 메모리/저장 장치(1150)에 저장될 수 있다. 도시된 네트워크 연결이 예시적인 것이며 컴퓨터들 사이에 통신 링크를 설정하는 기타 수단이 사용될 수 있다는 것을 잘 알 것이다.
컴퓨터(1102)는 무선 통신으로 배치되어 동작하는 임의의 무선 장치 또는 개체, 예를 들어, 프린터, 스캐너, 데스크톱 및/또는 휴대용 컴퓨터, PDA(portable data assistant), 통신 위성, 무선 검출가능 태그와 연관된 임의의 장비 또는 장소, 및 전화와 통신을 하는 동작을 한다. 이것은 적어도 Wi-Fi 및 블루투스 무선 기술을 포함한다. 따라서, 통신은 종래의 네트워크에서와 같이 미리 정의된 구조이거나 단순하게 적어도 2개의 장치 사이의 애드혹 통신(ad hoc communication)일 수 있다.
Wi-Fi(Wireless Fidelity)는 유선 없이도 인터넷 등으로의 연결을 가능하게 해준다. Wi-Fi는 이러한 장치, 예를 들어, 컴퓨터가 실내에서 및 실외에서, 즉 기지국의 통화권 내의 아무 곳에서나 데이터를 전송 및 수신할 수 있게 해주는 셀 전화와 같은 무선 기술이다. Wi-Fi 네트워크는 안전하고 신뢰성있으며 고속인 무선 연결을 제공하기 위해 IEEE 802.11(a,b,g, 기타)이라고 하는 무선 기술을 사용한다. 컴퓨터를 서로에, 인터넷에 및 유선 네트워크(IEEE 802.3 또는 이더넷을 사용함)에 연결시키기 위해 Wi-Fi가 사용될 수 있다. Wi-Fi 네트워크는 비인가 2.4 및 5 GHz 무선 대역에서, 예를 들어, 11Mbps(802.11a) 또는 54 Mbps(802.11b) 데이터 레이트로 동작하거나, 양 대역(듀얼 대역)을 포함하는 제품에서 동작할 수 있다.
본 발명의 기술 분야에서 통상의 지식을 가진 자는 여기에 개시된 실시예들과 관련하여 설명된 다양한 예시적인 논리 블록들, 모듈들, 프로세서들, 수단들, 회로들 및 알고리즘 단계들이 전자 하드웨어, (편의를 위해, 여기에서 "소프트웨어"로 지칭되는) 다양한 형태들의 프로그램 또는 설계 코드 또는 이들 모두의 결합에 의해 구현될 수 있다는 것을 이해할 것이다. 하드웨어 및 소프트웨어의 이러한 상호 호환성을 명확하게 설명하기 위해, 다양한 예시적인 컴포넌트들, 블록들, 모듈들, 회로들 및 단계들이 이들의 기능과 관련하여 위에서 일반적으로 설명되었다. 이러한 기능이 하드웨어 또는 소프트웨어로서 구현되는지 여부는 특정한 애플리케이션 및 전체 시스템에 대하여 부과되는 설계 제약들에 따라 좌우된다. 본 발명의 기술 분야에서 통상의 지식을 가진 자는 각각의 특정한 애플리케이션에 대하여 다양한 방식들로 설명된 기능을 구현할 수 있으나, 이러한 구현 결정들은 본 발명의 범위를 벗어나는 것으로 해석되어서는 안 될 것이다.
여기서 제시된 다양한 실시예들은 방법, 장치, 또는 표준 프로그래밍 및/또는 엔지니어링 기술을 사용한 제조 물품(article)으로 구현될 수 있다. 용어 "제조 물품"은 임의의 컴퓨터-판독가능 장치로부터 액세스 가능한 컴퓨터 프로그램, 캐리어, 또는 매체(media)를 포함한다. 예를 들어, 컴퓨터-판독가능 매체는 자기 저장 장치(예를 들면, 하드 디스크, 플로피 디스크, 자기 스트립, 등), 광학 디스크(예를 들면, CD, DVD, 등), 스마트 카드, 및 플래쉬 메모리 장치(예를 들면, EEPROM, 카드, 스틱, 키 드라이브, 등)를 포함하지만, 이들로 제한되는 것은 아니다. 또한, 여기서 제시되는 다양한 저장 매체는 정보를 저장하기 위한 하나 이상의 장치 및/또는 다른 기계-판독가능한 매체를 포함한다. 용어 "기계-판독가능 매체"는 명령(들) 및/또는 데이터를 저장, 보유, 및/또는 전달할 수 있는 무선 채널 및 다양한 다른 매체를 포함하지만, 이들로 제한되는 것은 아니다.
제시된 프로세스들에 있는 단계들의 특정한 순서 또는 계층 구조는 예시적인 접근들의 일례임을 이해하도록 한다. 설계 우선순위들에 기반하여, 본 발명의 범위 내에서 프로세스들에 있는 단계들의 특정한 순서 또는 계층 구조가 재배열될 수 있다는 것을 이해하도록 한다. 첨부된 방법 청구항들은 샘플 순서로 다양한 단계들의 엘리먼트들을 제공하지만 제시된 특정한 순서 또는 계층 구조에 한정되는 것을 의미하지는 않는다.
제시된 실시예들에 대한 설명은 임의의 본 발명의 기술 분야에서 통상의 지식을 가진 자가 본 발명을 이용하거나 또는 실시할 수 있도록 제공된다. 이러한 실시예들에 대한 다양한 변형들은 본 발명의 기술 분야에서 통상의 지식을 가진 자에게 명백할 것이며, 여기에 정의된 일반적인 원리들은 본 발명의 범위를 벗어남이 없이 다른 실시예들에 적용될 수 있다. 그리하여, 본 발명은 여기에 제시된 실시예들로 한정되는 것이 아니라, 여기에 제시된 원리들 및 신규한 특징들과 일관되는 최광의의 범위에서 해석되어야 할 것이다.
상기와 같이 발명의 실시를 위한 최선의 형태에서 관련 내용을 기술하였다.
본 발명은 데이터베이스 관리 시스템(DBMS)에 관한 것으로, 보다 구체적으로 변경 데이터 캡쳐(CDC:Change Data Capture)에 관한 것이다.

Claims (18)

  1. 인코딩된 명령들을 포함하는 컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램으로서, 상기 컴퓨터 프로그램은 하나 이상의 프로세서에 의해 실행되는 경우, 상기 하나 이상의 프로세서로 하여금 변경 데이터 캡쳐(CDC:Change Data Capture)를 위한 방법을 수행하도록 하며, 상기 방법은:
    소스(source) 데이터베이스 서버에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 분석함으로써, 상기 트랜잭션과 연관되는 하나 이상의 객체들에 대하여 발생된 복수의 SQL(Structured Query Language) 연산들을 식별하는 단계;
    식별된 SQL 연산에 대응되는 객체에 대한 메타 정보가 상기 CDC 파일에 존재하는지 여부에 기초하여, 개별 SQL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력(previous SQL operation history)이 CDC 파일에 존재하는지 여부를 판단하는 단계;
    상기 CDC 파일에서의 이전 SQL 연산 이력의 존재 여부에 기초하여, 상기 CDC 파일에 기록할 정보를 결정하는 단계;
    상기 결정된 정보를 상기 CDC 파일에 기록하는 단계; 및
    상기 CDC 파일을 타겟(target) 데이터베이스 서버로 전송할 것을 결정하는 단계;
    를 포함하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  2. 제 1 항에 있어서,
    상기 메타 정보는: 테이블 유저 정보, 테이블 이름 정보, 컬럼 이름 정보, 컬럼 순서 정보 및 컬럼 타입 정보 중 적어도 하나를 포함하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  3. 제 1 항에 있어서,
    상기 이전 SQL 연산 이력이 상기 CDC 파일에 존재하는지 여부를 판단하는 단계는,
    상기 SQL 연산에 대응되는 객체에 대해서 이전에 DML(Data Manipulation Language) 연산 혹은 DDL(Data Definition Language) 연산이 수행되었는지 여부에 추가적으로 기초하여, 상기 이전 SQL 연산 이력이 상기 CDC 파일에 존재하는지 여부를 판단하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  4. 제 1 항에 있어서,
    상기 이전 SQL 연산 이력이 상기 CDC 파일에 존재하는지 여부를 판단하는 단계는,
    상기 트랜잭션과 연관되는 객체들 전체에 대해서 상기 SQL 연산이 발생한 순서대로 수행되는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  5. 제 1 항에 있어서,
    상기 CDC 파일에는 상기 소스 데이터베이스 서버의 객체들 중 상기 SQL 연산이 발생한 객체에 대한 메타 정보가 기록되는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  6. 제 1 항에 있어서,
    상기 CDC 파일에 기록할 정보를 결정하는 단계는:
    상기 CDC 파일에서의 이전 SQL 연산 이력이 존재하지 않는 경우, 해당 객체에 대한 DD(Data Dictionary) 정보를 사용하여 상기 해당 객체에 대한 메타 정보를 생성하고, 그리고 상기 CDC 파일에서의 이전 SQL 연산 이력이 존재하는 경우, 상기 해당 객체에 대한 메타 정보를 생성하지 않을 것을 결정하는 단계;
    를 포함하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  7. 제 6 항에 있어서,
    상기 CDC 파일에 기록할 정보를 결정하는 단계는:
    상기 해당 객체에 대한 메타 정보가 생성된 경우, 상기 해당 객체와 관련된 SQL 연산 및 상기 메타 정보를 상기 CDC 파일에 기록할 것을 결정하고, 그리고 상기 해당 객체에 대한 메타 정보가 생성되지 않은 경우, 상기 해당 객체와 관련된 SQL 연산을 상기 CDC 파일에 기록할 것을 결정하는 단계;
    를 더 포함하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  8. 제 7 항에 있어서,
    상기 SQL 연산 및 상기 메타 정보는, 단일의 CDC 파일에 함께 기록되는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  9. 제 6 항에 있어서,
    상기 결정된 정보를 상기 CDC 파일에 기록하는 단계는,
    상기 해당 객체에 대한 메타 정보를 상기 해당 객체와 관련된 SQL 연산 보다 상기 CDC 파일에서의 앞 부분에 기록하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  10. 제 6 항에 있어서,
    상기 트랜잭션은 제 1 트랜잭션 및 제 2 트랜잭션을 포함하며, 그리고
    상기 제 1 트랜잭션이 상기 제 2 트랜잭션 보다 먼저 커밋(commit)된 경우, 상기 제 1 트랜잭션에 포함된 SQL 연산이 상기 제 2 트랜잭션에 포함된 SQL 연산 보다 상기 CDC 파일에서의 앞 부분에 기록되는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  11. 제 10 항에 있어서,
    상기 제 1 트랜잭션이 적어도 제 1 객체와 관련되고 그리고 상기 제 2 트랜잭션이 상기 제 1 객체 및 상기 제 1 객체와 상이한 제 2 객체와 관련되는 경우, 상기 결정된 정보를 상기 CDC 파일에 기록하는 단계는:
    상기 제 1 트랜잭션에 따라 생성된 제 1 객체에 대한 메타 정보, 상기 제 1 트랜잭션에 따라 생성된 제 1 객체에 대한 SQL 연산, 상기 제 2 트랜잭션에 따라 생성된 제 1 객체에 대한 SQL 연산, 상기 제 2 트랜잭션에 따라 생성된 제 2 객체에 대한 메타 정보, 그리고 상기 제 2 트랜잭션에 따라 생성된 제 2 객체에 대한 SQL 연산의 순서로 상기 CDC 파일에 기록하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  12. 제 1 항에 있어서,
    상기 SQL 연산은, DML(Data Manipulation Language) 연산 및 DDL(Data Definition Language) 연산 중 적어도 하나의 타입을 포함하며,
    상기 방법은:
    상기 식별된 복수의 SQL 연산들 각각에 대한 타입을 결정하는 단계;
    SQL 연산에 대한 타입이 DML 연산인 것으로 결정된 경우, 상기 DML 연산과 대응되는 객체에 대한 상기 이전 SQL 연산 이력이 상기 CDC 파일에 존재하는지 여부를 판단할 것을 결정하는 단계; 및
    상기 SQL 연산에 대한 타입이 DDL 연산인 것으로 결정된 경우, 상기 DDL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력이 상기 CDC 파일에 존재하는지 여부를 판단하지 않고, 상기 DDL 연산에 기초하여, 상기 DDL 연산에 대응되는 객체에 대한 메타 정보를 생성하고 그리고 생성된 메타 정보를 상기 CDC 파일에 기록할 것을 결정하는 단계;
    를 더 포함하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  13. 변경 데이터 캡쳐(CDC:Change Data Capture)를 구현하기 위한 하나 이상의 프로세서를 포함하는 데이터베이스 서버로서,
    상기 하나 이상의 프로세서는:
    소스 데이터베이스 서버에서 처리되는 트랜잭션에 대한 정보를 포함하는 로그 레코드를 분석함으로써, 상기 트랜잭션과 연관되는 하나 이상의 객체들에 대하여 발생된 복수의 SQL(Structured Query Language) 연산들을 식별하는 동작;
    식별된 SQL 연산에 대응되는 객체에 대한 메타 정보가 상기 CDC 파일에 존재하는지 여부에 기초하여, 개별 SQL 연산과 대응되는 객체에 대한 이전 SQL 연산 이력(previous SQL operation history)이 CDC 파일에 존재하는지 여부를 판단하는 동작;
    상기 CDC 파일에서의 이전 SQL 연산 이력의 존재 여부에 기초하여, 상기 CDC 파일에 기록할 정보를 결정하는 동작;
    상기 결정된 정보를 상기 CDC 파일에 기록하는 동작; 및
    상기 CDC 파일을 타겟(target) 데이터베이스 서버로 전송할 것을 결정하는 동작;
    을 수행하는,
    하나 이상의 프로세서를 포함하는 데이터베이스 서버.
  14. 인코딩된 명령들을 포함하는 컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램으로서, 상기 컴퓨터 프로그램은 하나 이상의 프로세서에 의해 실행되는 경우, 상기 하나 이상의 프로세서로 하여금 변경 데이터 캡쳐(CDC:Change Data Capture)를 위한 방법을 수행하도록 하며, 상기 방법은:
    소스 데이터베이스 서버로부터 CDC 파일을 수신하는 단계;
    상기 CDC 파일에 기록된 메타 정보를 판독함으로써, 타겟 데이터베이스 서버에 대응되는 메타 정보가 존재하는지 여부를 판단하는 단계;
    상기 대응되는 메타 정보가 존재하지 않는 경우, 상기 CDC 파일에 기록된 메타 정보를 메모리에 로딩하는 단계;
    상기 CDC 파일에 기록된 SQL 연산을 판독하고, 그리고 상기 판독된 SQL 연산과 대응되는 상기 메모리 상에서의 상기 메타 정보를 사용함으로써 상기 SQL 연산과 대응되는 SQL 문(statement)을 생성하는 단계; 및
    상기 생성된 SQL 문을 상기 타겟 데이터베이스 서버에 적용시키는 단계;
    를 포함하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  15. 제 14 항에 있어서,
    상기 CDC 파일은, 상기 소스 데이터베이스 서버에 의해 기록된 순서대로 상기 타겟 데이터베이스 서버에서 판독되는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  16. 제 14 항에 있어서,
    상기 타겟 데이터베이스 서버에 상기 대응되는 메타 정보가 존재하는지 여부를 판단하는 단계는, 상기 대응되는 메타 정보가 상기 타겟 데이터베이스 서버의 메모리에 로딩되어 있는지 여부에 기초하여 판단하며, 그리고
    상기 방법은: 상기 대응되는 메타 정보가 존재하는 경우, 상기 CDC 파일에 기록된 메타 정보를 메모리에 로딩하지 않고 상기 타겟 데이터베이스 서버의 로딩되어 있는 상기 대응되는 메타 정보를 사용할 것을 결정하는 단계;
    를 더 포함하는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  17. 제 14 항에 있어서,
    상기 CDC 파일에는 상기 소스 데이터베이스 서버의 객체들 중 상기 SQL 연산이 발생한 객체에 대한 메타 정보가 기록되는,
    컴퓨터 판독가능 저장 매체에 저장된 컴퓨터 프로그램.
  18. 변경 데이터 캡쳐(CDC:Change Data Capture)를 구현하기 위한 하나 이상의 프로세서를 포함하는 데이터베이스 서버로서,
    상기 하나 이상의 프로세서는:
    소스 데이터베이스 서버로부터 CDC 파일을 수신하는 동작;
    상기 CDC 파일에 기록된 메타 정보를 판독함으로써, 타겟 데이터베이스 서버에 대응되는 메타 정보가 존재하는지 여부를 판단하는 동작;
    상기 대응되는 메타 정보가 존재하지 않는 경우, 상기 CDC 파일에 기록된 메타 정보를 메모리에 로딩하는 동작;
    상기 CDC 파일에 기록된 SQL 연산을 판독하고, 그리고 상기 판독된 SQL 연산과 대응되는 상기 메모리 상에서의 상기 메타 정보를 사용함으로써 상기 SQL 연산과 대응되는 SQL 문(statement)을 생성하는 동작; 및
    상기 생성된 SQL 문을 상기 타겟 데이터베이스 서버에 적용시키는 동작;
    을 수행하는,
    하나 이상의 프로세서를 포함하는 데이터베이스 서버.
PCT/KR2019/015429 2018-11-14 2019-11-13 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법 WO2020101343A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/965,282 US11314719B2 (en) 2018-11-14 2019-11-13 Method for implementing change data capture in database management system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020180139901A KR102119258B1 (ko) 2018-11-14 2018-11-14 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법
KR10-2018-0139901 2018-11-14

Publications (1)

Publication Number Publication Date
WO2020101343A1 true WO2020101343A1 (ko) 2020-05-22

Family

ID=70731601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/015429 WO2020101343A1 (ko) 2018-11-14 2019-11-13 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법

Country Status (3)

Country Link
US (1) US11314719B2 (ko)
KR (1) KR102119258B1 (ko)
WO (1) WO2020101343A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112115147A (zh) * 2020-09-25 2020-12-22 北京百度网讯科技有限公司 数据处理的方法、装置、设备和存储介质
CN113742415A (zh) * 2020-05-29 2021-12-03 北京金山云网络技术有限公司 增量数据同步方法、装置及电子设备
CN113836139A (zh) * 2021-09-15 2021-12-24 许昌许继软件技术有限公司 一种跨隔离装置的数据库同步系统及方法
CN117708094A (zh) * 2023-12-26 2024-03-15 行吟信息科技(武汉)有限公司 数据处理方法、装置、电子设备和存储介质

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023000912A (ja) * 2021-06-18 2023-01-04 株式会社日立製作所 リフレクション生成システム、リフレクション生成方法、及びリフレクション生成プログラム
CN113722394A (zh) * 2021-08-17 2021-11-30 北京百悟科技有限公司 数据同步方法、设备及存储介质
US11874751B2 (en) * 2021-12-09 2024-01-16 International Business Machines Corporation Operating a data center
KR20240139375A (ko) * 2023-03-14 2024-09-23 주식회사 실크로드소프트 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐를 수행하기 위한 방법 및 장치
CN116501789A (zh) * 2023-06-28 2023-07-28 本原数据(北京)信息技术有限公司 数据库数据写入方法和装置、电子设备及存储介质
CN117909346B (zh) * 2024-01-17 2024-09-17 中科世通亨奇(北京)科技有限公司 离线数据的更新方法、系统、存储介质及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7647354B2 (en) * 2002-05-24 2010-01-12 Oracle International Corporation High-performance change capture for data warehousing
US20110191299A1 (en) * 2010-02-01 2011-08-04 Microsoft Corporation Logical data backup and rollback using incremental capture in a distributed database
JP2011258122A (ja) * 2010-06-11 2011-12-22 Mitsubishi Electric Corp データ転送装置及びデータ転送方法及びデータ転送プログラム及びデータ連携システム
US20170011087A1 (en) * 2015-07-06 2017-01-12 Oracle International Corporation Dynamically switching between data sources
KR20180055952A (ko) * 2016-11-16 2018-05-28 주식회사 실크로드소프트 데이터베이스 관리 시스템에서의 데이터 복제 기법

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6976002B1 (en) 1999-08-24 2005-12-13 Steelcase Development Corporation System and method of determining a knowledge management solution
US7065538B2 (en) 2000-02-11 2006-06-20 Quest Software, Inc. System and method for reconciling transactions between a replication system and a recovered database
US6832229B2 (en) 2001-03-09 2004-12-14 Oracle International Corporation System and method for maintaining large-grained database concurrency with a log monitor incorporating dynamically redefinable business logic
US7111023B2 (en) 2001-05-24 2006-09-19 Oracle International Corporation Synchronous change data capture in a relational database
US7657576B1 (en) 2001-05-24 2010-02-02 Oracle International Corporation Asynchronous change capture for data warehousing
US6999977B1 (en) 2002-05-09 2006-02-14 Oracle International Corp Method and apparatus for change data capture in a database system
US6981004B2 (en) 2002-09-16 2005-12-27 Oracle International Corporation Method and mechanism for implementing in-memory transaction logging records
US6976022B2 (en) 2002-09-16 2005-12-13 Oracle International Corporation Method and mechanism for batch processing transaction logging records
US7908243B2 (en) 2005-11-25 2011-03-15 Oracle International Corporation Considering transient data also in reports generated based on data eventually stored in a data-warehouse
US7831574B2 (en) 2006-05-12 2010-11-09 Oracle International Corporation Apparatus and method for forming a homogenous transaction data store from heterogeneous sources
US7668878B2 (en) 2006-07-31 2010-02-23 Oracle International Corporation Replicating data between heterogeneous data systems
US7801852B2 (en) 2007-07-31 2010-09-21 Oracle International Corporation Checkpoint-free in log mining for distributed information sharing
US8799213B2 (en) 2007-07-31 2014-08-05 Oracle International Corporation Combining capture and apply in a distributed information sharing system
US8385657B2 (en) 2007-08-01 2013-02-26 Yeda Research And Development Co. Ltd. Multiscale edge detection and fiber enhancement using differences of oriented means
US9230002B2 (en) 2009-01-30 2016-01-05 Oracle International Corporation High performant information sharing and replication for single-publisher and multiple-subscriber configuration
US8676759B1 (en) 2009-09-30 2014-03-18 Sonicwall, Inc. Continuous data backup using real time delta storage
CN101697169A (zh) * 2009-10-23 2010-04-21 中兴通讯股份有限公司 源数据库和目的数据库之间数据同步的方法、装置及系统
US8626778B2 (en) 2010-07-23 2014-01-07 Oracle International Corporation System and method for conversion of JMS message data into database transactions for application to multiple heterogeneous databases
US8510270B2 (en) 2010-07-27 2013-08-13 Oracle International Corporation MYSQL database heterogeneous log based replication
US9298878B2 (en) 2010-07-29 2016-03-29 Oracle International Corporation System and method for real-time transactional data obfuscation
US8874506B2 (en) 2012-09-10 2014-10-28 Oracle International Corporation Preventing database replication conflicts in a distributed environment
WO2014101207A1 (en) * 2012-12-31 2014-07-03 Sybase, Inc. Continuous change data capture without disruption of ddl
US9141680B2 (en) 2013-02-11 2015-09-22 Dell Products L.P. Data consistency and rollback for cloud analytics
US9727624B2 (en) 2013-03-01 2017-08-08 Oracle International Corporation Active replication with generic conflict detection and resolution (CDR)
US9171051B2 (en) * 2013-07-24 2015-10-27 Oracle International Corporation Data definition language (DDL) expression annotation
US10671565B2 (en) 2015-04-24 2020-06-02 Quest Software Inc. Partitioning target data to improve data replication performance
US10216589B2 (en) * 2016-03-02 2019-02-26 International Business Machines Corporation Smart data replication recoverer
US10803048B2 (en) 2016-09-16 2020-10-13 Oracle International Corporation Change data capture processing and analysis
US11669509B2 (en) * 2017-09-29 2023-06-06 Jpmorgan Chase Bank, N.A. System and method for achieving optimal change data capture (CDC) on hadoop
US10936441B2 (en) * 2017-12-15 2021-03-02 Microsoft Technology Licensing, Llc Write-ahead style logging in a persistent memory device
US10664465B2 (en) * 2018-04-03 2020-05-26 Sap Se Database change capture with transaction-consistent order
US11645261B2 (en) * 2018-04-27 2023-05-09 Oracle International Corporation System and method for heterogeneous database replication from a remote server

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7647354B2 (en) * 2002-05-24 2010-01-12 Oracle International Corporation High-performance change capture for data warehousing
US20110191299A1 (en) * 2010-02-01 2011-08-04 Microsoft Corporation Logical data backup and rollback using incremental capture in a distributed database
JP2011258122A (ja) * 2010-06-11 2011-12-22 Mitsubishi Electric Corp データ転送装置及びデータ転送方法及びデータ転送プログラム及びデータ連携システム
US20170011087A1 (en) * 2015-07-06 2017-01-12 Oracle International Corporation Dynamically switching between data sources
KR20180055952A (ko) * 2016-11-16 2018-05-28 주식회사 실크로드소프트 데이터베이스 관리 시스템에서의 데이터 복제 기법

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113742415A (zh) * 2020-05-29 2021-12-03 北京金山云网络技术有限公司 增量数据同步方法、装置及电子设备
CN112115147A (zh) * 2020-09-25 2020-12-22 北京百度网讯科技有限公司 数据处理的方法、装置、设备和存储介质
CN112115147B (zh) * 2020-09-25 2024-04-30 北京百度网讯科技有限公司 数据处理的方法、装置、设备和存储介质
CN113836139A (zh) * 2021-09-15 2021-12-24 许昌许继软件技术有限公司 一种跨隔离装置的数据库同步系统及方法
CN113836139B (zh) * 2021-09-15 2024-04-12 许昌许继软件技术有限公司 一种跨隔离装置的数据库同步系统及方法
CN117708094A (zh) * 2023-12-26 2024-03-15 行吟信息科技(武汉)有限公司 数据处理方法、装置、电子设备和存储介质

Also Published As

Publication number Publication date
KR20200056526A (ko) 2020-05-25
KR102119258B1 (ko) 2020-06-05
US20210271660A1 (en) 2021-09-02
US11314719B2 (en) 2022-04-26

Similar Documents

Publication Publication Date Title
WO2020101343A1 (ko) 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법
WO2018093094A1 (ko) 데이터베이스 관리 시스템에서의 데이터 복제 기법
WO2018101640A1 (ko) 데이터베이스 이중화 무중단 정합성 복구 기법
US10754835B2 (en) High-efficiency deduplication module of a database-management system
KR20200056357A (ko) 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법
KR100983300B1 (ko) 데이터 처리 시스템 내에서의 고장 복구
US7984327B2 (en) Fast data recovery system
US8495027B2 (en) Processing archive content based on hierarchical classification levels
JP3503957B2 (ja) 遠隔データベースの制御方法及び装置
US20040078658A1 (en) Journaling and recovery method of shared disk file system
US11347681B2 (en) Enhanced reading or recalling of archived files
US20100318534A1 (en) Intelligent retrieval of digital assets
WO2021141294A1 (ko) 데이터의 하이브리드 저장을 이용한 데이터 아카이빙 방법 및 시스템
US20210318938A1 (en) Updating stateful system in server cluster
WO2020119709A1 (zh) 数据合并的实现方法、装置、系统及存储介质
WO2022252322A1 (zh) 基于特征标记的电网监控系统内存库关系库同步方法
WO2018097522A1 (ko) 데이터베이스의 이중화를 위한 기법
WO2020213985A1 (ko) 데이터베이스 시스템에서 효율적인 변경 데이터 캡쳐를 제공하기 위한 컴퓨터 프로그램
US6738791B2 (en) Data synchronizing device
WO2023240995A1 (zh) 一种双机热备系统的数据恢复方法、装置及介质
WO2024190986A1 (ko) 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐를 수행하기 위한 방법 및 장치
WO2021141293A1 (ko) 데이터의 전송 및 조회 시의 비용을 최소화하기 위한 데이터 아카이빙 방법 및 시스템
CN112199332A (zh) 分布式防爆巡检机器人集群智能化文件管理方法及系统
KR20200078426A (ko) 복구 서버 및 컴퓨터 프로그램
WO2022250292A1 (ko) 서버간 네트워크가 단절된 망분리 환경에서의 cdc 방식의 db 복제 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19884285

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19884285

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 01/10/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19884285

Country of ref document: EP

Kind code of ref document: A1