UA79943C2 - Method and system for updating a remote data base (variants) - Google Patents

Abstract

A method and system for updating a remote database (210) over a network. A plurality of periodic updates, called sendfiles (300-F), based on incremental changes to a local database (200) are generated. Each of the periodic updates includes at least one transaction. An initialization update, called an initializing sendfile, including a version of the local database at a start time is generates. Additionally, an identifier associated with the last periodic update generated before the start time and an identifier associated with the last transaction committed prior to the start time are generated.

Description

Description of the invention

Priority claim/cross-reference to related applications. 2 This non-prior application claims priority to the prior (US Patent Application Serial No. 60/330,842 dated November 1, 2001), fully incorporated herein by reference, and the prior US Patent Application Serial No. 60/365,169 dated March 19 2002), fully incorporated into this description by reference.

The present invention relates to computer databases, more specifically, to a method and system for reliably updating a database.

As databases grow in size and due to their highly distributed structure, it becomes increasingly problematic to ensure identical versions of data across linked databases. If significant changes occur in one database, it may be necessary to update other databases to incorporate these changes as soon as possible. Performing such updates may cause large amounts of 79 update data to be moved frequently to multiple databases. Potentially, such a process can be extremely complex.

This problem is additionally combined with unreliable communication in systems. In this case, data may be lost in transit. This requires a retransmission of the data, and other databases are updated again. Such repetition significantly reduces the efficiency of the system and reduces the area in which the databases contain the most recent data.

Fig. 1 is a structural diagram of the system according to an embodiment of the present invention.

Fig. 2 is a structural diagram of the concentrator system according to an embodiment of the present invention.

Figure 3 illustrates a possible transfer of database updates from a local database to a remote database, according to an embodiment of the present invention.

Fig. 4 illustrates a sending file according to an embodiment of the present invention. with

Fig. 5 illustrates the initialization file of the shipment, according to an embodiment of the present invention. Gee)

Fig is a timing diagram illustrating the formation of a shipment file and a shipment initialization file, according to an embodiment of the present invention.

Fig. 7 is a block diagram of an embodiment of this invention in which local database update files can be created. She

Fig. 8 is a block diagram of an embodiment of this invention in which a remote database can receive its update files from a local database.

Fig. 9 is a block diagram of another variant of the implementation of this invention, in which the remote database can Me. retrieve update files from the local database and verify their authenticity. Ge")

Fig. 1OA is a block diagram of an embodiment of the present invention in which the authenticity of 30 update files can be checked. in

Fig. 10B is a block diagram of another embodiment of the present invention in which the authenticity of update files can be verified.

Fig. 11 is an illustration of checking the authenticity of the update file, according to an embodiment of this invention. WITH

Embodiments of the present invention provide a method and system for reliably updating a remote database over a communication network. According to the implementation options, several periodic updates are generated

From" (hereinafter referred to as "sending file"), based on additional changes in the local database. Each of the periodic updates contains at least one transaction. An initialization update (hereinafter referred to as the "send initialization file") is generated, containing the version of the local database at the time of startup. Additionally, an identifier corresponding to the last periodic update generated before and at the trigger time and an identifier corresponding to the last transaction completed before the trigger time (se) are generated. The implementation options preferably provide for the automation of the send files and the send initialization file for reliable updating of remote databases. o Fig. 1 is a schematic diagram illustrating a system according to an embodiment of the present invention. Basically, the system 100 can contain a large resident database, receive search requests and provide search responses through the communication network. For example, system 100 may be a symmetric multiprocessor (SMP) computer, such as an IBM K5Z/b60009M80 or 580 manufactured by IBM (AgtopKc, New York), Zp Epiegrgisetm 10000 manufactured by Zcp Misgovuvietv (Zapia

Ciaga, California), etc. The system 100 may also be a multiprocessor personal computer 99, such as a SotradR"goi iapitmMIi 530 (having two IPov!RepishtF Ii, 866MHz processors) that

GF) is produced by Nemiek-Raskaga (Rayu Ayo, California). The system 100 may also include a multi-processor operating system, such as an IVM AIHFO 4, Zy!ip Zoiagistm 8 Oregypd Epmigoptepi,

Kay Us and IMmOhe 6.2, etc. The system 100 can receive periodic updates through the communication network 124, which can be included in the database in parallel. Embodiments of the present invention can achieve very high database update and search performance by incorporating each update into the database without using database locking or access controls.

In an embodiment, system 100 may include at least one processor 102-1 attached to bus 101. Processor 102-1 may include an internal cache (eg, cache 11, not shown). Between the processor 102-1 and bus 101, the secondary memory cache 103-1 can be resident (for example, cache 12, cache I 2/3, etc.).

In a preferred embodiment, system 100 may include several processors 102-1...102-P connected to bus 101. Several caches 103-1 may also be resident between several processors 102-1...102-P and bus 101 ...103-P of secondary memory (for example, a look-through architecture) or, in the form of another variant, at least one cache 103-1 of secondary memory (for example, an architecture with a background history) can be connected to the bus 101. System 100 may include memory 104, such as a random access memory (RAM), etc., connected to bus 101 for storing information and instructions to be executed by multiple processors 102-1...102 -R.

Memory 104 can store a large database, for example, to convert Internet domain names to Internet addresses, to convert names or phone numbers to network addresses, to provide and update subscriber profile data, to provide and update user presence data, etc. In particular, the size of the database and the number of conversions per second can be very large. For example, memory 104 may contain at least 64GB of RAM and may contain a domain name database of 500M (ie, 500x1059) records, a subscriber database of 500M records, a mobile phone number database of 450M records, etc.

In a possible 64-bit system architecture, for example, such as a system containing at least one 75 64-bit reverse byte processor 102-1 connected to at least a 64-bit bus 101, |and 64-bit memory 104, an 8-byte pointer value can be written to a memory address (cell) on an 8-byte boundary (ie, a memory address divisible by eight, or, for example, 8M) using a single continuous operation. Basically, the presence of the secondary memory cache 103-1 may simply delay the writing of an 8-byte pointer to the memory 104. For example, in one embodiment, the secondary memory cache 103-1 may be a look-through cache operating in a look-through mode write so that a single 8-byte save command can move eight bytes of data from processor 102-1 to memory 104 without interruption and in just two system clock cycles. In another embodiment, secondary memory cache 103-1 may be a look-through cache operating in write-back mode so that an 8-byte pointer may first be written to secondary memory cache 103-1, which then, in more late time, can write an 8-byte pointer to memory 104, for example, when writing to memory 104 a cache line in which the 8-byte pointer is stored (ie, for example, when a specified line is "dumped" cache, or completely secondary memory cache). i9)

Ultimately, from the perspective of the processor 102-1, once the data is latched by the output pins of the processor 102-1, all eight bytes of data are written to the memory 104 in one continuous, continuous transfer, which may be delayed by the actions of the secondary memory cache 103-1 yati, if it is available. From the perspective of processors 102-2...102-P, as soon as data is latched by the output pins of processor 102-1, all eight bytes of data are written to memory 104 in one continuous, continuous transfer, which is designated by the cache coherence protocol caches M 103-1...103-P of secondary memory, which can delay writing to memory 104, if available. Gee!

