KR20240040262A - Automatic registration system for static data and its operation method - Google Patents

Abstract

According to an embodiment of the present invention, an automatic registration system for static data and a method of operating the same are disclosed. The method includes: determining to perform synchronization on a materialized view existing in a second database server located remotely from the first database server; In response to a decision to perform synchronization, generating a synchronization command to be transmitted to the second database server; and transmitting the generated synchronization command to the second database server, causing the second database server to perform synchronization between the materialized view existing in the second database server and the master table existing in the first database server. It may include steps to do so.

Description

Automatic registration system for static data and its operation method}

The present invention relates to an automatic registration system for static data and a method of operating the same. It relates to a system and a method of operating the same that automatically synchronize and register data created with an online document writer such as a cloud system.

Static data refers to data that is loaded into memory and used by calling the data whenever necessary, and dynamic data that is converted and applied in real time on the server. can be distinguished.

In a database management system (DBMS), data can be stored in a data store. In a relational database management system (RDBMS), these data stores may be referred to as tables. This table includes one or more rows, and each of the one or more rows may include one or more columns.

If a database contains a large amount of data, it may take a relatively long time to perform a query to retrieve data of interest to the user. If the database takes a lot of time to respond to queries, it can have a negative impact on the performance of the database.

In these situations, it is desirable to limit direct access to columns or tables that are accessed frequently and by multiple users. This problem can be solved by performing indirect access to the column or table through a “view” rather than direct access to the column or table. This “view” may refer to a virtual or logical table that does not physically exist in the same form as the master table, derived from one or more master tables. In other words, when a view is executed, the result set of the defined query is created in memory, and when the session ends, the result set disappears.

Meanwhile, the synchronization framework allows various devices or appliances to transmit data from the device or a synchronization server and/or an external partner over a network connection, such as over the Internet. Synchronization can be achieved through triggering synchronization of data upon user request, at periodic intervals, or in real time. For example, a synchronization event may correspond to a displayed instruction or command issued by the user to synchronize information associated with the data being presented (e.g., “to record my last page read”).

The purpose of the present invention is to implement synchronization of query results between databases in an efficient manner.

The purpose of the present invention is to implement fast refresh of materialized views between databases.

According to an embodiment of the present invention, a method for automatically registering static data is disclosed. The method includes: determining to perform synchronization on a materialized view existing in a second database server located remotely from the first database server; In response to a decision to perform synchronization, generating a synchronization command to be transmitted to the second database server; and transmitting the generated synchronization command to the second database server, causing the second database server to perform synchronization between the materialized view existing in the second database server and the master table existing in the first database server. It may include steps to do so.

According to an embodiment of the present invention, a method for synchronizing query results between databases performed on a second database server is disclosed. The method includes: receiving a synchronization command from a first database server located remotely from the second database server; And in response to the received synchronization command, it may include performing synchronization between the materialized view existing in the second database server and the master table existing in the first database server.

According to an embodiment of the present invention, synchronization of query results between databases can be implemented in an efficient manner.

According to one embodiment of the present invention, fast refresh of materialized views between databases can be implemented.

1 shows a schematic diagram of an automatic registration system for static data according to an embodiment of the present invention.
Figure 2 shows a schematic diagram of a first database server according to one embodiment of the present invention.
Figure 3 shows a schematic diagram of a second database server according to one embodiment of the present invention.
Figure 4 shows a flowchart for synchronizing query results between databases performed on a first database server according to an embodiment of the present invention.

Various aspects of the present disclosure relate generally to data synchronization. More specifically, various aspects of the present disclosure generally relate to how data is synchronized across various devices. This approach allows synchronization of data by a data synchronization framework, including personal computers (PCs), handheld devices, personal digital assistants (PDAs), tablets, smartphones, and scientific devices. Any connected device or appliance, such as an appliance, store device, etc., performs contextual synchronization through a wide variety of communication network topologies, including both wired and wireless connections.

Aspects of the disclosure described herein anticipate groups of data to be transmitted from one machine to another. Moreover, another aspect of the present disclosure prioritizes data within each transmission based on user activity and system information on each device. Additionally, another aspect is identifying user behavior that indicates that the user requires immediate access to data on a given device, thereby making new or modified data available on other devices only at the time the user requests it. synchronize to such devices.

