Method and system for processing query messages over a network
Abstract
This record has no abstract on file.
Term
Term ended
Expired 1 November 2022, 3.9 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
30 claims: 8 independent, 22 dependent
- 1ネットワークを通して遠隔データベースを更新する方法において、 前記ネットワークに接続されている少なくとも1つのプロセッサと、前記プロセッサに結合されたメモリとを具備し、そのメモリは、ローカルデータベースと、前記ネットワークを通して前記遠隔データベースを更新するために前記プロセッサにより実行される命令を含んでいる、コンピュータを用いて、 ローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を 生成 し、 ネットワークを通して前記遠隔データベースへ前記複数の周期的な更新 データ を送信し、 前記複数の周期的な更新 データ を 生成 しながら、 初期化更新データ 生成 の開始時間における前記ローカルデータベースのバージョンを含んでいる初期化更新データを 生成 し、 前記開始時間に基づいて前記複数の周期的な更新 データ の中から最新の周期的な更新 データ を決定し、 前記開始時間に基づいて最新のトランザクションを決定し、 前記初期化更新データ、最新の周期的な更新 データ の識別子、最新のトランザクション識別子をネットワークを通して前記遠隔データベースへ送信するステップを含んで おり、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 方法。
- 2前記初期化更新データを送信する前記ステップは、 前記最新の周期的な更新 データ の識別子を前記最新の周期的な更新 データ に関連付け、 前記最新のトランザクション識別子を前記最新のトランザクションに関連付けるステップを含んでいる請求項1記載の方法。
- 3前記複数の周期的な更新 データ は前記ローカルデータベースで規則的または不規則な間隔で生 成 される請求項1記載の方法。
- 4前記初期化更新データ 生成 の開始時間は、周期的な更新 データ の 生成 の開始時間と同じである請求項1記載の方法。
- 5前記初期化更新データ 生成 の開始時間は、周期的な更新 データ の 生成 の開始時間よりも後である請求項1記載の方法。
- 6周期的な更新 データ は複数のトランザクション の内容を表わしているデータ を含んでおり、複数のトランザクションのそれぞれは特有のトランザクション識別子を有している請求項1記載の方法。
- 7ネットワークを通して遠隔データベースを更新する方法において、 ネットワークに接続された少なくとも1つのプロセッサと、前記プロセッサに結合されたメモリとを具備し、そのメモリは、前記遠隔データベースと、前記ネットワークを通して前記遠隔データベースを更新するために前記プロセッサにより実行される命令を含んでいる、コンピュータを用いて、 ネットワークを通してローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を受信し、 前記ネットワークを通して、初期化更新データ 生成 の開始時間におけるローカルデータベースのバージョンを含んでいる初期化更新データを受信し、 前記初期化更新データから最新の周期的な更新 データ の識別子を読取り、 前記初期化更新データから最新のトランザクション識別子を読取り、 前記最新の周期的な更新 データ の識別子から最新の周期的な更新 データ を決定し、前記最新の周期的な更新 データ の決定は前記開始時間に基づいており、 前記最新のトランザクション識別子から最新のトランザクションを決定し、前記最新のトランザクションの決定は前記開始時間に基づいており、 前記最新のトランザクションの後に 生成 されたトランザクションを遠隔データベースへ供給し、 前記最新の周期的な更新 データ の後に 生成 された前記周期的な更新 データ を遠隔データベースへ供給するステップを含んで おり、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 方法。
- 8前記最新のトランザクションを決定した後に、前記初期化更新データ 生成 の開始時間よりも前の時間で生 成 された前記周期的な更新 データ を廃棄するステップをさらに含んでいる請求項7記載の方法。
- 9前記複数の周期的な更新 データ は、規則的な間隔で一度に1つ受信される請求項7記載の方法。
- 10前記複数の周期的な更新 データ は、周期的な間隔でバッチで受信される請求項7記載の方法。
- 11周期的な更新 データ は複数のトランザクション の内容を表わしているデータ を含み、各複数のトランザクションは特有のトランザクション識別子を有している請求項7記載の方法。
- 12ネットワークを通して遠隔データベースを更新する方法において、 前記ネットワークに接続されている少なくとも1つのプロセッサと、前記プロセッサに結合されたメモリとを具備し、そのメモリは、ローカルデータベースと、前記ネットワークを通して前記遠隔データベースを更新するために前記プロセッサにより実行される命令を含んでいる、コンピュータを用いて、 ローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を 生成 し、 初期化更新データ 生成 の開始時間におけるローカルデータベースのバージョンを含んでいる初期化更新データと、前記開始時間前に 生成 された最新の周期的な更新 データ に関連する更新 データ の識別子と、前記開始時間前に与えられた最新のトランザクションに関連するトランザクション識別子とを 生成 し、 前記初期化更新データと、前記更新 データ の識別子と、前記トランザクション識別子とをネットワークを通して前記遠隔データベースへ送信するステップを含んで おり、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 方法。
- 13前記複数の周期的な更新 データ は規則的な間隔で 生成 される請求項12記載の方法。
- 14前記複数の周期的な更新 データ は不規則な間隔で 生成 される請求項12記載の方法。
- 15前記初期化更新データ 生成 の開始時間は、周期的な更新 データ の 生成 の開始時間と同じである請求項12記載の方法。
- 16前記初期化更新データ 生成 の開始時間は、周期的な更新 データ の 生成 の開始時間よりも後である請求項12記載の方法。
- 17ネットワークを通して遠隔データベースを更新するシステムにおいて、 ネットワークに接続されている少なくとも1つのプロセッサと、 前記プロセッサに結合されたメモリとを具備し、 前記メモリは、ローカルデータベースと、前記ネットワークを通して前記遠隔データベースを更新する方法を行うために前記プロセッサにより実行される命令とを含んでおり、前記更新する方法は、 ローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を 生成 し、 前記ネットワークを通して前記遠隔データベースへ前記複数の周期的な更新 データ を送信し、 前記複数の周期的な更新 データ を 生成 しながら、 初期化更新データ 生成 の開始時間における前記ローカルデータベースのバージョンを含んでいる初期化更新データを 生成 し、 前記開始時間に基づいて前記複数の周期的な更新 データ の中から最新の周期的更新 データ を決定し、 前記開始時間に基づいて最新のトランザクションを決定し、 前記初期化更新データ、最新の周期的な更新 データ の識別子、最新のトランザクション識別子を前記ネットワークを通して前記遠隔データベースへ送信するステップを含んで おり 、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 システム。
- 18前記初期化更新データを送信する前記ステップは、 前記最新の周期的な更新 データ の識別子を前記最新の周期的な更新 データ に関連付け、 前記最新のトランザクション識別子を前記最新のトランザクションに関連付ける請求項17記載のシステム。
- 19前記複数の周期的な更新 データ は前記ローカルデータベースで規則的または不規則な間隔で発生成される請求項17記載のシステム。
- 20前記初期化更新データ 生成 の開始時間は、周期的な更新 データ の 生成 の開始時間と同じである請求項17記載のシステム。
- 21前記初期化更新データ 生成 の開始時間は、周期的な更新 データ生成 の開始時間よりも後である請求項17記載のシステム。
- 22周期的な更新 データ は複数のトランザクション の内容を表わしているデータ を含んでおり、複数のトランザクションのそれぞれは特有のトランザクション識別子を有している請求項17記載のシステム。
- 23ネットワークを通して遠隔データベースを更新するシステムにおいて、 ネットワークに接続される少なくとも1つのプロセッサと、 前記プロセッサに結合されたメモリとを具備し、 前記メモリは、遠隔データベースと、前記ネットワークを通して前記遠隔データベースを更新する方法を行うために前記プロセッサにより実行される命令とを含んでおり、その更新方法は、 前記ネットワークを通してローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を受信し、 前記ネットワークを通して、初期化更新データ 生成 の開始時間における前記ローカルデータベースのバージョンを含んでいる初期化更新データを受信し、 前記初期化更新データから最新の周期的な更新 データ の識別子を読取り、 前記初期化更新データから最新のトランザクション識別子を読取り、 前記最新の周期的な更新 データ の識別子から最新の周期的な更新 データ を決定し、前記最新の周期的な更新 データ は前記開始時間に基づいており、 前記最新のトランザクション識別子から最新のトランザクションを決定し、前記最新のトランザクションは前記開始時間に基づいており、 前記最新のトランザクションの後に 生成 されたトランザクションを前記遠隔データベースへ供給し、 前記最新の周期的な更新 データ の後に 生成 された前記周期的な更新 データ を前記遠隔データベースへ供給するステップを含んで おり 、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 システム。
- 24さらに、前記最新のトランザクションを決定した後に、前記初期化更新データ発生の開始時間よりも前の時間で 生成 された前記周期的な更新 データ を廃棄する請求項23記載のシステム。
- 25前記複数の周期的な更新 データ は、規則的または不規則の間隔で、一度に1つ受信される請求項23記載のシステム。
- 26前記複数の周期的な更新 データ は、規則的または不規則の間隔で、バッチで受信される請求項23記載のシステム。
- 27周期的な更新 データ は複数のトランザクション の内容を表わしているデータ を含み、複数のトランザクションのそれぞれは特有のトランザクション識別子を有し、トランザクション識別子はランダムな順序である請求項23記載のシステム。
- 28ネットワークを通して遠隔データベースを更新する方法をプロセッサにより実行させるプログラム命令を含んでいるマシーンの読取り可能な媒体において、この方法は、 ローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を 生成 し、 前記ネットワークを通して前記遠隔データベースへ前記複数の周期的な更新 データ を送信し、 前記複数の周期的な更新 データ を 生成 しながら、 初期化更新データ 生成 の開始時間におけるローカルデータベースのバージョンを含んでいる初期化更新データを 生成 し、 前記開始時間に基づいて前記複数の周期的な更新 データ の中から最新の周期的 な 更新 データ を決定し、 前記開始時間に基づいて最新のトランザクションを決定し、 最新の周期的な更新 データ の識別子を前記最新の周期的な更新 データ に関連付け、 最新のトランザクション識別子を前記最新のトランザクションに関連付け、 前記初期化更新データ、前記最新の周期的な更新 データ の識別子、前記最新のトランザクション識別子を前記ネットワークを通して前記遠隔データベースへ送信するステップを含んで おり 、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 マシーンの読取り可能な媒体。
- 29ネットワークを通して遠隔データベースを更新する方法をプロセッサにより実行させるプログラム命令を含んでいるマシーンの読取り可能な媒体において、この方法は、 前記ネットワークを通してローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を受信し、 前記ネットワークを通して、初期化更新データ 生成 の開始時間におけるローカルデータベースのバージョンを含んでいる初期化更新データを受信し、 前記初期化更新データから最新の周期的な更新 データ の識別子を読取り、 前記初期化更新データから最新のトランザクション識別子を読取り、 前記最新の周期的な更新 データ の識別子から最新の周期的な更新 データ を決定し、前記最新の周期的な更新 データ は前記開始時間に基づいており、 前記最新のトランザクション識別子から最新のトランザクションを決定し、前記最新のトランザクションは前記開始時間に基づいており、 前記最新のトランザクションの後に 生成 されたトランザクションを前記遠隔データベースへ供給し、 前記最新の周期的な更新 データ の後に 生成 された周期的な更新 データ を前記遠隔データベースへ供給するステップを含んで おり 、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 マシーンの読取り可能な媒体。
- 30ローカルデータベースに対するインクリメント変化に基づいた、それぞれ少なくとも1つのトランザクション の内容を表わしているデータ を有している複数の周期的な更新 データ を 生成 する手段と、 初期化更新データ 生成 の開始時間におけるローカルデータベースのバージョンを含んでいる初期化更新データを 生成 し、更新 データ の識別子を前記開始時間前に 生成 された最新の周期的な更新 データ に関連付け、トランザクション識別子を前記開始時間前に与えられた最新のトランザクションに関連付ける手段と、 前記初期化更新データと、前記更新 データ の識別子と、前記トランザクション識別子とをネットワークを通して遠隔データベースへ送信する手段とを含んで おり 、 前記最新の周期的な更新データは、初期化更新データ生成の開始時間前に生成された周期的な更新データの内の最後に生成された周期的な更新データであり、 前記最新のトランザクションは初期化更新データ生成の開始時間前に与えられたトランザクションの内の最後のトランザクションである、 更新 データ 生成装置。
Independent claims30
86 paragraphs, as filed
An embodiment of the present invention relates to a computer database, particularly to a method and system for reliably updating the database.
This non-provisional application is a US patent provisional application No. 60 / 330,842, filed November 1, 2001, with reference in its entirety, and a US patent provisional application filed on March 19, 2002, with reference to the whole. Claims the advantages of Application No. 60 / 365,169.
The increasing size and high distributability of databases makes it very difficult to ensure that related databases in the network contain the same version of data. If there are significant changes to one database, the other databases should be updated to include these changes as much as possible. Performing these updates involves frequently moving large amounts of data to be updated to a large number of databases. The potential complexity of such a process is enormous.
<p> This problem is exacerbated in systems where communication is not reliable. In this case, the data may be lost during the transfer. As a result, the data will be sent again and all other databases will have to be updated again. Such iterations significantly reduce the efficiency of the system and the extent to which the database contains updated data.</p>
<p> Embodiments of the present invention provide a method and system for reliably updating a remote database over a network. In the embodiment, a plurality of periodic updates (hereinafter referred to as "transmission files") are performed based on incremental changes to the local database. Each periodic update contains at least one transaction. An initialization update (hereinafter outgoing file initialization) that includes the version of the local database at the disclosure time is performed. In addition, an identifier associated with the latest periodic update made before the start time and an identifier associated with the latest transaction made before the start time are generated. The embodiment effectively releases the transmission file and initializes the transmission file in order to surely update the remote database.</p>
FIG. 1 is a block diagram showing a system according to one embodiment of the present invention. In general, system 100 hosts a database that resides in large memory, receives search requests, and provides search responses over the network. For example, System 100 includes IBM RS / 6000 (R) M80 or S80 manufactured by International Business Machines in Armonk, New York, and Sun Enterprise (brand name) 1000 manufactured by Sun Microsystems in Santa Clara, California. It may be a symmetric multiprocessing (SMP) computer such as. System 100 may also be a multiprocessor personal computer such as the Compaq ProLiant ML530 (including two Intel Pentium (R) III 866 MHz processors) manufactured by the Hewlett-Packard Company of Palo Alto, California. Good. System 100 is, for example, IBM AIX (R) 4, Sun Solaris (trade name) 8 It may include a multi-processing operating system such as Operating Environment, Red Hat Linux (R) 6.2, etc. System 100 receives regular updates on network 124, which are also included in the database. Embodiments of the present invention can achieve very high database searches and updates by including each update in the database without using database locking or access control.
In one embodiment, system 100 includes at least one processor 102-1 coupled to bus 101. Processor 102-1 may include an internal memory cache (eg, L1 cache, not explicitly indicated). The secondary memory cache 103-1 (eg, L2 cache, L2 / L3 cache, etc.) exists between processor 102-1 and bus 101. In a preferred embodiment, system 100 may include multiple processors 102-1 ... 102-P coupled to bus 101. Multiple secondary memory caches 103-1 ... 103-P also exist between multiple processors 102-1 ... 102-P and bus 101 (eg lookaside architecture), or at least one instead. Two secondary memory caches 103-1 are coupled to bus 101 (eg lookaside architecture). System 100 includes memory 104, such as random access memory (RAM) coupled to bus 101, for recording information and instructions executed by multiple processors 102-1 ... 102-P. ..
Memory 104, for example, translates an internet domain name into an internet address, translates a name or phone number into a network address, provides and updates subscriber profile data, and provides a large database for providing and updating the user's current data. I remember. Both the size of the database and the number of transactions per second are useful when they are very large. For example, memory 104 contains at least 64GB of RAM and is 500M (ie 500x10).<sup>6</sup>) Includes record domain name database, 500M record subscriber database, 450M record phone number portable database, etc.
For example, in an exemplary 64-bit system architecture that includes at least one 64-bit big endian processor 102-1 coupled to at least 64-bit bus 101 and 64-bit memory 104, an 8-byte pointer value is a single interrupt. It is written to an 8-byte boundary memory address (ie, a memory address divisible by 8 or eg 8N) using non-possible behavior. Normally, the presence of the secondary memory cache 103-1 simply delays the writing of the 8-byte pointer to memory 104. For example, in one embodiment, the secondary memory cache 103-1 is a look-through cache that operates in write-through mode, so that a single 8-byte storage instruction can be interrupt-free and clock cycles of as few as two systems. Moves 8 bytes of data from processor 102-1 to memory 104. In another embodiment, the secondary memory cache 103-1 is a look-through cache that operates in write-back mode, which first writes an 8-byte pointer to the secondary memory cache 103-1, which is then An 8-byte pointer at a later time, such as when a cache line that stores an 8-byte pointer is written to memory 104 (ie, for example, when a particular cache line or the entire secondary memory cache is "flushed"). Write to memory 104.
Finally, from the figure of processor 102-1, once the data is latched on the output pin of processor 102-1, all 8 bytes of data are written to memory 104 in one adjacent uninterrupted transfer, which Is delayed by the effect of the secondary memory cache 103-1 if it exists. From the diagram of processors 102-2 ... 102-P, once the data is latched on the output pin of processor 102-1 all 8 bytes of data are written to memory 104 in one adjacent uninterrupted transfer. , This is enhanced by the cache coherency protocol across the secondary memory cache 103-1 ... 103P, delaying writes to memory 104 if present.
However, if an 8-byte pointer value is written to a misaligned position in memory 104, such as a memory address that crosses an 8-byte boundary, then all 8 bytes of data use a single 8-byte storage instruction. Cannot be transferred from processor 102-1. Instead, processor 102-1 can generate two separate and different storage instructions. For example, if the memory address starts with 4 bytes before the 8-byte boundary (eg 8N-4), the first storage instruction transfers the four high-order bytes to memory 104 (eg 8N-4) and the second The storage instruction transfers the four least digit bytes to memory 104 (eg 8N). Importantly, between these two separate storage instructions, processor 102-1 is not interrupted, or processor 102-1 controls bus 101 to another system component (eg processor 102-P, etc.). You may lose. As a result, the pointer value located in memory 104 is invalid until processor 102-1 can complete the second storage instruction. If another component initiates a single non-interruptable memory read to this memory location, the invalid value is probably returned as a valid value of 1.
Similarly, the new 4-byte pointer value is written to a memory address divisible by 4 (eg 4N) using a single non-interruptible behavior. Note that in the above example, the 4-byte pointer value is written to the 8N-4 memory location using a single storage instruction. Of course, if a 4-byte pointer value is written across a 4-byte boundary, eg 4N-2, then all 4 bytes of data can be transferred from processor 102-1 using a single storage instruction. It cannot, and the pointer value existing in memory 104 is invalid for some time period.
System 100 also includes read-only memory (ROM) 106, or other static storage, coupled to bus 101 to store static information and instructions for processor 102-1. A storage device 108, such as a magnetic or optical disk, is coupled to a bus 101 to store information and instructions. System 100 also includes a display 110 (eg LCD monitor) and an input device 112 (eg keyboard, mouse, trackball, etc.) coupled to bus 101. System 100 includes multiple network interfaces 114-1 ... 114-Q, which transmit and receive electrical, electromagnetic or optical signals with digital data streams representing various types of information. In one embodiment, network interface 114-1 is coupled to bus 101 and local area network (LAN) 122, while network interface 114-O is coupled to bus 101 and wide area network (WAN) 124. Multiple network interfaces 114-1 ... 114-O are, for example, Gigabit Ethernet (R) (eg IEEE Standard 802.3-2002 published in 2002), Fiber Channel (eg ANSI Standard X.3230-1994 published in 1994), etc. Supports various network protocols including. Multiple network computers 120-1 ... 120-N are coupled to LAN122 and WAN124. In one embodiment LAN 122 and WAN 124 may be physically different networks, while in another embodiment LAN 122 and WAN 124 are via a network gateway or router (not explicitly shown). Alternatively, LAN122 and WAN124 may be the same network.
As mentioned above, System 100 may provide DNS resolution services. In the DNS resolution embodiment, the DNS resolution service is usually divided between network forwarding and lookup functions. For example, System 100 is a back-end lookup engine (LUE) optimized for data lookup of large datasets, while multiple network computers 120-1 ... 120N are optimized for network processing and forwarding. Multiple front-end protocol engines (PEs). LUE is in memory 104 to encourage fast, high throughput searches and updates<u style="single">DNS</u>A powerful multiprocessor server that stores the entire recording set. In an alternative embodiment<u style="single">DNS</u>Resolution services are provided by a series of powerful microprocessor servers or LUEs, each in memory to drive high-speed, high-throughput searches and updates.<u style="single">DNS</u>Memorize a subset of the entire recording set.
Conversely, multiple PEs are machines that operate a PC-based and efficient multitasking operating system with a typical low profile (eg Red Hat Linus (R) 6.2).<u style="single">DNS</u>Minimize network processing transfer load in LUE to maximize resources available for resolution. PE is wire line<u style="single">DNS</u>Manages protocol nuances and responds to invalid DNS queries and multiple valid DNS queries to LUEs via LAN122. In an alternative embodiment involving a large number of LUEs that store a subset of DNS records, the PE is each valid for the appropriate LUE.<u style="single">DNS</u>Determines the LUE that receives queries and multiple valid DSN queries. The number of PEs for a single LUE is processed, for example, every second<u style="single">DNS</u>Determined by the number of queries and the performance characteristics of a particular system. Other calculations may also be used to determine the appropriate mapping ratio and mode of operation.
Other high volume query-based embodiments are typically supported, including, for example, telephone number resolution, SS7 signaling processing, ground position determination, telephone number to subscriber mapping, subscriber location, existence determination, and the like.
In one embodiment, the central online transaction processing (OLTP) server 140-1 is coupled to WAN124 to receive add, modify and erase (ie update traffic) to database 142-1 from various sources. The OLTP server 140-1, which contains a local copy of database 142-1, sends updates to system 100 over WAN124. OLTP server 140-1 is Hyper Text Transmission Protocol (HTTP), Registry Registrar Protocol (RRP), Extensible Provisioning Protocol (EPP), Service Management System / 800 Mechanized Generic Interface Optimized for handling update traffic in various formats and protocols, including (MGI) and other online protocol. The read-only LUE constellation is deployed in hub and spoke architectures to provide high-speed search capabilities that combine with high-capacity incremental updates from OLTP server 140-1.
In an alternative embodiment, the data is distributed across a number of OLTP servers 140-1 ... 140-S, each coupled to WAN124. OLTP servers 140-1 ... 140-S add, modify, erase (ie update traffic) from various sources to their respective databases 142-1 ... 142-S (not explicitly shown). Receive. The OLTP server 140-1 ... 140-S, which may contain a copy of database 142-1 ... 142-S and other dynamically generated data, etc., sends updates to system 100 via WAN124. For example, in a ground-based embodiment, OLTP servers 140-1 ... 140-S receive update traffic from a group of remote sensors. In another alternative embodiment, multiple network computers 120-1 ... 120-N also receive add, modify, erase (ie update traffic) from various sources across WAN124 or LAN122. In this embodiment, the plurality of network computers 120-1 ... 120-N send updates to system 100 as well as inquiries.
In a DNS resolution embodiment, each PE (eg, multiple network computers 120-1 ... 120-N) combines several DNS query messages received over a wide area network (eg WAN124) into a single request superpacket. Alternatively, it is multiplexed and the request super packet is transmitted to the LUE (for example, system 100) via the premises network (for example, LAN122). The LUE combines or multiplexes several DNS query message responses into a single response superpacket and sends the response superpacket over the campus network to the appropriate PE. Generally, the maximum size of a request or response superpacket is limited by the maximum transmission unit MTU (eg Gigabit Ethernet (R)) of the physical network layer. For example, a typical DNS query and response message size smaller than 100 bytes or 200 bytes each allows more than 30 queries to be multiplexed into a single request superpacket, with more than 15 responses being a single. Allows multiplexing into response superpackets. However, a smaller number of queries (eg 20 queries) are included in a single request superpacket to avoid MTU overflow of responses (eg 10 responses). For larger MTU sizes, the number of multiplexed queries and responses may therefore be increased.
Each multitasking PE contains inbound and outbound threads to manage DNS queries and responses, respectively. For example, an inbound thread dealigns DNS query components from incoming DNS query packets received over a wide area network and multiplexes a few milliseconds of the query into a single request superpacket. The inbound thread then sends a request superpacket to the LUE over the campus network. Conversely, the outbound thread receives a response superpacket from the LUE, demultiplexes the response it contains, aligns the various fields into a valid DNS response, which is then sent over the wide area network. In general, as mentioned above, other high volume query-based embodiments are supported.
In one embodiment, the request superpacket also contains state information associated with each DNS query, such as source address, protocol type, and so on. The LUE contains the state information and the associated DNS response in the response superpacket. Each PE then uses the information sent by the LUE to reconfigure a valid DNS response message. As a result, each PE effectively acts as a stateless machine, i.e. a valid DNS response is formed from the information contained in the response superpacket. Normally, the LUE returns the response superpacket to the PE where the incoming superpacket was generated, and it is clear that other changes are possible.
In another embodiment, each PE maintains the state information associated with each DNS query and contains or processes criteria for the state information in the request superpacket. The LUE contains the state information criteria and the associated DNS response in the response superpacket. Each PE then reconfigures a valid DNS response message using the status information criteria sent by the LUE and the status information maintained therein. In this embodiment, the LUE returns a response superpacket to the PE where the incoming superpacket was generated.
FIG. 2 is a block diagram of a hub and spoke architecture according to one embodiment of the present invention. Normally the system is connected to the local database 200 (which may be included in the central OLTP hub 140) and to the local database 200 (may be included in the LUE 100) by any connection mechanism such as the Internet or LAN122. ) Contains one or more remote databases 210. The database sends and receives update data.
Referring to FIG. 3, in one embodiment of the present invention, the local database 200 sends F transmission files 300-1 ... 300-F and initialization transmission files 310 to the remote database 210 in order to update the remote database 210. Send. Update files include many send files 300 and one send file 300 and one initialization send file 310, many send files 300 and one initialization send file 310, send file 300 alone, or initialization send file 310 alone. Can be sent individually or in batches, such as.
In one embodiment of the invention, processor 104 receives transmit file 300 and / or initialization transmit file 310 containing updated data from the local database 200. The system 150 receives the transmit file 300 and the initialization transmit file 310 at the remote database 210 via the communication interface 118. Processor 104 then compares the updated data in transmit file 300 or initialization transmit file 310 with the corresponding data in remote database 210. If the data is different in the remote database 210, the processor 104 supplies the transmit file 300 or the initialization transmit file 310 to the remote database 210. The remote database 210 can therefore have updated data that matches the updated data in the local database 200 as a result.
FIG. 4 shows a transmission file 300 according to one embodiment of the present invention. The fields of file 300 are, for example, file identifier 400, file occurrence time 402, number of transactions in file N404, total file size 406, checksum or any such error check indicator 408, transaction (including transaction identifier). Contains 410-1 ... 410-N. These transmit file fields are exemplary and are not intended to limit the technical scope of the embodiments of the present invention. Any valid field can be included in the send file 300.
Outgoing file 300 contains changes to the local database 200 between two points in time. These changes include, for example, adding a new identifier (ie, an identifier for a data record), erasing an existing identifier, changing one or more data records associated with an identifier, renaming an identifier, no-op, and so on. One or more of these changes are made in sequence, called a transaction, and the transmit file 300 contains a unique identifier for these transactions. Transactions are recorded in send file 300 as they are done in the local database 200. For transactions that contain more than one change, the changes are recorded within the transaction in the order in which they are made in the local database 200.
In general, transaction identifiers are assigned to transactions in any order. That is, the transaction identifier does not have to increase monotonically over time. For example, two consecutive transactions have a transaction identifier of 10004 followed by 10002. Therefore, the order in which transactions occur is determined by their position in the current file 300-F or the position of the preceding file 300- (F-1). Transactions typically do not include the range of adjacent files 300 to fully complete the remote database update within the application for one outbound file. This prevents update interruptions due to network delays, which can result in erroneous data in the remote database 210.
FIG. 5 shows an initialization transmission file 310 according to one embodiment of the present invention. The fields of the initialization file 310 are, for example, file identifier 500, file occurrence time 502, number of transactions in the file N504, total file size 506, checksum or any such error check indicator 508, local database (data). Contains the entire copy 516. The initialization send file 310 also includes field 510, which is the file identifier 400 of the latest send file 300 that occurred before the occurrence of file 310, and the identifier of the latest transaction given to the local database 200 before the occurrence of file 310. Contains field 512, which is. The data in the local and remote databases 200, 210 is assigned to the tables that exist in the databases 200, 210. Databases 200 and 210 support any number of tables. When the database has tables, the initialization send file 310 contains fields for each table that indicate the number of records recorded in the table. For example, a domain name database contains a domain table and a name server table. Therefore, the initialization transmission file can include a field that indicates a large number of records in the domain table and a field that indicates the number of records in the name server table. The fields specify, for example, the table name, the key used to index the table's records, and the number of records in the table. In addition, the initialization transmission file 310 contains a field indicating the version of the initialization transmission file 310, usually 1.0. These initialization transmission file fields are illustrated by way of example and are not intended to limit the technical scope of the embodiments of the present invention. Any valid field can be included in the initialization send file 310.
The initialization send file 310 contains a read-matched copy of the entire local database 200, for example as described above. The initialization send file 310 becomes consistent with the local database 200 at the point of time t between ts and tf, where ts is the time when the initialization send file 310 starts to occur and tf is the time when it occurs. It's time to finish. In this way, the only action performed on the initialization transmission file 310 is the "addition" action. That is, when the initialization transmission file 310 is generated, a copy of the entire local database 200 at time t is recorded in the initialization transmission file 310. Therefore, the "addition" operation is performed to record the local database 200 in the initialization transmission file 310. The identifiers can be recorded in the initialization transmission file 310 in any order. Instead, in the presence of an external identifier, the referenced data record is recorded before the reference data record.
The addition of fields 510, 512 gives the initialization transfer file 310 recognition of the transmission file 300 that is generated and given to the remote database 210, while the initialization transmission file 310 is being generated. However, the occurrences of the transmit file 300 and the initialization transmit file 310 are separated from each other in that they are independent of the other in their occurrence. Such structures and processes prevent inefficient ways in which transmission file generation and supply are initialized and aborted until transmission file generation is complete. By generating and continuing to supply the transmission file 300 while generating the initialization transmission file 310 as in one embodiment of the present invention, a powerful error check of the transmission file 300 is performed, and similarly in the remote database 210. Constraints, such as specific constraints or external identifier constraints, are set. Setting constraints protects the data integrity of the remote database 210 by rejecting transactions that violate the relevant model of the remote database 210. For example, a unique constraint prevents the same key from being stored in database 210 more than once.
FIG. 6 is an exemplary timing chart of the generation of the transmission file and the initialization transmission file according to one embodiment of the present invention. In FIG. 6, the transmission files 300 (sf-1 to s-21) are generated at regular time intervals. In another embodiment, the transmit file 300 may occur at irregular time intervals. Normally, the transmission file does not occur over the entire time interval. For example, if the files occur at 5-minute intervals, do not take all 5 minutes to complete the file generation. Further, if changes occur in the local database 200 while the transmit file 300 is occurring, these changes will be captured in the next transmit file 300. For example, if the outbound file sf-4 starts spawning at 12:05:00 and completes at 12:05:02, then the changes to the local database 200 that occurred between 12:05:00 and 12:05:02. Is captured in the transmit file sf-5 (eg 300-5), which captures the time period from 12:05:00 to 12:10:00.
Transmission files 300-5 and 300-19 are shown in Figure 6. Among the other fields, these files show the file identifier 601 (sf-5, sf-19), the file occurrence time 603, and the transaction identifier 605 (eg 10002). Note that transaction identifiers are not monotonously ordered. As mentioned above, the transaction identifier may have a random value. However, the associated transactions themselves are recorded in the send file 300 in the order in which they occurred in the local database 200.
Since the generation of the initialization transmission file 310 and the generation of the transmission file 300 may be separated, the initialization transmission file 310 can be generated at any time. For example, the initialization transmission file 310 may be generated before, during, or after the generation of the transmission file 300. FIG. 6 shows the initialization transmit file 310 that occurs at the midpoint between the 4th and 5th transmit files (eg sf-4 and sf-5).
In one embodiment, the initialization send file 310, among other fields, has a file identifier of 610 (isf-1), a file identifier of the latest send file generated before the occurrence of the initialization send file, 615, and an initialization send. It may contain the transaction identifier 620 of the latest transaction given before the file occurred. In this example, the most recent outbound file generated is outbound file sf-4 and the latest given transaction is transaction 10001. Initialization transmit file 310 starts occurrence 611 at 12:07:29. The first half of the outbound file 300-5 (sf-5) transactions, transactions 10002, 10005, 10001, have already been given to the local database 200 when the initialization outbound file 310 begins to occur. Therefore, the initialization transmission file 310 recognizes these transactions, and the initialization transmission file 310 captures these transactions. However, the initialization transmit file 310 cannot recognize subsequent transactions 10003 and 10004 that occur after the initiation of the initialization transmission file.
Initialization transmission file 310 is generated, and transmission files starting with transmission file 300-5 continue to be generated at regular intervals. These files are sent to and supplied to the remote database 210.
Initialization transmission file 310 is the midpoint of the occurrence of the 18th and 19th transmission files 300 (sf-18 and sf-19), completes the generation at 1:15:29, and the 19th transmission file 300-19. Does not affect the occurrence of.
After the remote database 210 receives and loads the initialization send file 310, the remote database 210 does not consider the send files that occurred before the initialization send file 310 occurred. This is because, for example, the initialization send file 310 contains all changes to the local database 200 recorded in the previous send file 300. In this example, the remote database 210 does not need to consider the first to fourth transmit files (sf-1 to sf-4). The changes recorded in these transmission files sf-1 to sf-4 can also be recorded in the initialization transmission file 310. These destination transmission files (sf-1 to sf-4) may be deleted or archived instead. Similarly, the remote database 210 does not consider transactions given before the occurrence of the initialization send file 310 contained in the send file 300 that occurs later. The initialization send file 310 contains these transactions when the initialization send file 310 occurs. For example, the remote database 210 does not need to consider the first three transactions 10002, 10005, 10001 of the send file sf-5 for these transactions. These transactions recorded in sf-5 can also be recorded in the initialization transmission file 310. These given transactions may be erased or archived instead.
FIG. 7 is a flowchart of one embodiment of the present invention in which an update file of a local database is generated. The system will generate multiple periodic updates (at 705) based on incremental changes to the local database. Each update contains one or more transactions. The system then sends periodic updates (at 710) to the remote database. While regular updates occur, the system begins to generate initialization updates at the start time (at 715). The initialization update contains the version of the entire local database. The system can determine the latest periodic updates that occur before the start time and the latest transactions that will be given before the start time. The system then sends an initialization update (at 725) to the remote database. The initialization update includes an update identifier associated with the latest periodic update that occurs and a transaction identifier associated with the latest transaction given.
For example, OLTP140 generates send file 300 at some regular or irregular time intervals (at 705). The OLTP140 then (at 710) sends the send file 300 to the remote database 210. While the transmit file 300 is generated, the OLTP140 begins to generate the initialization transmit file 310 at start time 611 (at 715). The initialization send file 310 contains a copy of the local database 200. The OLTP140 is then given (at 720) the latest send file 300, which occurs before the start time 611 due to the occurrence of the initialization send file 310, and the latest given before the start time 611 due to the occurrence of the initialization send file 310. Determine the transaction. OLTP140 then sends the initialization send file 310 (at 725) to the remote database 210. The initialization send file 310 contains a send file identifier 615 associated with the latest sent file 300 generated and a transaction identifier 620 associated with the given latest transaction.
FIG. 8 is a flowchart of one embodiment of the present invention in which the remote database receives the update file from the local database. The system receives multiple regular updates (at 805). Each update contains one or more transactions. Regular updates are received individually or in batches. The system receives an initialization update at some time (at 810). The initialization update contains the version of the entire local database. The system reads the latest periodic update identifier (at 815) and the latest transaction identifier from the initialization update. The system then determines (at 820) the latest periodic updates associated with the update identifier and the latest transaction associated with the transaction identifier. Periodic updates and transactions are the latest ones that occurred and were given before the initialization update occurred. The system applies the remaining ungiven transactions of the corresponding periodic update (at 825) to the remote database. The system then supplies the remote database with the remaining periodic updates that occurred after the latest periodic update (at 830). Effectively supplying initialization updates makes up for any previously lost periodic updates.
For example, the LUE100 receives the transmit file 300 (at 805) at several regular or non-regular time intervals. The transmission file 300 is received individually or in batch. The LUE100 receives the initialization send file 310 at some time (at 810). The LUE100 reads the transmit file identifier 615 (at 815) and the transaction identifier 620 from the initialization transmit file 310. The LUE 100 then determines (at 820) the transmit file 300 associated with the transmit file identifier 615 and the transaction 605 associated with the transaction identifier 620. The send file and transaction are the latest ones generated and given before the occurrence of the initialization send file 310, respectively. LUE100 applies the remaining ungiven transaction 605 of the corresponding outbound file 300 (at 825) to the remote database 210. The LUE100 then applies the remaining send file 300 to the remote database 210 after the latest send file sf-4 (at 830).
In another embodiment, for example, the LUE 100 does not give to the remote database 210 and / or discards or archives the transmit file 300 with an occurrence time 603 before the initialization transmit file occurrence time 611. Outgoing file 300 to be discarded or archived contains outbound file sf-4 associated with outbound file identifier 615.
After the initialization send file 310 is given, any later send file 300 already given to the remote database 210 may be lost because the remote database 210 becomes a read match with the initialization send file 310. Will be understood. Therefore, the transmission file 300 after these is given again.
In one embodiment of the invention, the transmit file 300 and the initialization transmit file 310 go from the local database 200 to the remote database 210 without approval, i.e., without an ACK / NACK signal to indicate that the file was properly received. Can be sent. This effectively reduces the overhead generated by the ACK / NACK signal.
In another embodiment, the ACK / NACK signal is sent from the remote database 210 to indicate proper reception of the file. In this embodiment, the ACK / NACK signal is transmitted by an uncertain communication system.
FIG. 9 is a flowchart of another embodiment of the invention in which the system checks for update files sent from the local database and received at the remote database. Here, the system sends multiple periodic updates (at 905). Each update may contain one or more transactions. Regular updates are sent individually or in batches. The system sends an initialization update at some time (at 910) and feeds the initialization update to the remote database. The initialization update contains the version of the entire local database. The system first identifies inconsistencies between local and remote databases by comparing the databases (at 915). The system determines (at 920) whether the mismatch is valid or has an error. The system then (at 925) provides periodic updates to the remote database according to embodiments of the invention. This embodiment ensures that there are no errors in the remote database as a result of receiving updates from the local database.
For example, the OLTP 140 sends the transmit file 300 to the remote database 210 at some regular or irregular time intervals (in 905). The transmission file 300 is transmitted individually or in batches. The OLTP140 sends the initialization send file 310 to the LUE100 at some time (at 910), and the LUE100 sends the initialization send file 310 to the remote database 210. OLTP140 compares the local database 200 with the remote database 210 and identifies discrepancies between them (at 915). OLTP140 then determines (at 920) whether the mismatch is valid or has an error. The OLTP 140 then notifies the LUE 100 (at 925) of giving the transmit file 300 to the remote database 210 according to one embodiment of the invention. The LUE100 then feeds the transmit file 300 to the remote database 210.
In another embodiment, the system identifies the discrepancy and supplies both the transmit file and the initialization transmit file before confirming. Instead, the system can identify and confirm the discrepancy before supplying both the transmit file and the initialization transmit file.
It will be appreciated that the verification process is performed on any data transmitted over the network from the source to the destination for the purpose of delivering the transmitted data to the destination.
FIG. 10A is a flowchart of one embodiment of confirmation of a transmission file and an initialization transmission file according to the present invention. After sending multiple periodic and initialization updates to the remote database, the system reviews these updates. Each update contains one or more transactions made in the local database. Each transaction contains one or more events. Events are database actions or occurrences, such as add, modify, delete, etc., with respect to the data in the database.
First, the system compares the records in the remote database (at 1000) with the corresponding records in the local database. The system raises an exception (at 1005) that describes the discrepancy between the remote and local databases, and an exception is raised for each discrepancy. A discrepancy is any difference in at least one data value between two versions of the same record. For example, the data record in the local database is (12345, xyz.com, 123.234.345). The corresponding data record in the remote database that is supposed to be the same is (12345, abc.com, 123.234.345). Therefore, there is a discrepancy in the second data value of the record. Therefore, one embodiment of the present invention raises an exception that explains this discrepancy. The exception simply indicates that there is a mismatch, identifies the location of the mismatch, describes the mismatch by explaining the difference between the two data values of the mismatch, and so on. If it is assumed that two records contain the same data, then the data record in the local database corresponds to the data record in the remote database (and vice versa).
It will be understood that a discrepancy refers to the difference between one or more data values in a record or its entire record.
The system associates an exception identifier (at 1010) with each exception, and the exception identifier is associated with the record identifier. For example, the data record (12345, xyz.com, 123.234.345) has the identifier d10. Therefore the exception identifier is also d10. Each exception is classified as belonging to any one of a number of exception (or mismatch) types. The exception list is formed to include the exception type and the exception identifier of the exception classified therein. The exception list and different exception types will be described in detail later. The system also associates the event identifier (at 1015) with each update event, and the event identifier is associated with the record identifier. For example, the data record (12345, xyz.com, 123.234.345) has the identifier d10. Therefore, the event identifier is also d10. Each update event is found in the event history. The event history is a list of events that occur for records in the local database over a period of time. The event history will be explained in detail later.
The system then determines (at 1020) whether record updates are valid. FIG. 10B is a flowchart of one embodiment of the confirmation decision. This decision is made as follows. Each event is compared to each exception (at 1022). If each exception is not justified by the event (at 1024), the update is designated as valid (at 1026) and the update is fed to the remote database. Otherwise, if each exception is not justified by the event (at 1024), the update is specified as invalid (at 1028) and the exception is logged as an error. Exceptions are justified when the event identifier corresponds to an exception identifier and the associated event corresponds to a valid sequence of events associated with the exception type. The valid sequences will be described in detail later. If the exception is justified, the system removes the exception identifier from the exception list. The justified exception indicates that the mismatch is valid, for example the remote database has not yet received the update, but will match the local database when the update is received.
During verification, the system identifies potential errors or failures in periodic and initialization updates. The system applies these updates structurally and semantically correctly, these updates without exceptions or otherwise improperly stop, and comparisons between local and remote databases accurately fail. To ensure that high profile data is not accidentally erased. The system ensures that regular and initialization updates are properly delivered to the remote database.
Numerous errors are effectively discovered by attempting to deliver updates to a remote database during verification. For example, a data-centric error, a warning that an object already exists in a remote database, or a warning that there is an external identifier compromise is found during the supply attempt. Therefore, after performing the verification process of the embodiments of the present invention, the system attempts to apply these updates to the remote database. This attempt fails, indicating that there is an additional error during the update that invalidates the update. Therefore, no further attempts are made to apply these updates to the remote database.
In another embodiment, an attempt is made to supply at least one update before performing the confirmation. If the attempt fails, the confirmation is skipped and the update is discarded. On the other hand, if the attempt is successful, a confirmation is performed, valid updates are maintained, and invalid updates are logged due to a mismatch.
In an exemplary embodiment, the OLTP 140 identifies the transmit file 300 and the initialization transmit file 310 to ensure that the transmit file 300 and the initialization transmit file 310 are properly fed to the remote database 210.
In another embodiment, the network computer 121, LUE100, or any combination of existing systems performs the verification.
With reference to Figure 10A, OLTP140 compares the local database 200 with the remote database 210 and determines any exceptions (or discrepancies) between them. The exceptions include three types, that is, the data resides in the remote database 210 instead of the local database 200, the data resides in the local database 200 instead of the remote database 210, or the corresponding data resides in the local database 200. A type that exists in the remote database 210 but has different data. Of course, the corresponding data exists in the local database 200 and the remote database 210, the data are the same, in which case the data are considered valid and therefore do not require further processing by the OLTP 140.
It will be understood that a discrepancy refers to one or more data values in the record or its entire record.
Therefore, OLTP140 compares the corresponding records of the local database 200 and the remote database 210 (at 1000). OLTP140 raises an exception (at 1005) that describes a discrepancy between the records in the remote database 210 and the records in the local database 200, where an exception is raised for each discrepancy. OLTP140 associates an exception identifier (at 1010) with each exception, and each exception identifier is associated with a record identifier. The exception list is formed to include the exception type and the exception identifier of the exception belonging to the exception type. In one embodiment, an exception is designated as a "List 1" exception (or mismatch) if it belongs to the first exception type, and a "List 2" exception, if the exception belongs to a second exception type. Or if the exception belongs to a third exception type, it is designated as a "List 3" exception. Figure 11 shows an exemplary exception list 1140.
The presence of the exception identifier in the exception list is present in the send file 300 or early, for example because of the time delay between changes to the local database 20 and updates delivered to the remote database 210, all three types of exceptions are legitimate. It will be understood that the transmission file 310 does not suggest that it is bad. Such delays can occur, for example, due to network congestion. In this way, confirmation provides a mechanism for removing legitimacy from erroneous data.
For the initialization send file 310, OLTP140 compares the local database 200 with the remote database 210 by performing a bidirectional full table scan on both databases 200 and 210. That is, all the data in the local database 200 is compared against all the data in the remote database 210. After that, all the data in the remote database 210 is compared against all the data in the local database 200. This has the advantage of finding all discrepancies and giving a thorough comparison of databases 200, 210.
With the send file 300, the OLTP 140 compares only the data records of the local database 200 and the remote database 210 recorded in the send file 300. This has the advantage of giving quick inquiries to find targeted discrepancies.
Instead, the data in the initialization transmit file 310 and / or the transmit file 300 is randomly sampled. The OLTP140 then randomly compares the sampled data from the local database 200 with the remote database 210.
Exception list 1140 corresponds to lost events for the local database 200 that are inconsistent with the remote database 210, such as add, mod, and delete. To identify these candidate events, OLTP140 examines the recent transactions given to the local database 200. Normally, for each transaction given, an entry is made in the log table stored in the local database 200. The entry may include an identifier for the modified record and a transaction (or event) (eg, add, mod and / or del event) that modified the record, a log sequence number indicating the order of the transactions, and the like.
An exemplary log table 1100 is shown in Figure 11. In this example, the send file 300 contains the transaction 1108-1114 shown in log table 1100. The first entry 1101 indicates that the data n1 and n2 (name server) were added to the data (domain) associated with the identifier d1 in the first transaction 1108. The identifier is d1, the event is add, and the log sequence number is 11526. Similarly, the second entry 1102 indicates that in the second transaction 1109, the data n8 and n9 were attached to the data associated with the identifier d2. The third entry 1103 indicates that the data associated with the identifier d3 was erased in the third transaction 1110. Fourth entry 1104 indicates in fourth transaction 1111 that the data associated with identifier d1 has been modified to append data n5. In the fifth transaction 1112, the fifth entry 1105 indicates that the data n6 and n7 have been attached to the data associated with the identifier d3. In the sixth transaction 1113, the sixth entry 1106 indicates that the data associated with the identifier d4 has been modified to remove the data n3. The Rth entry 1107 indicates that the data associated with the identifier d5 was erased in the Rth transaction 1114.
Therefore, as shown in Figure 10A, OLTP140 associates the event identifier (at 1015) with each event in the update, and the event identifier is associated with the event in the record. Each update event is found in the event history. The event history indexed and ordered by the event identifier can be generated from log table 1100. An exemplary event history 1120 is shown in Figure 11. Here, the first and fourth entries 1101 and 1104 of log table 1100 indicate changes to the data associated with identifier d1. Event history 1120 therefore includes the d1 identifier 1121 and two events 1126 with an "add" followed by an "mod" in the data associated with the identifier d1. The second entry 1102 indicates a change to the data associated with identifier d2. Event history 1120 therefore contains the d2 identifier 1122 and the add event 1127. Event history 1120 contains the d3 identifier 1123 and two events 1128 with a del followed by a mod, indicating third and fifth entries 1103 and 1105, and changes to the data associated with the identifier d3. Includes. The sixth entry 1106 indicates a change to the data associated with identifier d4. Therefore, the event history 1120 contains the d4 identifier 1124 and the mod event 1129. The R entry 1107 indicates a change to the data associated with the identifier d5, and the event history 1120 contains the d5 identifier 1125 and the del event 1130. The identifiers 1121-1125 are ordered from d1 to d5.
With reference to Figure 10A again, OLTP140 determines if the update is valid (at 1020). This determination is made, for example, according to the embodiment of FIG. 10B. First, OLTP140 compares the event identifier 1121-1125 with the exception identifier 1140 to determine which identifier (at 1022) corresponds to. For example, in FIG. 11, the d1 event identifier 1121 in event history 1120 corresponds to the d1 exception identifier in List 2 in exception list 1140. After discovering the corresponding event and exception, OLTP140 determines (at 1024) whether the event justifies the exception. Justification is done as follows. In each event identifier 1121-1125 of event history 1120, OLTP140 determines whether each system of event 1126-1130 of event history 1120 is valid. It checks the exception list 1140 to determine, for example, the exception type to which each exception identifier belongs, determines what the valid sequence of events for that exception type should be, and then the corresponding event identifier and event identifier for the event. It is done by searching the event history 1120 of the sequence of. The valid sequences for each exception type are detailed below. If the sequence of events 1126-1130 in event history 1120 matches a valid sequence, then the corresponding event identifier 1121-1125 has a valid sequence. In this way, the exception associated with the exception identifier is justified. The corresponding transaction 1108-1114 containing the event is justified and error-free. In this case, OLTP140 removes the exception identifier from the exception list 1140.
A valid sequence of events of the List 1 exception type is (mod)<sup>*</sup>(del). This sequence contains zero or more "mod" events, followed by "del" events, followed by something. The List 1 exception type corresponds to the data residing in the remote database 210, but not the data residing in the local database 200. In this case, the data has recently been erased from the local database 200 and the transaction has not yet been written to the send file 300. Therefore, the transmit file 300 has not yet been fed to the remote database 210. Therefore the data does not exist in the remote database 210. This is considered a justification discrepancy, as it is expected that the transmit file 300 will be generated and applied to the remote database 210 at some point. If any such sequence 1126-1130 is found in the event history 1120 of the exception identifier in Listing 1 of Exception List 1140, then the corresponding transaction may be considered valid.
For example, in FIG. 11, the d5 identifier 1125 and its associated data are cleared from the local database 200 and indexed by event history 1120, as shown in entry 1114 of R in log table 1100. At confirmation, d5 is erased from the local database 200, but not from the remote database 210. Exception List 1140 contains the identifier d5 in Listing 1. According to the event history 1120, the event 1130 associated with the d5 identifier 1125 is del. OLTP140 is a valid sequence of List 1 exception types, ie (mod)<sup>*</sup>Compare (del) to d5 event 1130 in event history 1120. The clearing transaction 1114 associated with identifier d5 is valid and is not considered an error, as the valid sequence in List 1 matches event 1130. Therefore, the identifier d5 can be removed from the exception list 1140.
A valid sequence of List 2 exception type events is (add). This sequence contains an "add" event followed by something. The List 2 exception type corresponds to the data residing in the local database 200, but not the data residing in the remote database 210. In this case, the data has recently been added to the local database 200 and the transaction has not yet been written to the send file 300. Outgoing file 300 has not yet been applied to the remote database 210. The data does not exist in the remote database 210. This is considered a justification discrepancy, as it is expected that the transmit file 300 will be generated and applied to the remote database 210 at some point. Therefore, if any such sequence 1126-1130 is found in the event history 1120 of the exception identifier in Listing 2 of Exception List 1140, then the corresponding transaction is considered valid.
Referring to FIG. 11, the d1, d2 identifiers 1121 and 1123 are associated with, for example, the first data attached to the local database 200. Since the sequences of events 1126 and 1127 start with an "add" event, the d1, d2 identifiers 1121 and 1123 match the valid sequences of the "List 2" exception type. Therefore, transactions 1108 and 1109 containing these identifiers are considered valid and the identifiers d1 and d2 are removed from the exception list 1140. It should be noted that the d3 identifier 1123 also contains an add event in its sequence 1128. However, the "add" event is not the first in sequence 1128. Therefore, sequence 1128 is not eligible as a " List 2" type. In addition, d3 is not specified in Listing 2 of Exception List 1140, so OLTP140 does not check it with a valid sequence in Listing 2.
A valid sequence of List 3 exception type events is (del)<sup>*</sup>(add) or (mod). These sequences include a "mod" event followed by an "add" event followed by something or a "mod" event followed by something. The List 3 exception types correspond to the data that exists in both databases 200 and 210, but they are different. In this case, the data has recently changed in the local database 200 and the transaction has not yet been written to the send file 300. Outgoing file 300 has not yet been applied to the remote database 210. The data associated with the identifier has not yet changed in the remote database 210. This is considered a justification discrepancy, as it is expected that the transmit file 300 will be generated and applied to the remote database 210 at some point. Therefore, if any such sequence 1126-1130 is found in the event history 1120 of the exception identifier in Listing 3 of Exception List 1140, then the corresponding transaction is considered valid.
For example, in Figure 11, the d3, d4 identifiers 1123, 1124 are associated with the modified data in the local database 200. In the case of d3 identifier 1123, d3 identifier 1123 and its data are first erased and then new data is added, so that the sequence of event 1128 contains "del" followed by "add". In the case of the d4 identifier 1124, the d4 data has been modified to remove the data, so that the sequence of event 1129 contains a mod. Since these sequences in events 1128, 1129 match the valid sequences of the List 3 exception type, these corresponding transactions 1110, 1112, 1113 are considered valid, and the identifiers d3, d4 are in exception list 1140. Is removed from.
Seeing Figure 10B, if all the exceptions indicated by the identifiers in exception list 1140 are justified by the event (at 1024), that is, if exception list 1140 is empty, then OLTP140 is the send file (at 1026). Specify 300 or the initialization send file 310 as valid and notify LUE100 to apply the send file 300 or the initialization send file 310 to the remote database 210. The LUE100 then feeds the transmit file 300 or the initialization transmit file 310 to the remote database 210.
Conversely, if all exceptions are not justified by the event (at 1024), that is, exception list 1140 is not empty, then the remaining exceptions (at 1028) invalidate send file 300 or initialization send file 310. Specify and log the error to the error file.
In another embodiment, for example, if transmit file 300 or initialization transmit file 310 is specified as invalid, after a predetermined period of time, OLTP140 will invalidate the transmit file to ensure that the mismatch is really an error. Repeat the verification process with 300 or initialization send file 310. This predetermined delay allows more time on the network to send any slow transmission files 300, 310 and databases 200, 210, and more time to consistently read.
In one embodiment of the invention, the data in the remote database 210 "delays" the data in the local database 200 over a large period of time. Therefore, to compare detection errors with databases 200, 210, databases 200, 210 are consistently read at the same point in time, so they are exact copies of each other. Normally, the remote database 210 is rolled forward to the local database 200, where the data in the remote database 210 is essentially the same as the data in the local database 200.
Therefore, to speed up the change, any currently generated initialization transmit file 310 and subsequent transmit files 300 are fed to the remote database 210 before the start of verification. In this way, the number of discrepancies is greatly reduced. This batching of outbound files 300 and 310 is called chunking. The beginning and end of these send files 300 and 310 in chunks are called low and high watermarks, respectively. The first chunk, called the first chunk, contains the initialization send file 310. All next chunks, called termination chunks, contain only send file 300.
Chunking is a group confirmation rather than a separate confirmation. Therefore, if an error is detected in a chunk, the entire chunk is designated as invalid rather than just the sending file 300 or the initialization sending file 310 where the error occurred.
The mechanisms and methods of the embodiments of the present invention will be performed using a general purpose microprocessor programmed according to the teachings of the embodiments. Embodiments of the invention therefore include a readable medium for the machine, which includes instructions used in the program of the processor to perform the methods according to the embodiments of the invention. This medium includes, but is not limited to, any type of disk including, but is not limited to, floppy (R) disks, optical disks, and CD-ROMs.
Some embodiments of the present invention have been specifically shown and described herein. However, it will be appreciated that the modifications and modifications of the present invention do not deviate from the technical scope of the present invention and are covered by the claims by the above considerations.
<figref num="1">The block diagram of the system according to 1 Embodiment of this invention.</figref><figref num="2">The block diagram of the system hub according to 1 Embodiment of this invention.</figref><figref num="3">The figure which shows the exemplary transmission of the database update from the local database to the remote database according to one Embodiment of this invention.</figref><figref num="4">The figure which shows the transmission file according to 1 Embodiment of this invention.</figref><figref num="5">The figure which shows the initialization transmission file according to 1 Embodiment of this invention.</figref><figref num="6">A timing chart of generation of a transmission file and an initialization transmission file according to one embodiment of the present invention.</figref><figref num="7">The flowchart of one embodiment of the present invention in which an update file of a local database is generated.</figref><figref num="8">A flowchart of another embodiment of the invention in which a remote database receives an update file from a local database.</figref><figref num="9">A flowchart of another embodiment of the invention in which a remote database receives and confirms an update file from a local database.</figref><figref num="10A">A flowchart of one embodiment of the present invention in which an update file is confirmed.</figref><figref num="10B">A flowchart of another embodiment of the present invention in which an update file is confirmed.</figref><figref num="11">The figure which shows the update file confirmation according to 1 Embodiment of this invention.</figref>
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2001290689A | Cites | Japan |
| JP2001236257A | Cites | Japan |
| JP2000057030A | Cites | Japan |
| JP11327985A | Cites | Japan |
123 members in 17 offices
Priority claims14
| Document | Office | Kind | Date |
|---|---|---|---|
| 33084201 | United States of America | P | |
| 33084201 | United States of America | P | |
| 60330842 | United States of America | – | |
| 36516902 | United States of America | P | |
| 36516902 | United States of America | P | |
| 60365169 | United States of America | – | |
| 0235083 | United States of America | W | |
| 0235083 | United States of America | W | |
| 2001330842 | – | – | – |
| 2002365169 | – | – | – |
| 2002035083 | – | – | – |
| US20010330842P | – | – | – |
| US20020365169P | – | – | – |
| WO2002US35083 | – | – | – |
Members123
| Document | Office | Kind | |
|---|---|---|---|
| US2003084038A1 | United States of America | A1 | |
| US2003084039A1 | United States of America | A1 | |
| US2003084057A1 | United States of America | A1 | |
| US2003084074A1 | United States of America | A1 | |
| US2003084075A1 | United States of America | A1 | |
| CA2466107A1 | Canada | A1 | |
| CA2466110A1 | Canada | A1 | |
| CA2466117A1 | Canada | A1 | |
| CA2472014A1 | Canada | A1 | |
| WO03038565A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO03038596A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO03038653A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO03038654A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO03038683A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2002356886A1 | Australia | A1 | |
| US6681228B2 | United States of America | B2 | |
| WO03038565A3 | World Intellectual Property Organization (WIPO) | A3 | |
| KR20040053254A | Republic of Korea | A | |
| KR20040053255A | Republic of Korea | A | |
| KR20040053266A | Republic of Korea | A | |
| KR20040053268A | Republic of Korea | A | |
| MXPA04004169A | Mexico | A | |
| NO20042258L | Norway | L | |
| NO20042259L | Norway | L | |
| NO20042260L | Norway | L | |
| NO20042261L | Norway | L | |
| EP1449049A2 | European Patent Office (EPO) | A2 | |
| EP1449062A1 | European Patent Office (EPO) | A1 | |
| EP1451714A1 | European Patent Office (EPO) | A1 | |
| EP1451728A1 | European Patent Office (EPO) | A1 | |
| IL161712A0 | Israel | A0 | |
| IL161712D0 | Israel | D0 | |
| EP1461723A1 | European Patent Office (EPO) | A1 | |
| EA200400613A1 | Eurasian Patent Organization (EAPO) | A1 | |
| EA200400614A1 | Eurasian Patent Organization (EAPO) | A1 | |
| EA200400618A1 | Eurasian Patent Organization (EAPO) | A1 | |
| BR0213807A | Brazil | A | |
| US2004254926A1 | United States of America | A1 | |
| BR0213862A | Brazil | A | |
| BR0213863A | Brazil | A | |
| BR0213864A | Brazil | A | |
| EA200400612A1 | Eurasian Patent Organization (EAPO) | A1 | |
| MXPA04004201A | Mexico | A | |
| JP2005508042A | Japan | A | |
| JP2005508050A | Japan | A | |
| JP2005508051A | Japan | A | |
| JP2005510782A | Japan | A | |
| CN1610877A | China | A | |
| CN1610901A | China | A | |
| CN1610902A | China | A | |
| CN1610906A | China | A | |
| EA005646B1 | Eurasian Patent Organization (EAPO) | B1 | |
| MXPA04004202A | Mexico | A | |
| MXPA04004203A | Mexico | A | |
| EA006038B1 | Eurasian Patent Organization (EAPO) | B1 | |
| EA006045B1 | Eurasian Patent Organization (EAPO) | B1 | |
| ZA200404267B | South Africa | B | |
| ZA200403597B | South Africa | B | |
| ZA200404266B | South Africa | B | |
| ZA200404268B | South Africa | B | |
| EA006223B1 | Eurasian Patent Organization (EAPO) | B1 | |
| IL161721A0 | Israel | A0 | |
| IL161721D0 | Israel | D0 | |
| IL161722A0 | Israel | A0 | |
| IL161722D0 | Israel | D0 | |
| IL161723A0 | Israel | A0 | |
| IL161723D0 | Israel | D0 | |
| NZ532773A | New Zealand | A | |
| HK1075308A1 | Hong Kong, China | A1 | |
| NZ532771A | New Zealand | A | |
| NZ532772A | New Zealand | A | |
| NZ533166A | New Zealand | A | |
| US7047258B2 | United States of America | B2 | |
| US7167877B2 | United States of America | B2 | |
| US7203682B2 | United States of America | B2 | |
| US2007100808A1 | United States of America | A1 | |
| UA79943C2 | Ukraine | C2 | |
| UA80540C2 | Ukraine | C2 | |
| AU2002350106B2 | Australia | B2 | |
| AU2002356885B2 | Australia | B2 | |
| AU2002350104B2 | Australia | B2 | |
| AU2002356884B2 | Australia | B2 | |
| US2009106211A1 | United States of America | A1 | |
| IL161722A | Israel | A | |
| EP1449062A4 | European Patent Office (EPO) | A4 | |
| EP1451714A4 | European Patent Office (EPO) | A4 | |
| EP1451728A4 | European Patent Office (EPO) | A4 | |
| EP1461723A4 | European Patent Office (EPO) | A4 | |
| EP1449049A4 | European Patent Office (EPO) | A4 | |
| CN100557595C | China | C | |
| JP4399552B2This record | Japan | B2 | |
| KR100941350B1 | Republic of Korea | B1 | |
| JP4420324B2 | Japan | B2 | |
| JP4420325B2 | Japan | B2 | |
| KR100953137B1 | Republic of Korea | B1 | |
| CN1610902B | China | B | |
| CN1610877B | China | B | |
| IL161723A | Israel | A | |
| KR100970122B1 | Republic of Korea | B1 | |
| KR100977161B1 | Republic of Korea | B1 |
20 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Notification of resignation of power of attorneyJAPANESE INTERMEDIATE CODE: A7424RD04 | RD04 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Notification of appointment of power of attorneyJAPANESE INTERMEDIATE CODE: A7423RD03 | RD03 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 4399552
- Publication, DOCDB
- 4399552
- Publication, EPODOC
- JP4399552B
- Application
- 2003540847
- Application, DOCDB
- 2003540847
- Application, EPODOC
- JP20030540847
Titles2
- Japanese
- 遠隔でデータベースを更新する方法およびシステム
- English
- How and system to update database remotely
Classification
- CPC, 16
- G06F9/505
- G06F16/2471
- G06F17/40
- G06F9/546
- G06F2209/5018
- G06F16/245
- G06F16/2358
- G06F16/2365
- G06F16/2315
- Y10S707/99953
- Y10S707/99942
- Y10S707/99938
- Y10S707/966
- Y10S707/959
- Y10S707/99943
- Y10S707/99952
- IPC, 11
- G06F12 00
- G06F15 00
- G06F
- G06F1 00
- G06F7 00
- G06F9 46
- G06F9 50
- G06F17 00
- G06F17 30
- G06F17 40
- G06Q50 10