However, if an 8-byte pointer value is written to an unaligned memory location 104, such as a memory address crossing an 8-byte boundary, then all eight bytes of data cannot be transferred from processor 102-1 using a single instruction 8-byte storage. Instead, processor 102-1 may issue two different and separate save commands. For example, if a memory address begins four bytes before an 8-byte boundary (eg, 8M-4), then the first save instruction transfers the four high-order bytes to memory 104 (eg, 8-4), while the second the save command transfers the four least significant bytes (for example, 8M) to memory 104. "

Importantly, between these two separate save commands, processor 102-1 may receive an interrupt, or processor 102-1 may release control of bus 101 to another system component (eg, processor 102-P, etc.). Therefore, the pointer value resident in memory 104 will be invalid until processor 102-1 can complete the second save command. If another component initiates a single "" continuous memory read into this memory location, then an invalid value will be returned as if a valid value were to be returned.

Similarly, a new 4-byte pointer value can be written to a memory address divisible by four -ANDs (eg, 4M) using a single continuous operation. It should be noted that in the possible variant described above, the 4-byte value of the pointer can be written into the memory cell 8M-4 with the use of a single save command. Of course, if a 4-byte pointer value is written to a cell that crosses a 4-byte boundary, such as 4M-2, then all four bytes of data cannot be transferred from processor 102-1 using a single store instruction, and the value pointer resident in memory 104 may be invalid for some period of time. The system 100 may also include a non-volatile memory device (VRAM) 106, or other static memory devices connected to the bus 101, for storing static information and instructions for the processor 102-1. A storage device 108, such as a magnetic or optical disk, may be attached to the bus 101 to store information and commands. System 100 may also include a display device 110 (e.g., liquid crystal display (LCD)) and input device 112 (e.g., keyboard, mouse, trackball, etc.) connected to bus 101. System 100 may contain several network co-interfaces 114-1...114-O, which can transmit and receive electrical, electromagnetic or optical signals carrying streams of digital data, which represent various types of information. In an embodiment, the network interface 114-1 can be connected to the bus 101 and to the local area network (GAM) 122, while the network interface 114-O can be connected to the bus 101 and the global communication network UUAM (GM) 124.

Several network interfaces 114-1...114-0 may support different network protocols, including, for example, Sidabia E(Pegpay (e.g. IEEE Standard 802.3-2002 issued in 2002), Rireg Spappei! (e.g.

AMZ5I Standard Kh.3230-1994, issued in 1994), etc. Several network 65 Computers 120-1...120-M can be connected to LM 122 and GM 124. In one embodiment, LM 122 and GM 124 may be physically separate communication networks, while in another embodiment, LM 122 and GM 124 may be connected through a network gateway or router (not shown for convenience). Alternatively, LM 122 and GM 124 may be the same communication network.

As mentioned above, the system 100 may provide OM5 (domain name service) resolution services. In a variant of implementation for OMZ discrimination (address determination process), OM discrimination services can basically be divided between network transport and data retrieval functions. For example, system 100 may be a search engine (SE) for a server optimized for searching data across large data sets, while a plurality of network computers 120-1...120-M may be a plurality of client protocol engines (PE) , optimized for communication and transportation network processing. | The SHE can be a powerful multiprocessor /o berver that stores in memory 104 the entire set of OM5 records to facilitate high-speed, high-performance searching and updating. In another embodiment, OM resolution services may be provided by a plurality of powerful multiprocessor servers, or a plurality of IESs, each of which stores a subset of the entire OM record set in memory to facilitate high-speed, high-performance retrieval and updating.

In contrast, the plurality of REs may be conventional highly specialized PC-based devices running an efficient multitasking operating system (e.g., Kei Nai GIMOHO 6.2) that minimize the traffic load of the communication processing network by | SHE to maximize available resources for discrimination

OHM. PE devices can process the nuances of the OM5 protocol of the main communication line, respond to invalid requests

OM and multiplex valid OMZ requests to the SHE via the LM 122. In another embodiment, containing 2o Set of COEs that store subsets of OM5 records, REs can determine which device | The UE must receive each valid OM request and multiplex the valid OM requests into the corresponding IS. The number of REs for one (ESR) can be determined, for example, by the number of OM requests that must be processed per second, and the operating characteristics of a particular system. Other indicators can also be used to determine compliance ratios and modes.

In general, other query-based high-volume implementations may be supported, including, for example, phone number resolution, 557 signaling processing, determination for i) geolocation, phone number matching, subscriber location and presence determination etc.

In an embodiment, the central server 140-1 of operational transaction processing (OIT TR) can be connected to the GM 124 and receive from various sources additions, changes and deletions (ie, update traffic) for the database 142-1. ОИ TR server 140-1 can transmit updates through GM 124 to the system 100, which contains - a local copy of the database 142-1. ОЙ TR server 140-1 can be optimized to handle update traffic in Ge! various formats and protocols, including, for example, Hypertext File Transfer Protocol (HTTP),

Recording Recorder Protocol (RCP), Extended Initialization Protocol (ERP), Management System (ME)

Services/Mechanized Common Interface (MO) 800, and other operational initialization protocols. The totality of

The read-only IOE can be deployed in a hub-and-spoke architecture to provide high-speed lookup capabilities that are accompanied by voluminous incremental updates from the 140-1 OT server.

In an alternative variant of implementation, data can be distributed over several OITR servers « 40. 140-1...140-5, each of which can be connected to GM 124. OI TR servers 140-1...140-5 can receive from -ptsh) from various application sources, changes and deletions (ie, update traffic) for the databases corresponding to them, 142-1...142-5 (not shown for convenience). TR servers 140-1...140-5 can transmit updates via GM from 124 to system 100, which can contain copies of databases 142-1...142-5, other dynamically created data, etc.

For example, in an embodiment for geolocation, the TR servers 140-1...140-5 can receive update traffic from groups of remote sensors. In another alternative embodiment, a plurality of network-I computers 120-1...120-M can also receive, through GM 124 or LM 122, applications, changes, and deletions (ie, update traffic) from various sources. In this embodiment, a plurality of network computers 120-1...120-M and can transmit updates as well as requests to the system 100.