In one example according to the present disclosure, a method for synchronizing data is provided. The method includes monitoring a set of attributes in a plurality of devices on a network, selecting a group of data for synchronization based on the monitored attribute set, and assigning a priority level to each selected data and each device. and assigning priority to a synchronization operation to be performed on the selected data group based on the priority level, and synchronizing the selected data group according to the priority assignment of synchronization.

In another example according to the present disclosure, a system is provided. The system includes a monitoring module that monitors a set of attributes in a plurality of devices on a network, a prediction module that selects a group of data for synchronization based on the monitored attribute set and assigns a priority level to each selected data and each device; , and a data manager that gives priority to synchronization operations to be performed on the selected data group based on the priority level. The data manager also synchronizes selected data groups according to synchronization priority.

1 shows a schematic diagram of a system 100 for automatic registration of static data according to an embodiment of the present invention.

As shown in FIG. 1, the automatic registration system 100 for static data may include a client 110, a first database server 120, and a second database server 130.

As shown in FIG. 1, the client 110 may refer to node(s) in an automatic registration system for static data that has a mechanism for communicating through a network. For example, client 110 may include a PC, laptop computer, workstation, terminal, and/or any electronic device with network connectivity. Additionally, the client 110 may include any server implemented by at least one of an agent, an application programming interface (API), and a plug-in. For example, client 110 in FIG. 1 may be associated with a user using second database server 130. In this example, the client 110 may check a materialized view referencing a table in the first database server 120 through the second database server 130.

Database servers 120 and 130 may include any type of computer system or computer device, such as, for example, microprocessors, mainframe computers, digital single processors, portable devices, and device controllers. Each of these database servers 120 and 130 may include a database management system (DBMS) 120a and 130a and persistent storage (persistent storage) 120b and 130b. The first database server 120 and the second database server 130 may refer to heterogeneous database servers located remotely from each other. In addition, although Figure 1 shows two database servers, it will be clear to those skilled in the art that more database servers may also be included in the scope of the present invention.

Although not shown in Figure 1, database servers 120 and 130 may include one or more memories that include a buffer cache. Additionally, although not shown in FIG. 1, the database servers 120 and 130 may include one or more processors. Accordingly, DBMS (120a and 120b) can be operated by the processor on the memory.

Here, memory is the main storage device directly accessed by the processor, such as random access memory (RAM) such as dynamic random access memory (DRAM) and static random access memory (SRAM), and stores information when the power is turned off. may refer to a volatile storage device that is instantaneously erased, but is not limited to these. These memories can be operated by a processor. Memory can temporarily store a data table containing data values. The data table may include data values, and in one embodiment of the present invention, the data values of the data table may be written from memory to a permanent storage medium. In a further aspect, the memory includes a buffer cache, where data may be stored in data blocks of the buffer cache. The data may be recorded to a permanent storage medium by a background process.

Permanent storage media 120b and 130b may include, for example, magnetic disks, optical disks, and magneto-optical storage devices, as well as storage devices based on flash memory and/or battery-backed memory. It refers to a non-volatile storage medium that can continuously store arbitrary data. These persistent storage media (120b and 130b) can communicate with the processors and memories of the database servers (120 and 130) through various communication means. In additional embodiments, these persistent storage media 120b and 130b may be located external to and communicable with database servers 120 and 130.

DBMS (120a and 130a) is a program that allows performing operations such as searching, inserting, modifying and/or deleting necessary data in the database servers (120 and 130). As described above, the database servers (120 and 130) 130) can be implemented by a processor in memory.

The client 110 and the database servers 120 and 130 or the database servers 120 and 130 may communicate with each other through a network (not shown). The network according to an embodiment of the present invention includes Public Switched Telephone Network (PSTN), x Digital Subscriber Line (xDSL), Rate Adaptive DSL (RADSL), Multi Rate DSL (MDSL), and Very High Speed DSL (VDSL). ), UADSL (Universal Asymmetric DSL), HDSL (High Bit Rate DSL), and local area network (LAN) can be used.

In addition, the networks presented in this specification include Code Division Multi Access (CDMA), Time Division Multi Access (TDMA), Frequency Division Multi Access (FDMA), Orthogonal Frequency Division Multi Access (OFDMA), and Single Carrier-FDMA (SC-FDMA). ) and other systems may be used. Additionally, the network in this specification may include a database link (dblink), whereby the first database server 120 and the second database server 130 communicate with each other through this database link to receive information from other database servers. Data can be imported. For example, the database link may include a database link from the first database server 120 to the second database server 130. The techniques described herein can be used in the networks mentioned above, as well as other networks.