Ge) In an embodiment of OM5 discrimination, each RE (for example, each of the set of network computers 120-1...120-M) can combine, or multiplex, several OM request messages received through the global communication network ( for example, GM 124), into a single Request SuperPacket and transmit the Request SuperPacket 4) through a local communication network (for example, LM 122) to the SHE (for example, system 100). | The UE can combine, or multiplex, several responses to UOM5 request messages into a single SuperPacket of Responses and transmit the SuperPacket of Responses through the local communication network to the corresponding PE. Basically, the maximum size of a SuperPacket of a Reply or Request can be limited by the maximum transmission unit (MT) of the physical network layer (for example, Sidabia E(pegpe). For example, the standard sizes of the request and response message (F) OM, not exceeding 100 bytes and 200 bytes, respectively, allow multiplexing more than 30 requests into a single Request SuperPacket, as well as multiplexing more than 15 responses into a single SuperPacket

Answers. However, a smaller number of requests (for example, 20 requests) can be included in a single SuperPacket of a Request, in order to avoid overflowing the MIT (for example, 10 responses) when forming a response. For larger MTs, the number of multiplexed requests and responses can be increased, respectively.

Each multitasking PE can have an input stream and an output stream to handle p requests and responses, respectively. For example, an input stream may demarshal (unpack) OM5 request components from incoming OM5 request packets received over a WAN and multiplex several millisecond 65 requests into a single Request SuperPacket. The incoming stream can then transmit the Request SuperPacket over the LAN to the SHE. On the contrary, the output stream can receive SuperPacket Responses from GE,

demultiplex the responses contained therein and marshal (package into a standard format) the various fields into a valid OM response, which can then be transmitted over a global communications network. Basically, as mentioned above, other high volume implementation options based on requests can be supported.

In an embodiment, the Request SuperPacket may also contain status information corresponding to each OM5 request, such as source address, protocol type, etc. | The OE can include information about the status and corresponding answers of the OM in the SuperPacket of Answers. Each RE can then generate and return valid OM5 response messages using the information transmitted from the (SHE). Therefore, each RE can preferably function as a device that does not change its state during execution, i.e., valid OM5 responses can be generated from the information contained in the Answer SuperPacket. Basically, (SHE can return

SuperPacket Responses in the RE from which the incoming SuperPacket originated, however, other possible options are obvious.

In an alternative embodiment, each RE may maintain state information corresponding to each OM request and include a reference, or descriptor, to the state information in the Request SuperPacket. And the OEE may include in the Answers SuperPacket a link to information about the status and corresponding answers of the OM. Each RE can then form and return valid OM5 response messages using the state information references transmitted from the ESR as well as state information maintained by it. In this embodiment | The SHE can return the Reply SuperPacket to the RE from which the incoming SuperPacket originated.

Figure 2 shows a structural diagram of a hub-and-spoke architecture (star topology), according to an embodiment of the present invention. Basically, the system may include a local database 200 (which may be located in a central OI-TR. hub 140) and one or more remote databases 210 (which may be located in IES devices 100) connected to the local database 200 using any connection mechanism, for example, the Internet or LM 122. Databases can transmit and receive update data.

According to Fig. 3, in embodiments of the present invention, the local database 200 transmits to the remote database 210 the P files 300-1...300-E of the shipment and the initialization file 310 of the shipment to update the remote database 210. The update files can be transmitted individually or in batches, such as multiple (8) 300 send files, one 300 send file and one 310 send initialization file, multiple 300 send files and one 310 send initialization file, a single 300 send file, or a single 310 send initialization file. c zo In an embodiment of this invention, the processor 104 can receive from the local database 200 the file 300 of the shipment and/or the initialization file 310 of the shipment containing the update data. System 150 can receive a file -

Z00 sending and initialization file 310 sending in the remote database 210 through the communication interface 118. Gee!

The processor 104 can then compare the update data in the send file Z00 or the send initialization file 310 with the corresponding data in the remote database 210. If the data in the remote database 210 is different, then (22) the processor 104 can apply the send file 300 or the initialization file 310 sending to the remote database 210. Accordingly, the remote database 210 may subsequently be updated with data corresponding to the update data in the local database 200.

Fig.A4 illustrates a file 300 of the shipment, according to an embodiment of the present invention. File fields 300 may include, for example, file identifier 400 , file creation time 402 , number 404 of M transactions in the file, full file size 406 , checksum 408 , or any similar error and transaction control indicator 410 -1...410-M (containing transaction identifiers). The specified fields of the send file are possible variants intended to illustrate, but not to limit the context of the embodiments;" of this invention. Any field that may be useful may be included in the send file 300 .

The sending file 300 contains the changes in the local database 200 between the two points in time. These changes can

Include, for example, adding new identifiers (ie, data record identifiers), deleting -AND existing identifiers, changing one or more data records corresponding to an identifier, renaming an identifier, an empty command, etc. One or more of these changes may be made sequentially and may be called transactions. The 300 shipment file may contain unique

Ge) identifiers of these transactions. Transactions may be recorded in the dispatch file 200 in the order in which they were committed in the local database 200. Additionally, for transactions containing more than one change, the changes may be recorded within the transaction in the order in which they were committed in local database 200. 4) Basically, transaction identifiers can be assigned to transactions in a random order. That is, transaction identifiers do not necessarily grow monotonically over time. For example, two consecutive transactions can have transaction identifiers 10004 and the next one 10002. Accordingly, the sequence of execution of this transaction can be determined by its placement in the current file 300-E or its placement in the previous file 300-(E-1). Basically, to completely complete the update of the remote database with the application

F) of one send file, transactions cannot span neighboring files 300. This prevents updates from being interrupted by network latency, which could lead to erroneous data in the remote database 210.

Fig. 5 depicts the initialization file 310 of the shipment, according to an embodiment of the present invention. Fields in the send initialization file 310 may include, for example, a file identifier 500 , a file creation time 502 , a number 504 of M transactions in the file, a full file size 506 , a checksum 508 or any similar error control indicator, and a copy 516 (data ) of the complete local database. The send initialization file 310 may further include a field 510 that is a file identifier 400 of the last file

Z00 of the shipment, formed before the formation of the file 310, and field 512, which is the identifier of the last transaction 65 fixed in the local database 200 before the formation of the initialization file 310 of the shipment. Data in the local and remote databases 200, 210 can be distributed across tables resident in the databases 200, 210. The databases 200, 210 can support any number of tables. Thus, when the database has tables, the initialization file 310 of the shipment may contain, for each table, a field that indicates the number of entries made to the table. For example, a domain name database might contain a table of domains and a table of domain name servers. Therefore, the send initialization file may contain a field that indicates the number of entries in the domain table and a field that indicates the number of entries in the domain name server table. The field can specify, for example, the name of the table, the key used to index the records in the table, and the number of records in the table. Additionally, the send initialization file 310 may contain a field that indicates the version of the send initialization file 310 , typically 1.0. The specified send initialization file fields are possible variants intended 7/0 to illustrate, but not limit, the context of embodiments of the present invention. Any field that may be useful may be included in the initialization file 310 of the shipment.

As indicated above, the initialization file 310 of the shipment may contain, for example, a copy of the complete local database 200, unified by reading the data. The initialization file 310 of the shipment may become unified with the local database 200 at a time between iv and E, where iv is the start time of the formation of the initialization file 7/5 310 of the shipment, and E is the completion time of the formation. In fact, the only operation that can appear in the initialization file 310 of the shipment is the "add" operation. That is, when creating the initialization file 310 of sending, copies of the complete local database 200 at the time of It can be written into it. Therefore, an "add" operation can be performed to write the local database 200 to the initialization file 310 of the shipment.

The identifiers may be written to the initialization file 310 of the shipment in a random order. Alternatively, in the presence of external identifiers, the referenced data records may be written to the referenced data record.

The addition of fields 510 and 512 can provide the initialization file 310 of the shipment with some information about the files 300 of the shipment that can be generated and transferred to the remote database 210 during the formation of the initialization file 310 of the shipment. However, the formation of the sending file 300 and the formation of the initialization file 310 of the Dispatch may not be related to each other due to the lack of dependence between them during formation. Such a structure and process can prevent a less efficient approach, in which the formation and application of the i) sending file can be terminated before the completion of the formation of the sending initialization file. When continuing to generate and apply the shipment files 300 during the formation of the shipment initialization file 310, as in an embodiment of the present invention, strict error control of the shipment files 300 can be performed, as well as the imposition of restrictions on the remote database 210, for example, restrictions can be made relative to uniqueness or restriction to external identifiers. The imposition of restrictions can protect the integrity of the data in the remote database 210 by rejecting transactions that violate the relational model of Ge! of the remote database 210. For example, a restriction on uniqueness may prevent the repeated storage of the same key in the database 210. (22)

Fig.b6 shows a timing diagram illustrating the formation of a sending file and a sending initialization file, according to an embodiment of the present invention. According to Fig. b, files 300 of sending (from 8-1 to 8i-21) are formed at regular time intervals. In an alternative embodiment, the sending files 300 may be generated at irregular time intervals. In the general case, the formation of the sending file does not occupy the time interval completely. For example, if the files are generated in 5-minute time intervals, then it does not take the entire 5 minutes to complete the file generation. Additionally, if changes are made to the local database from c 200 during the generation of the shipment file 300, then these changes will be collected in the next file

From 00 of sending. For example, if the generation of shipment file 5/-4 starts at 12:05:00 and ends at 12:05:02, then any changes to local database 200 made between 12:05:00 and 12:05: 02, are collected into a dispatch file 51-5 (eg 300-5), which covers the time interval from 12:05:00 to 12:10:00.

Fig. 1 illustrates the 300-5 and 300-19 shipment files. In the specified files, among other fields, the identifier 601 of the file (51-5, 8i-19), the time 603 of the formation of the file, and the identifiers 605 of transactions (for example, 10002) are depicted. It should be noted that transaction identifiers may not be monotonically ordered. As mentioned above, transaction identifiers can have arbitrary values. However, directly related transactions

Ge) are recorded in file Z00 of shipments in the order in which they were made in the local database 200.

Since the formation of the initialization file 310 of the shipment and the formation of the file 300 of the shipment may not be connected, the initialization file 310 of the shipment may be formed at any time. For example, the file 4) of the initialization 310 of the shipment can be formed before, during or after the formation of the file 300 of the shipment. Fig. b illustrates the initialization file 310 of the shipment, which is formed in the time interval between the formation of the fourth and fifth files of the shipment (for example, 1-4 and 8-5).

In an embodiment, the initialization file 310 of the shipment may contain, among other fields, a file identifier 610 (ivy-1), a file identifier 615 for the last shipment file generated before the generation

F) the initialization file of the shipment, and the identifier 620 of the transaction for the last transaction completed before the formation of the initialization file of the shipment. In this possible embodiment, the last generated send file is send file 5/-4, and the last completed transaction is transaction 10001. The initialization bo file 310 of the send starts 611 at 12:07:29. When the generation of the shipment initialization file 310 begins, the first half of the transactions in the shipment file 300-5 (1-5), transactions 10002, 10005, and 10001 have already been completed in the local database 200. Accordingly, the shipment initialization file 310 may have information about the transaction data and may collect the transaction data in the send initialization file 310 . However, the initialization file 310 of sending cannot have information about further transactions 10003 and 10004, which are carried out after the beginning 65 of the formation of the initialization file of sending.

When forming the initialization file 310 of the shipment, the shipment files, starting with the file 300-5 of the shipment,

may continue to form at regular time intervals. These files can be transferred to the remote database 210 and applied.

The formation of the initialization file 310 of the shipment can be completed at 1:15:29, in the time interval between the formation of the 18th and 19th files Z00 of the shipment (51-18 and 81-19), it cannot affect the formation of the 19th file 300-19 dispatches.

After receiving and loading in the remote database 210 the initialization file 310 of the shipment, the remote database 210 may not take into account the shipment files formed before the formation of the initialization file 310 of the shipment. This is possible, for example, due to the fact that the initialization file 310 of the shipment contains all the changes in the 70 local database 200 that were written to the previous files 300 of the shipment. In this possible embodiment, the remote database 210 may not need to consider the first through fourth shipment files (51-1 through 8/-4). The changes recorded in these shipment files 851-1 through 81-4 may also be recorded in the initialization file 310 of the shipment. The specified previous sending files (from 51-1 to 51-4) can be deleted or, alternatively, archived.

Similarly, the remote database 210 may not consider transactions completed prior to the formation of the initialization file 310 of the shipment that were included in the file 300 of the shipment generated subsequently. Transaction data may be included in the initialization file 310 of the shipment when it is generated. For example, therefore, the remote database 210 may not need to consider the first three transactions 10002, 10005, 10001 from the shipment file v51-5.

The transaction data written to the sending file 5-5 may also be written to the initialization file 310 Sending. These completed transactions may be deleted, or alternatively, archived.

Figure 7 shows a block diagram of an embodiment of this invention in which local database update files can be created. The system may generate (705) several periodic updates based on additional changes in the local database. Each update can contain one or more transactions. The system may then transmit (710) periodic updates to the remote database. When generating periodic update logs, the system may start generating (715) initialization updates at startup time.

The initialization update may contain a version of the full local database. The system may determine (720) the last i) periodic update generated prior to the trigger time and the last transaction completed prior to the trigger time. The system may then transmit (725) the initialization update to the remote database. The initialization update may contain an update ID corresponding to the last periodic update generated and a transaction ID corresponding to the last completed transaction.

For example, ОИ ТР 140 may form (705) files 300 of sending with some regular or irregular time interval. Then ОИ TR 140 can transmit (710) the files 300 of the shipment to the remote database 210. At Ge! formation of files З00 of sending, ОИ ТР 140 can start formation (715) of initialization file 310 of sending at the moment of time 611 of launch. The initialization file 310 of the shipment may contain a copy of the complete local database 200. me)

Then ОИ ТР 140 can determine (720) the last file 300 of the shipment, formed before the moment of time 611 of starting it- to form the initialization file 310 of sending, and the last transaction completed before the moment of time 611 of the trigger for forming the initialization file 310 of sending. The OI TR 140 may then transfer (725) the dispatch initialization file 310 to the remote database 210. The dispatch initialization file 310 may contain a dispatch file identifier 615 corresponding to the last generated dispatch file 300 and a transaction identifier 620 that "

Corresponds to the last completed transaction. 8 shows a block diagram of an embodiment of the present invention in which a remote database can receive update files from a local database. The system can receive (805) several periodic ;" updates Each update can contain one or more transactions. Periodic updates can be received individually or in packages. At some point in time, the system may receive (810) an initialization update.

The initialization update may contain a version of the full local database. The system can read (815) from the initialization update the identifier of the last periodic update and the identifier of the last transaction.

The system can then determine (820) the last periodic update that corresponds to the update ID and the last transaction that corresponds to the transaction ID. Periodic update and transaction can be,

Ge) respectively, the last formed update and the last completed transaction before the formation of the update or initialization. The system may apply (825) the remaining pending transactions to the remote database in an appropriate periodic update. The system may then apply (830) to the remote database 4) the remaining periodic updates generated after the last periodic update. Applying an initialization update will preferably fill in any previously missed periodic updates.