As shown in FIG. 1, the first database server 120 may be located remotely from the second database server 130. Additionally, the first database server 120 and the second database server may mean database servers that are incompatible with each other. One of these database servers (e.g., first database server 120) contains a master table (i.e., a table included in the FROM clause used in the query), and another database server (e.g., second database server 120) contains a master table (i.e., a table included in the FROM clause used in the query). The database server 130 includes a materialized view (a table storing query results) for the master table. The materialized view here can be used interchangeably with a materialized view table, Mview, or container table.

Query result synchronization (refresh) in this specification may mean reflecting the results of a materialized view query in a materialized view table. This reflection method may include a complete refresh method that empties the contents of the materialized view table and inserts the entire query result, and a fast refresh method that changes only the changes (diff) of the master table. You can. Since the complete refresh method requires a large amount of processing time compared to the high-speed refresh method, for example, when processing a large amount of data, the high-speed refresh method is generally preferable.

As shown in FIG. 1, because the first and second database servers are located remotely, there is difficulty in implementing synchronization (i.e., refresh) of query results. That is, in the high-speed refresh method, changes in the table (i.e., master table) included in the FROM clause used in the query must be reflected in the table (i.e., materialized view) where the query results are stored. Metadata included in stored log tables must be able to be interpreted by heterogeneous servers located remotely. However, it is realistically impossible to share coding rules, permission rules, communication rules, encryption rules, etc. between database servers independently produced by different manufacturers. Therefore, instead of the above-described high-speed refresh of materialized views between heterogeneous database servers, all data in the materialized view table must be deleted, queries related to the materialized view must be re-performed, and all result data of the query must be inserted into the materialized view table. method (i.e., complete refresh method) may be possible. However, this method not only takes an excessive amount of time to process large amounts of data, but can also have a negative impact on the performance of the database server.

Figure 2 shows a schematic diagram of a first database server 120 according to one embodiment of the present invention.

As shown in FIG. 2, the first database server 120 may include a synchronization determination module 201, a synchronization command generation module 203, a communication module 205, and a storage module 207. Each module in the first database server 120 can communicate with each other. Additionally, for example, the components of the first database server 120 described above may be included in the DBMS 120a. Additionally, the components of the first database server 120 described above are exemplary, and additional components other than the components described above may also be included in the first database server 120.

The synchronization decision module 201 may determine whether to perform synchronization on a materialized view existing in a second database server located remotely from the first database server. For example, the synchronization decision module 201 may determine a synchronization request from the client 110, a synchronization request from the second database server 130, a preset synchronization cycle, and a situation in which a data change in the master table occurs (e.g., It is possible to determine whether to perform synchronization based on at least one of the commit occurrences. For example, the synchronization determination module 201 may check the log table set of the first database server 120 to determine whether there have been data changes in the master table. The synchronization decision module 201 may determine whether to perform synchronization if there is a data change. Additionally, the synchronization decision module 201 may determine not to perform synchronization if it is determined that there are no data changes in the master table.

The synchronization command generation module 203 may generate a synchronization command to be transmitted to the second database server 139 in response to the decision to perform synchronization. For example, the synchronization command creation module 203 provides connection information for accessing a materialized view existing in the second database server 130 from a materialized view object (mview object) existing in the first database server 120. The included metadata can be obtained. This materialized view object may refer to the materialized view of the second database server 130. The synchronization command generation module 203 may generate a synchronization command to be transmitted to the second database server 130 based on the obtained metadata. The metadata here may include, for example, query information about the materialized view, database link information for communication between the first and second databases, and/or name information of the materialized view table. In one embodiment of the invention, the synchronization command generated by the synchronization command generation module 203 stores log information in a first set of log tables that exist in a first database table and is associated with the master table in the second database. It may include a command for inserting into the second materialized view log table. Additionally, the synchronization command may include information for a procedure call to the second database server 130.

The communication module 205 may provide a communication function with the second database server 130 or the client 110. For example, the communication module 205 may transmit the generated synchronization command to the second database server 130. Additionally, communication module 205 may communicate with second database server 130 or client 110 using any of the network and/or database links described above. Additionally, the communication module 205 may receive data storage, inquiry, index build, and inquiry requests from clients using the first database server 120. Additionally, the communication module 205 may deliver result information about data storage, inquiry and index building, and inquiry requests. In addition, the communication module 205 may transmit a synchronization command to the second database server 130 by calling a procedure with the second database server 130.

The storage module 207 may include a set of materialized view objects, master tables, and log tables. The storage module 207 may store all data stored in relation to task performance of the first database server 120. The storage module 207 may be included in the DBMS 120a and/or the persistent storage medium 120b. Additionally, the storage module 207 may create a master table, a materialized view object, a first materialized view log table, a DD_SLOG table, and a DD_MLOG table on the first database server 120. As another example, the creation of these tables may be performed by a separate component, such as a control module (not shown). Additionally, the storage module 207 may process and manage requests related to storage (including updates) of data. This storage module 207 can decide to store data, index tables, etc. Additionally, the storage module 207 may determine a storage location for the data and/or index table. For example, the storage module 207 may determine a storage location for data on a data table. As another example, the storage module 207 may determine a storage location on the persistent storage medium 130a for data.

Figure 3 shows a schematic diagram of a second database server 130 according to one embodiment of the present invention.

As shown in FIG. 3, the second database server 130 may include a synchronization performance module 301, a communication module 303, and a storage module 305. Each module in the second database server 130 can communicate with each other. Additionally, for example, the components of the second database server 130 described above may be included in the DBMS 130a. Additionally, the components of the second database server 130 described above are exemplary, and additional components other than the components described above may also be included in the second database server 130.

The synchronization performing module 301 may perform synchronization (fast refresh) between the materialized view and the master table in response to the synchronization command received from the first database server 120. For example, the synchronization performing module 301 stores log information in the log table set that exists in the first database server 120 and is associated with the master table to the second materialized view log table that exists in the second database server 130. Can be inserted. Additionally, the synchronization performing module 301 may perform synchronization by performing a join operation between the second materialized view log table including the inserted log information and the materialized view table. Additionally, the synchronization performing module 301 may create a second materialized view log table and a materialized view table on the second database server 130. As another example, the creation of these tables may be performed by separate components, such as a storage module 305 and/or a control module (not shown).

The communication module 303 may provide a communication function with the first database server 120 or the client 110. For example, the communication module 303 may receive a synchronization command from the first database server 120. Additionally, communication module 303 may communicate with first database server 120 or client 110 using any of the network and/or database links described above. Additionally, the communication module 303 may receive data storage, inquiry, index build, and inquiry requests from a client using the second database server 130. Additionally, the communication module 303 may deliver result information about data storage, inquiry and index building, inquiry request, and synchronization performance. In addition, the communication module 303 may receive a procedure call from the first database server 120.

The storage module 305 may include a materialized view table and a second materialized view log table. The storage module 305 may store all data stored in relation to task performance of the second database server 130. The storage module 305 may be included in the DBMS 130a and/or the persistent storage medium 130b. Additionally, the storage module 305 may process and manage requests related to storage (including updates) of data. This storage module 305 can decide to store data, index tables, etc. Additionally, the storage module 305 may determine a storage location for the data and/or index table. For example, the storage module 305 may determine a storage location for data on a data table. As another example, storage module 305 may determine a storage location on persistent storage medium 130b for data.

FIG. 4 shows a flowchart for synchronizing query results between databases performed on the first database server 120 according to an embodiment of the present invention.

The order of the flowchart shown in FIG. 4 may vary depending on implementation, and some orders may be added or some orders may be omitted.

As shown in FIG. 4, the first database server 120 may decide to perform synchronization on the materialized view existing in the second database server 130 located remotely from the first database server 120 ( 401). In one embodiment of the present invention, the first database server 120 generates a synchronization request from the client 110, a synchronization request from the second database server 130, a preset synchronization period, and a change in data in the master table. It may be determined whether to perform synchronization based on at least one of the following situations. Additionally, the first database server 120 may check the log table set of the first database server 120 to determine whether there has been a change in data in the master table. For example, the first database server 120 may consider time information about the previous (latest) synchronization point and determine whether there has been a change in data in the master table after the latest synchronization point. The first database server 120 may decide to perform synchronization when there is a change in data. Additionally, the first database server 120 may determine not to perform synchronization when it is determined that there are no data changes in the master table. When it is determined to perform synchronization, the first database server 120 displays the youngest last refresh time of each materialized view included in the DD_MLOG table in the log table set at the current time (i.e., sysdata). It can be changed to . In an additional embodiment, the determination of whether to perform the above-described synchronization in the first database server 120 may be performed after calling a procedure to the second database server 130.

In one embodiment of the present invention, the first database server 120 references a materialized view object existing in the first database server 120 and includes connection information for access to the materialized view. metadata may be obtained (403), and the first database server 120 may generate a synchronization command to be transmitted to the second database server 130 in response to the decision to perform synchronization (405). A materialized view object pointing to a materialized view existing in the second database server 130 may be created in the first database server 120. The materialized view object in the present invention may include, for example, a separate table that stores metadata related to the materialized view. This materialized view object may include metadata such as query information about the materialized view, database link information for communication between the first and second database servers, and/or table name information of the materialized view. Since the materialized view object, which is generally located in the place where the materialized view is located (e.g., the second database server 130), is located on the first database server 120, the first database server 120 having the master table Since the second database server 130 having the materialized view can be controlled, high-speed refresh can be implemented between heterogeneous database servers. In other words, the second database server 130 used by the client 110 wanting to view the materialized view does not generate the synchronization command, but the first database server 120 that actually has the master table referenced by the materialized view. You can create a synchronization command using your own materialized view object. In other words, by locating a materialized view object on the first database server 120, the materialized view object references a set of log tables (e.g., DD_SLOG table and/or DD_MLOG table) located on the first database server 120, Determination of whether to perform synchronization and/or generation of a synchronization performance command may be performed on the first database server 120. The logic generator for high-speed refresh may be the first database server 120, and the actual storage of the materialized view may be the second database server 130. Accordingly, the problem that high-speed refresh between heterogeneous DBs is impossible, which occurs because the second database server 130 cannot interpret the log table set of the heterogeneous first database server 120, can be solved.

For example, this synchronization command may include a procedure call to the second database server 130. The procedure here may be stored in the second database server 130 and may interpret and perform synchronization commands (eg, SQL statements) issued from the first database server 120. Additionally, the synchronization command may include connection information for access to the materialized view. Additionally, the synchronization command may include a database manipulation language (DML) for controlling the second database server 130 (eg, INSERT INTO CONT_TBL@DBLINK). That is, the synchronization command synchronizes log information in the log table set that exists in the first database server 120 and is associated with the master table to the second materialized view log table or materialized view table (i.e., , container table).

Then, the first database server 120 transmits the generated synchronization command to the second database server 130, thereby allowing the second database server 130 to perform high-speed refresh (407).

Additionally, when synchronization is completed, the first database server 120 changes the last synchronization time in the DD_SLOG table to the current time and sets the minimum value (youngest last refresh time) and maximum value (oldest last) in the DD_MLOG table. refresh time) information can be changed, and unnecessary change data can be removed from the first materialized view log table. For example, when a completion message is received from the second database server 130 or when the first database server 120 transmits a synchronization command to the second database server 130, it may be determined that the synchronization performance is complete. .