For example, SHE 100 may receive (805) files 300 sent at some regular or irregular time interval. 300 shipment files can be received individually or in packages. At some point in time | OE 100 can receive (810) initialization file 310 of sending. (SOE 100 can read (815) from the initialization file

F) 310 sending identifier 615 of the sending file and identifier 620 of the transaction. The IO 100 may then determine (820) the send file 300 corresponding to the send file identifier 615 and the transaction 605 corresponding to the transaction identifier 620. The send file and the transaction may be, respectively, the last sent file generated and the last completed transaction before forming the initialization file 310 of the shipment. , remaining following the last send file 5-4.

In an alternative embodiment, for example, the SHE 100 may discard or archive the send files 300 65 that have not been applied to the remote database 210 and/or have a generation time 603 prior to the generation time 611 of the send initialization file. The discarded or archived send files 300 may include a shipment file 51-4 corresponding to a shipment file identifier 615.

It is understood that after the application of the initialization file 310 of the shipment, any later files 300 of the shipment that may have already been applied to the remote database 210 may not be preserved, because the remote database 210 may become read-unified with the initialization file 310 of the shipment.

Accordingly, these later shipment files 300 can be reused.

In an embodiment of the present invention, the send files 300 and the send initialization file 310 can be transferred from the local database 200 to the remote database 210 without a message about the successful receipt of the data, that is, without an ASK/MASK signal to indicate that the files have been successfully received. This mainly 7/0 reduces the additional service signaling that the ASK/MASK signal can create.

In an alternative embodiment, an ASK/MASK signal may be transmitted from the remote database 210 to indicate that the files have been successfully received. In this embodiment, the ASK/MASK signal can be transmitted in systems with unreliable communication.

Figure 9 is a block diagram of another embodiment of the present invention in which the system can verify the authenticity of update files transmitted from a local database and received in a remote database. Here, the system may transmit (905) a plurality of periodic updates. Each update can contain one or more transactions. Periodic updates can be delivered individually or in batches. At some point in time, the system may transmit (910) an initialization update and apply the initialization update to the remote database. The initialization update may contain a version of the full local database. First, the system, using database comparison, can identify (915) differences between local and remote databases. The system may determine (920) whether the discrepancies are valid or false. The system may then apply (925) periodic updates to the remote database, in accordance with an embodiment of the present invention. This version of the implementation, preferably, can ensure the absence of errors in the remote database, which is the result of receiving updates from the local database. with

For example, ОИ ТР 140 may transfer (905) to the remote database 210 the files 300 of the shipment with some regular or irregular time interval. The 300 shipment files can be sent individually or in i) packages. At some point in time, the UE TR 140 may transmit (910) the send initialization file 310 to the GE 100, and the UE 100 may apply the send initialization file 310 to the remote database 210. The UE TR 140 may compare the local database 200 with the remote database 210 and identify (915) differences between them. The OGTR 140 can then determine (920) whether the variances are valid or false. The OITR 140 can then inform the SHE 100 to apply (925) to the remote database 210 of the shipment files 300, according to an embodiment of the present invention. Then, the SOE 100 can apply the send files 300 to the remote Ge! database 210.

In an alternative embodiment, the system can use the shipment files and the shipment initialization file to identify and validate discrepancies. As another option, the system can use the shipment files and the shipment initialization file after identifying and verifying the authenticity of discrepancies.

It is understood that the authentication process can be performed on any data transmitted from the source to the addressee through the communication network to apply the transmitted data to the addressee. "

Fig. 10A shows a block diagram of a variant of the verification of the authenticity of the sending file and the sending initialization file, according to the present invention. After sending several periodic updates and initialization updates to the remote database, the system can verify the validity of the update data. Every;" an update may contain one or more transactions performed in the local database. Each transaction can contain one or more events. An event is an action or possible execution in a database, such as adding, changing, deleting, etc., with respect to data in the database. -And First, the system can compare (1000) records in the remote database with the corresponding record in the local database. The system may generate (1005) an exception describing the discrepancy between the records of the remote and local databases, and the exception may be generated for each discrepancy. Differences

Ge) there can be any difference in at least one data value between two versions of the same record.

For example, there may be a data entry in the local database (12345, khug.sot, 123.234.345). The corresponding record of pi data in the remote database, which is supposed to be identical, can correspond to (12345, ars.sot, 123.234.345). 4) Accordingly, there is a discrepancy in the second value of the record data. Therefore, an embodiment of the present invention may form an exception that describes the specified difference. An exception can describe a difference by simply indicating that there is a difference; determining the location of the divergence; describing the difference between two data values when diverging, etc. A record of data in the local database corresponds to a record of data in the remote database (and vice versa) if the two records necessarily contain identical data. (F) It is understood that a discrepancy may refer to a difference in one or more data values within a record or to a record in general.

The system may assign (1010) to each exception an exception identifier, where the exception identifier may correspond to a record identifier. For example, a data record (12345, hul.sot, 123.234.345) might have an identifier of 410. Accordingly, an exception identifier might also be 410. Each exception can be classified as belonging to any of several types of exceptions (or discrepancies) . An exception list can be generated to include exception types and an exception ID for the exceptions grouped there. The list of exclusions and the different types of exclusions are detailed below. The system may also assign (1015) to each event in the update an event ID, where the event ID may correspond to a record ID. For example, the data record (12345, hul.sot, 123.234.345) can have the identifier 410. Accordingly, the event identifier can also be a10. Each event in the update can be found from the event history. The background of events can be a listing, etc. events performed on local database records over a period of time. The background of the events is detailed below.

The system can then determine (1020) whether the record update is valid. Fig. 10B8 shows a block diagram of a variant of the implementation of the determination of the authenticity check. This definition can be made as follows. A comparison (1022) of each event with each exception may be made. If each exception is confirmed (1024) by an event, then the update can be determined (1026) as valid and the given update can be applied to the remote database. Otherwise, unless each exception is confirmed 7/0. Y1024) event, then the update may be determined (1028) as invalid, and exceptions may be logged as errors. An exception may be confirmed when the exception identifier matches the event identifier and the corresponding event corresponds to a valid sequence of events corresponding to the exception type. Valid sequences are detailed below. If the exclusion is confirmed, the system can remove the exclusion ID from the list of exclusions. A confirmed exception might indicate that the discrepancy is 7/5 true, for example, the remote database has not yet received an update, but when an update is received it will indeed match the local database.

During validation, the system may identify hidden errors or failures in periodic update and initialization updates. The system can provide the possibility of structural and semantic correctness of update data, the possibility of successful application of update data that does not cause the formation of exceptions or other unwanted stops, the possibility of accurate detection of errors when comparing local and remote databases with each other, and the impossibility of accidental deletion of significant data. The system can ensure that periodic updates and initialization updates are successfully applied to the remote database.