Although the above disclosure has been shown and described with reference to the preceding examples, it should be understood that other forms, details, and implementations may be made without departing from the spirit and scope of the disclosure, as defined by the following claims.

Claims (3)

As a method of automatically registering static data,
determining to perform synchronization on a materialized view existing in a second database server located remotely from the first database server;
In response to a decision to perform synchronization, generating a synchronization command to be transmitted to the second database server; and
Transmitting the generated synchronization command to the second database server to cause the second database server to perform synchronization between the materialized view existing in the second database server and the master table existing in the first database server steps;
Includes,
The above synchronization command is:
Of static data, including a command for inserting log information from a set of log tables that exists in the first database server and is associated with the master table into a second materialized view log table that exists in the second database server. How to auto-enroll. According to claim 1,
The log table set is,
a first materialized view log table containing data changes in the master table;
a DD (data dictionary)_SLOG table that stores at least one of information about the materialized view referencing the master table and information about the last synchronization time for the materialized view; and
A DD_MLOG table that stores maximum (youngest last refresh time) and minimum (oldest last refresh time) information regarding the last synchronization time for the materialized view;
A method of automatically registering static data, including at least one of the following. According to claim 2,
When the synchronization is completed,
Changing the last synchronization time in the DD_SLOG table to the current time;
Changing maximum value (youngest last refresh time) and minimum value (oldest last refresh time) information in the DD_MLOG table; and
removing unnecessary change data from the first materialized view log table;
A method for automatically registering static data, including.