Most importantly, validation may reveal many errors that occur when trying to apply an update to a remote database. For example, an attempted application may encounter data centralization errors, warnings that the object already exists in the remote database, or (8) warnings that there is an external identifier violation. Therefore, after performing the validation process in accordance with an embodiment of the present invention, the system may attempt to apply said updates to the remote database. The attempt may fail, which may indicate the presence of additional errors in the updates that make the update invalid. Accordingly, additional attempts to apply the specified updates to the remote database cannot be made. -

In an alternative implementation, an attempt can be made before performing the validation. apply at least one of the updates. If the attempt is unsuccessful, the validation may be skipped and the update rejected. On the other hand, if the attempt is successful, a Mez5 validity check can be performed and the valid update is saved, and discrepancies are logged for the invalid update. Cha

In a possible variant of the implementation of the OI TR 140 can perform an authentication of the sending files З00 and the sending initialization files 310 to ensure the successful application to the remote database 210 of the sending files 300 and the sending initialization files 310 .

In alternative embodiments, authentication can be performed by network computers 121, “

ME 100 or any combination of existing systems. in c According to Fig. 10A, OY TR 140 can compare the local database 200 and the remote database 210 to determine any exceptions (or discrepancies) between them. Exceptions can include three types: in the remote database 210 there may be data that is not in the local database 200; the local database 200 may contain data that is not present in the remote database 210; or the corresponding data may exist in both the local database 200 and the remote database 210, but the data "may be different. Of course, -And the corresponding data may exist in both the local database 200 and the remote database 210, and the data may be identical, in this case the data can be considered reliable, therefore, no additional processing is required from ОИ ТР 140.

Ge) It is clear that the discrepancy may refer to one or more data values in the record or to

Recording in general. п Accordingly, ОИ ТР 140 may compare (1000) corresponding entries in the local database 200 and remote 4) database 210. ОИ ТР 140 may generate (1005) an exception that describes the discrepancy between the entry in the remote database 210 and the entry in the local database 200, and an exception can be generated for each discrepancy. ОИ TR 140 may assign (1010) to each exception an exception identifier, and the exception identifier may correspond to a record identifier. An exception list can be generated to include the exception types and the exception ID for the exception belonging to the type

F) exclusion. In an embodiment, an exception may be defined as a "List 1" exception (or difference) if the exception belongs to the first type of exceptions, a "List 2" exception if the exception belongs to the second type of exceptions, or a "List 3" exception if exclusion belongs to the third type of exclusions. because Fig. 11 illustrates a possible list of 1140 exceptions.

It is understood that the presence of an exception ID in the exception list does not mean that the send file 300 or the send initialization file 310 is not valid, since, for example, all three types of exceptions can reasonably occur due to a time delay between changes in the local database 200 and updates that apply to the remote database 310. Such a delay, for example, can be caused by 65 congestion of the communication network. In essence, robustness testing can provide a mechanism to exclude valid exceptions from erroneous data.

For the initialization file 310 of the shipment, the TR 140 can compare the local database 200 and the remote database 210 by performing a bidirectional lookup of all tables in both databases 200, 210.

That is, all the data in the local database 200 can be compared against all the data in the remote database 210. Then all the data in the remote database 210 can be compared against all the data in the local database 200. This preferably provides a comprehensive comparison of the databases 200, 210 to identify all discrepancies.

For the sending file 300, the TR 140 can compare only those data records in the local database 200 and the remote database 210, which are recorded in the sending file Z00. This primarily provides a fast-acting query to detect specified discrepancies. 70 Alternatively, data may be randomly sampled in the initialization file 310 of the shipment and/or the file 300 of the shipment. Then, the OI TR 140 can compare the randomly selected data in the local database 200 and the remote database 210.

The exception list 1140 may correspond to missing events, such as additions (ada), changes (tod), and deletions (aei) for the local database 200 that are inconsistent with the remote database 210. Therefore, to identify such candidate events, 140 may examine recent transactions committed to the local database 200. Basically, an entry for each committed transaction may be created in the registration table stored in the local database 200. An element can contain the identifier of the record that was changed, the transaction (or event) that changed the record (for example, ada, tod and/or dei), a registration sequence number that indicates the sequence of the transaction, etc.

A possible registration table 1100 is shown in Fig.11. In this possible embodiment, the sending file 300 contains transactions 1108-1114 depicted in the registration table 1100. The first element 1101 indicates that in the first transaction 1108, the (domain name server) data n! and n2 have been added to the data (domain) corresponding to identifier 41. Therefore, the identifier is ai, the event is add "ada", and the registration sequence number is 11526. Similarly, the second element 1102 indicates that in the second transaction 1109, data n8 and pO were added to the data corresponding to the identifier a2. The third element of the POZ indicates that in the third transaction 1110 the data corresponding to the identifier 43 was deleted. The fourth element 1104 indicates that in the fourth transaction 1111, i) the data corresponding to the identifier 41 has been changed to add data on. For the fifth transaction 1112, the fifth element 1105 indicates that the data pb and p7 have been added to the data corresponding to the identifier a3. For the sixth transaction 1113, the sixth element 1106 indicates that the data corresponding to the identifier 44 has been changed to remove the data p3. The K y element 1107 in the vy transaction 1114 indicates that the data corresponding to the identifier d5 has been deleted. M

Accordingly, according to Figt!OA, the TR 140 may assign (1015) to each event in the update an identifier. F) events, and the event identifier may correspond to the record identifier. Each event in the update can be found from the event history. A history of events, indexed and ordered by event identifier, can be generated from the registration table 1100. A possible history of 1120 events is shown in Fig. 11. Here, the first and fourth elements 1101, 1104 in the registration table 1100 indicate changes for the data corresponding to the identifier a1. Therefore, the background history 1120 of events contains the identifier 491 1121 and two events 1126, the addition of "ada" and the subsequent change "toy", performed on the data corresponding to the identifier 41. The second element 1102 « indicates the changes for the data corresponding to the identifier a2. So, event history 1120 contains 70 ID 42 1122 and event 1127 adding "hell". The background history 1120 of events contains the identifier aZ 1123 and 8 s two events 1128, the deletion of "where" followed by the change of "that", which is indicated by the third and fifth elements 1103, c 1105, which contain changes for the data corresponding to the identifier 43. Sixth element 1106 indicates changes for i" data corresponding to identifier 44. Accordingly, the event history 1120 contains the identifier 44 1124 and the change event 1129 "that". The BIY element 1107 indicates changes for the data corresponding to the identifier 5, and the event history 1120 contains identifier 45 1125 and event 1130 delete "ae!". Identifiers 1121-1125 -| are ordered from a1 to 45. so According to Fig. 10A, the OI TR 140 can determine (1020) whether the update is valid. This determination can be performed , for example, in accordance with the embodiment of Fig. 10B. First, the OI TR 140 may compare (Se) (1022) event identifiers 1121-1125 with exception identifiers 1140 to determine which identifiers 1" 50 have a match. For example, in accordance with Fig. 11, the identifier 1121 of event a1 in the chronology of 1120 events corresponds to the identifier of exception 41 in "List 2" of the list of 1140 exceptions. After detecting the corresponding event (45) and the exception, the OI TR 140 can determine (1024) whether the exception is confirmed by the event. Confirmation can be done as follows. For each identifier 1121-1125 of the event in the timeline of events 1120, the TR 140 can determine whether each sequence of events 1126-1130 in the timeline of events 1120 is valid. This can be done, for example, by examining the exception list 1140 to determine which exception type each exception identifier belongs to, a determination that should be valid

IF) the sequence of events for this type of exception, and then searching the history 1120 of the events for the corresponding name) of the event identifier and the sequence of events for the event identifier. Valid sequences for each type of exception are detailed below. If the sequence of events 1126-1130 in the timeline of events 1120 corresponds to a valid sequence 60, then the corresponding event ID 1121-1125 has a valid sequence. Basically, the exception matching the exception ID can be asserted. And, the corresponding transaction 1108-1114 containing the specified event ID is valid and not in error. In this case, the TR 140 can remove the exception identifier from the list of exceptions 1140.

For the "List 1" type of exceptions, a valid sequence of events can be (to) " (aeii). A given sequence 65 may contain a sequence of zero or more change events "toi" followed by a deletion event "de" followed by an arbitrary event The exception type "List 1" may correspond to data that may exist in the remote database 210 but not be present in the local database 200. In this case, the data may have been recently deleted from the local database 200 and the transaction has not yet occurred recorded in file 300 shipments.

Therefore, the send file 300 could not yet be applied to the remote database 210. Thus, this data

may still remain in the remote database 210. This may be considered a reasonable variance because it is assumed that at some point in time the dispatch file 300 will be generated and applied to the remote database 210. Therefore, if for the exception ID in List 1 of the list 1140 of exceptions in If any such sequence 1126-1130 is detected in the timeline 1120 of events, then the corresponding transaction can be considered valid. 70 For example, in accordance with Fig. 11, the identifier a5 1125 and its corresponding data have been deleted from the local database 200, as illustrated by element 1114 of the registration table 1100 and indicated by the chronology 1120 of events. During validation, 45 was deleted from local database 200 but not from remote database 210. Therefore, exclusion list 1140 contains ID a5 in Listing 1. According to event timeline 1120, event 1130 corresponding to ID 45 1125 is removing "where!". ОИ ТР 140 can compare a valid 75 sequence of exception type "List 1", ie (tod) " (dae), with event 45 1130 in the chronology of 1120 events.

Since the valid sequence of "List 1" and the event 1130 match, then the transaction 1114 deletion corresponding to the identifier 45 can be considered valid and not an error. Accordingly, the identifier a5 can be removed from the list of 1140 exceptions.

A valid sequence of events for the "List 2" exception type can be (ad4a). A given sequence may contain an add event "ada" followed by an arbitrary event. The "List 2" exception type may correspond to data that exists in the local database 200 but does not exist in the remote database 210. In this case, the data may have been recently added to the local database 200 and the transaction has not yet been written to file З00 sending Therefore, the send file 300 may not yet have been applied to the remote database 210. Therefore, the data may not exist in the remote database 210. This may also be considered a reasonable variance, since the send file 300 is expected to be generated at some point in time. and applied to the remote database 210. Accordingly, if any such sequence 1126-1130 in the event timeline 1120 is found for the exception ID in List 2 of the exception list 1140, then the corresponding transaction may be considered valid.

According to Fig. 11, the identifiers 41 and a2 1121, 1123 can be mapped to data that, for example, was initially added to the local database 200. Since the sequence of events 1126, 1127 for them begins with the addition event "ada", then identifiers a1 and 42 1121, 1123 correspond to valid sequences for the type in "List 2" exceptions. Accordingly, transactions 1108, 1109, containing the specified identifiers, can be considered Ge"! valid, and IDs 41 and 42 can be removed from the 1140 exclusion list. It should be noted that identifier 43 1123 also contains the event "ada" in its sequence 1128. However, the event of addition of 3z5 ada" is not the first in the sequence 1128. Accordingly, the sequence 1128 does not belong to the type "List 2". -

Additionally, since 43 is not listed in List 2 of the 1140 list of exclusions, OJ TR 140 cannot verify it against a reliable sequence for List 2.

Valid sequences of events for the List C exception type can be (aeii), (ada), or (tod). Sequence data may contain a deletion event "de!" followed by an addition event "ada" followed by an arbitrary 70 event, or a change event "toa" followed by an arbitrary event. The type of exceptions "List 3" may correspond to data 8 that exist in both databases 200, 210, but are different. In this case, the data may have recently changed in the local database 200 and the transaction has not yet been written to the file 300 sent. Therefore, the send file 300 could not yet be applied to the remote database 210. Therefore, the data corresponding to the identifier may not yet have been modified in the remote database 210. Again, this may be considered a reasonable variance because it is expected that at some point in time, the dispatch file 300 will be generated and applied to -I the remote database 210. Accordingly, if any such sequence 1126-1130 is found in the event timeline 1120 for the exception ID in "List 3" of the exception list 1140, then the corresponding transaction o can be considered valid.(Se) For example, according to Fig.11, the identifiers 43 and 44 1123, 1124 can be mapped to the data that has been changed in the local database 200. In the case of the identifier az 1123, the identifier az 1123 and its the data t was first deleted and then added back with the new data, so that the sequence of events 1128 may include the deletion of "dei" followed by the addition of "ada". In the case of identifier a4 1124, the data 44 have been modified to remove data so that sequence of events 1129 may contain the change "that". Since the indicated sequences of events 1128, 1129 correspond to the valid sequences for the type of exclusions "List 3", the corresponding transactions 1110, 1112, 1113 can be considered valid, and identifiers 43 and a4 can be removed from the list 1140 of exceptions. 10B) According to Fig. 10B, if all the exceptions marked in the list of exceptions 1140 with their identifiers were justified by (1024) events, for example, if the list of exceptions 1140 is empty, then the OI TR 140 can determine (1026) the file 300 of sending or send initialization file 310 as valid and inform ESR 100 to apply send file 300 or send initialization file 310 to remote database 210.

The GOE 100 may then apply the send file 300 or the send initialization file 310 to the remote database 210 .

Conversely, if all exceptions have not been confirmed by (1024) events, for example, if the list of exceptions 1140 is not empty, then the remaining exceptions may indicate errors in the file Z00 of the shipment or the initialization file 65 of the shipment 310. Accordingly, the OI TR 140 may determine (1028) the sending file Z00 or the sending initialization file 310 as invalid and log errors in the error file.

In an alternative embodiment, if, for example, the send file 300 or the send initialization file 310 was determined to be untrusted, then after a predetermined period of time, the TR 140 may repeat the validation process against the untrusted send file 300 or the send initialization file 310 to confirm that that differences are indeed errors. This predetermined delay provides the network with more time to transfer any slow file 300, 310 sending, and more time for the databases 200, 210 to become read-unified.

In an embodiment of the present invention, the data in the remote database 210 may "lag" the data in the local database 200 by a significant time interval. Accordingly, for comparing the databases 200, 210 and for 7/0 error detection, the databases 200, 210 can be made read-unified at the point in time when they become exact copies of each other. Basically, the remote database 210 can be brought, with all completed transactions repeated, to the local database 200, and the data in the remote database 210 can be made substantially identical to the data in the local database 200.

Accordingly, to speed up validation, any currently generated file 7/5 initialization 310 of the shipment and subsequent files 300 of the shipment may be applied to the remote database 210 before validation begins. In fact, the number of discrepancies can be significantly reduced. Such batch processing of the sending files 300, 310 can be defined as the formation of blocks. The first and last of these sending files 300, 310 in the block may be referred to as the lower and upper "watermarks", respectively. The first block, called the initial block, may contain the initialization file 310 of the shipment. All subsequent blocks, which are called end blocks, can only contain 300 send files.

Block formation can provide group validation instead of individual validation.

Accordingly, when an error is detected in a block, the entire block can be marked as invalid, not just the file

C00 shipment or initialization file 310 shipment where the error occurred.

Mechanisms and methods corresponding to the variants of implementation of this invention can be implemented with the use of a universal microprocessor programmed in accordance with the variants of implementation. Thus, embodiments of the present invention also include computer-readable media that can i) contain instructions that can be used to program a processor to perform a method according to embodiments of the present invention. This media can include any type of disc, including floppy disc, optical disc, SO-COM compact discs, etc. Several embodiments of the present invention have been described and illustrated in detail above. However, it should be obvious that changes and modifications of the invention, which are covered by the above description and the appended claims, can be made without deviating from the essence and scope of this invention. b

Claims (27)

Formula of the invention 35 and - 1. A method of updating a remote database over a network, comprising: generating a plurality of periodic updates based on incremental changes in a local database, and each of the plurality of periodic updates contains at least one transaction, "transmitting a plurality of periodic updates to a remote database over a network , w-v s, while forming a set of periodic updates, perform: formation of an initializing update containing the version of the local database at the time of startup, :z" determination of the last periodic update from a set of periodic updates based on the time of startup, determination of the last transaction on based on the moment of the start time and -I transfer over the network to the remote database the initializing update, the identifier of the last periodic update and the identifier of the last transaction for use and) when updating a separate database. so 2. The method according to claim 1, in which the transfer of the initializing update includes: matching with the last periodic update of the identifier of the last periodic update and - matching with the last transaction of the identifier of the last transaction. c" Z. The method according to claim 1, in which the plurality of periodic updates are generated at regular or irregular time intervals. 4. The method according to claim 1, in which the moment in time of starting the formation of the initializing update is identical to the moment in time of starting the formation of the periodic update. 5. The method according to claim 1, in which the time of starting the formation of the initializing update is later than (F) the time of starting the formation of the periodic update. GI 6. The method according to claim 1, in which the periodic update contains a plurality of transactions, each of which has a unique transaction identifier. in 7. A method of updating a remote database over a network, comprising: receiving over a network a plurality of periodic updates that are based on incremental changes in a local database, each of the plurality of periodic updates containing at least one transaction, receiving over a network an initialization update containing a version of the local database at startup time, 65 reading from the initialization update of the identifier of the last periodic update, reading from the initialization update of the identifier of the last transaction, determining the last periodic update from the last periodic update identifier, said determination of the last periodic update being based on a start time, determining the last transaction from the last transaction identifier, said determination of the last transaction being based on the start time, applying to a remote database of transactions generated after of the last transaction, and applying to the remote database periodic updates generated since the last periodic update. 8. The method according to claim 7, which additionally includes: 70 discarding the periodic updates formed up to the time of starting the initializing update. 9. The method according to claim 7, in which a plurality of periodic updates are received one at a time at periodic time intervals. 10. The method according to claim 7, in which the plurality of periodic updates are received in packets at periodic time intervals. 11. The method according to claim 7, in which the periodic update contains a plurality of transactions, each of which has a unique transaction identifier. 12. A method of updating a remote database over a network, comprising: generating a plurality of periodic updates based on incremental changes in a local database, each of the plurality of periodic updates containing at least one transaction, and generating an initialization update containing a version of the local database in the trigger time, the update ID corresponding to the last periodic update generated before the trigger time, and the transaction ID corresponding to the last transaction completed before the trigger time, and transmitting over the network to the remote database the initializing update , the update ID, and the transaction ID . 13. The method according to claim 12, in which a plurality of periodic updates are generated at regular time intervals. 14. The method according to claim 12, in which a plurality of periodic updates are generated at irregular time intervals. high school 15. The method according to claim 12, in which the instant of time of starting the formation of the initializing update is identical to the moment of the start of the formation of the periodic update. and) 16. The method according to claim 12, in which the instant of time of starting the formation of the initializing update is later than the moment of the start of the formation of the periodic update. 17. A system for updating a remote database over a network, comprising: c zo at least one processor connected to the network, and memory connected to the processor, which contains the local database and commands adapted to be executed by the processor method of updating a remote database over the network, while the specified commands include commands for forming a set of periodic updates that are based on incremental changes in the local database, and each of the set of periodic updates contains at least one transaction, i- transmitting a plurality of periodic updates to a remote database over a network, wherein the commands for generating the plurality of periodic updates include commands for generating an initialization update containing the version of the local database at the time of startup, determining the last periodic update from the plurality of periodic updates based on the time time « Start, sshh s determination of the last transaction based on the moment of the start time and before achi over the network to the remote database of the initializing update, the identifier of the last ;" periodic update and last transaction ID. 18. The system according to claim 17, in which when transmitting the initialization update, the last periodic update is mapped to the identifier of the last periodic update, and -I the last transaction is mapped to the identifier of the last transaction. 19. The system according to claim 17, in which a plurality of periodic updates are generated at regular or irregular time intervals. Gee) 20. The system according to claim 17, in which the instant of time of starting the formation of the initializing update is identical to the moment of time of starting the formation of the periodic update. ve 21. The system according to claim 17, in which the instant of time of starting the formation of the initializing update is later than 4) the moment of the start of the formation of the periodic update. 22. The system of claim 17, wherein the periodic update comprises a plurality of transactions, each of which has a unique transaction identifier. 23. A system for updating a remote database over a network, comprising: at least one processor connected to the network, and (F, memory connected to the processor, which contains the local database and commands adapted to execute the by a processor, to update a remote database over a network, wherein said commands include commands for receiving over a network a plurality of periodic updates based on incremental changes in a local database, each of the plurality of periodic updates containing at least one transaction, receiving via an initialization update network containing the version of the local database at startup time, reading from the initialization update the identifier of the last periodic update, 65 reading from the initialization update the identifier of the last transaction, determining the last periodic update from the identifier of the last periodic update, wherein the last periodic update is based on the start time, determining the last transaction from the last transaction ID, wherein the last transaction is based on the start time, applying to the remote database transactions formed since the last transaction, and applying to the remote database periodic updates formed since the last periodic update. 24. The system according to claim 23, in which said commands additionally include commands for discarding periodic updates generated up to the time of starting the initializing update. 70 25. The system of claim 23, in which a plurality of periodic updates are received one at a time at regular or irregular time intervals. 26. The system of claim 23, wherein the plurality of periodic updates are received in packets at regular or irregular time intervals. 27. The system of claim 23, wherein the periodic update comprises a plurality of transactions, each having a unique 7/5 transaction identifier, wherein the transaction identifiers are randomly ordered. c schi 6) (ze) « (o) (o) and - - and? -i se) se) sh» syu» ime) 60 b5