UA79943C2 - Спосіб і система для оновлення віддаленої бази даних (варіанти) - Google Patents

Abstract

Спосіб і система для оновлення віддаленої бази даних відноситься до галузі безпровідного зв’язку. Відповідно до способу формується множина періодичних оновлень, що базуються на інкрементних змінах у локальній базі даних (200). Кожне з періодичних оновлень містить щонайменше одну транзакцію. Формується оновлення ініціалізації, що містить версію локальної бази даних у момент часу запуску. Додатково формуються ідентифікатор, що відповідає останньому періодичному оновленню, сформованому до моменту часу запуску, та ідентифікатор, що відповідає останній транзакції, завершеній до моменту часу запуску.

Description

Опис винаходу

Вимога на пріоритет/перехресне посилання на пов'язані заявки. 2 Дана не попередня заявка заявляє пріоритет попередньої (заявки на патент США з реєстраційнім номером 60/330.842 від 1 листопада 2001 року), повністю включеної у даний опис за допомогою посилання, і попередньої заявки на патент США з реєстраційним номером 60/365.169 від 19 березня 2002 року), повністю включеної у даний опис за допомогою посилання.

Даний винахід відноситься до комп'ютерних баз даних, більш конкретно, до способу і системи для достовірного оновлення бази даних.

Зі збільшенням розміру баз даних і внаслідок їх сильно розподіленої структури стає все в більшій мірі проблематичним забезпечення однакових версій даних у пов'язаних базах даних. Якщо відбуваються істотні зміни в одній базі даних, то може бути потрібне оновлення інших баз даних для включення вказаних змін у найкоротші терміни. Здійснення таких оновлень може спричинити часте переміщення великих об'ємів даних 79 оновлення у декілька баз даних. Потенційно такий процес може бути надзвичайно складним.

Вказана проблема додатково поєднується з ненадійним зв'язком у системах. У цьому випадку дані можуть бути втрачені при транспортуванні. При цьому потрібна повторна передача даних, і інші бази даних знову оновлюються. Таке повторення істотно знижує ефективність системи і зменшує ділянку, в якій бази даних містять найновіші дані.

Фіг.1 - структурна схема системи, відповідно до варіанту здійснення даного винаходу.

Фіг.2 - структурна схема системи концентратора, відповідно до варіанту здійснення даного винаходу.

Фіг.3 ілюструє можливу передачу оновлень бази даних з локальної бази даних у віддалену базу даних, відповідно до варіанту здійснення даного винаходу.

Фіг.4 ілюструє файл відправки, відповідно до варіанту здійснення даного винаходу. с

Фіг.5 ілюструє файл ініціалізації відправки, відповідно до варіанту здійснення даного винаходу. Ге)

Фіг - часова діаграма, що ілюструє формування файлу відправки та файлу ініціалізації відправки, відповідно до варіанту здійснення даного винаходу.

Фіг.7 - блок-схема варіанту здійснення даного винаходу, в якому можуть бути сформовані файли оновлення локальної бази даних. Ше

Фіг.8 - блок-схема варіанту здійснення даного винаходу, в якому віддалена база даних може одержувати «Її файли оновлення з локальної бази даних.

Фіг.9 - блок-схема іншого варіанту здійснення даного винаходу, в якому віддалена база даних може Ме. одержувати файли оновлення з локальної бази даних і перевіряти їх достовірність. Ге»)

Фіг1ОА - блок-схема варіанту здійснення даного винаходу, в якому може бути перевірена достовірність 3о файлів оновлення. в

Фіг1оВ - блок-схема іншого варіанту здійснення даного винаходу, в якому може бути перевірена достовірність файлів оновлення.

Фіг.11 - ілюстрація перевірки достовірності файлу оновлення, відповідно до варіанту здійснення даного « винаходу. З

Варіанти здійснення даного винаходу забезпечують спосіб і систему для достовірного оновлення віддаленої с бази даних через мережу зв'язку. Відповідно до варіантів здійснення, формується декілька періодичних оновлень

Із» (далі по тексту "файл відправки"), що базуються на додаткових змінах у локальній базі даних. Кожне з періодичних оновлень містить, щонайменше, одну транзакцію. Формується оновлення ініціалізації (далі по тексту "файл ініціалізації відправки"), що містить версію локальної бази даних у момент часу запуску. Додатково формуються ідентифікатор, що відповідає останньому періодичному оновленню, сформованому перед і моментом часу запуску, та ідентифікатор, що відповідає останній транзакції, завершеній до моменту часу (се) запуску. Варіанти здійснення, переважно, забезпечують автономізацію файлів відправки та файлу ініціалізації відправки для достовірного оновлення віддалених баз даних. о Фіг.1 - структурна схема, що ілюструє систему, відповідно до варіанту здійснення даного винаходу. В ї» 20 основному система 100 може містити велику резиденту базу даних, через мережу зв'язку одержувати запити на пошук і забезпечувати відповіді по пошуку. Наприклад, система 100 може являти собою симетричний с» багатопроцесорний (ЗМР) комп'ютер, наприклад, такий як ІВМ К5З/б60009М80 або 580, що виробляється компанією ІВМ (АгтопКк, штат Нью-Йорю), Зп Епіегргізетм 10000, що виробляється Зцп Місговувіетв (Запіа

Сіага, штат Каліфорнія), і т.д. Система 100 також може являти собою багатопроцесорний персональний 99 комп'ютер, наприклад, такий як СотрадР"гої іапітмМІі 530 (що має два процесори Іпів! РепіїштФ Ії, 866МГц), що

ГФ) виробляється компанією Неміейк-Раскага (Раю Айо, штат Каліфорнія). Система 100 може також містити 7 багатопроцесорну операційну систему, наприклад, таку як ІВМ АЇХФО 4, Зи!ип Зоіагізтм 8 Орегайпд Епмігоптепі,

Кей Нас і ІМмОхе 6.2, і т.д. Система 100 може одержувати через мережу 124 зв'язку періодичні оновлення, які до Можуть паралельно включатися у базу даних. Варіанти здійснення даного винаходу можуть досягати дуже високої продуктивності оновлення і пошуку по базі даних за допомогою включення кожного оновлення у базу даних без використання блокування бази даних або засобів керування доступом.

У варіанті здійснення система 100 може містити, щонайменше, один процесор 102-1, приєднаний до шини 101. Процесор 102-1 може містити внутрішній кеш (наприклад, кеш 11, не зображений). Між процесором 102-1 і в5 шиною 101 може бути резидентно розміщений кеш 103-1 вторинної пам'яті (наприклад, кеш 12, кеші І 2/3 і т.д.).

У переважному варіанті здійснення система 100 може містити декілька процесорів 102-1...102-Р, приєднаних до шини 101. Між декількома процесорами 102-1...102-Р і шиною 101 також може бути резидентно розміщено декілька кешів 103-1...103-Р вторинної пам'яті (наприклад, архітектура крізного перегляду) або, у вигляді іншого варіанту, до шини 101 може бути приєднаний, щонайменше, один кеш 103-1 вторинної пам'яті (наприклад, архітектура з передісторією). Система 100 може містити пам'ять 104, наприклад, таку як оперативний запам'ятовуючий пристрій (ОЗП), і т.д., приєднану до шини 101 для зберігання інформації та інструкцій, які повинні виконуватися декількома процесорами 102-1...102-Р.

Пам'ять 104 може зберігати велику базу даних, наприклад, для перетворення імен доменів Інтернет в адреси в Інтернет, для перетворення імен або номерів телефонів у мережні адреси, для забезпечення і оновлення /о даних профілю абонента, для забезпечення і оновлення даних присутності користувача, і т.д. Переважно, розмір бази даних і кількість перетворень за секунду можуть бути дуже великими. Наприклад, пам'ять 104 може містити, щонайменше, 64Гбайт ОЗП і може містити базу даних імен доменів у 5О0ОМ (тобто, 500х1059) записів, базу даних абонентів у 5О0М записів, базу даних мобільності номерів телефонів у 450М записів і т.д.

У можливій архітектурі 64-бітової системи, наприклад, такої як система, що містить, щонайменше, один 75 64-бітовий процесор 102-1 зі зворотним порядком байтів, приєднаний, щонайменше, до 64-бітової шини 101, |і 64-бітову пам'ять 104, 8-байтове значення покажчика може бути записане в адресу (комірки) пам'яті на межі 8-байтів (тобто, адреса пам'яті, що ділиться на вісім, або, наприклад, 8М) з використанням одиночної безперервної операції. В основному наявність кешу 103-1 вторинної пам'яті може просто затримувати запис 8-байтового покажчика у пам'ять 104. Наприклад, в одному варіанті здійснення кешем 103-1 вторинної пам'яті може бути кеш крізного перегляду, що діє у режимі крізного запису так, щоб одиночна команда збереження 8-байтів могла переміщати вісім байтів даних з процесора 102-1 у пам'ять 104 без переривання і всього лише за два такти системних годин. В іншому варіанті здійснення кешем 103-1 вторинної пам'яті може бути кеш крізного перегляду, що діє у режимі зворотного запису так, щоб 8-байтовий покажчик міг бути спочатку записаний у кеш 103-1 вторинної пам'яті, який потім, у більш пізній час, може записати 8-байтовий покажчик у пам'ять 104, с наприклад, при запису у пам'ять 104 рядка кешу, в якому зберігається 8-байтовий покажчик (тобто, наприклад, коли "скидається у пам'ять" визначений рядок кешу, або повністю кеш вторинної пам'яті). і9)

Зрештою, з точки зору процесора 102-1, як тільки дані фіксуються вихідними контактами процесора 102-1, всі вісім байтів даних записуються у пам'ять 104 в одній постійній, безперервній передачі, яка може бути затримана діями кешу 103-1 вторинної пам'яті, якщо він є у наявності. З точки зору процесорів 102-2...102-Р, со зо як тільки дані фіксуються вихідними контактами процесора 102-1, всі вісім байтів даних записуються у пам'ять 104 в одній постійній, безперервній передачі, яка призначена протоколом узгодженості кешу по кешах М 103-1...103-Р вторинної пам'яті, які можуть затримувати запис у пам'ять 104, якщо є у наявності. Ге»!

Однак, якщо 8-байтове значення покажчика записується у невирівняну комірку пам'яті 104, наприклад, адреса пам'яті, що перетинає межу 8-байтів, то всі вісім байтів даних не можуть бути передані з процесора 102-1 з о використанням одиночної команда збереження 8-байтів. Замість цього процесор 102-1 може видати дві різні і - окремі команди збереження. Наприклад, якщо адреса пам'яті починається за чотири байти до межі 8-байтів (наприклад, 8М-4), то перша команда збереження передає у пам'ять 104 чотири старших байти (наприклад, 8-4), у той час як друга команда збереження передає у пам'ять 104 чотири молодших байти (наприклад, 8М). «

Істотно, що між цими двома окремими командами збереження процесор 102-1 може одержати переривання, або процесор 102-1 може звільнити керування шиною 101 для іншого компонента системи (наприклад, процесора - с 102-Р і т.д). Отже, значення покажчика, що резидентно знаходиться у пам'яті 104, буде недійсним, доки ц процесор 102-1 не зможе завершити другу команду збереження. Якщо інший компонент починає одиночне "» безперервне зчитування пам'яті у дану комірку пам'яті, то недійсне значення буде повернене, як припустимо дійсне.

Аналогічно, нове 4-байтове значення покажчика може бути записане в адресу пам'яті, що ділиться на чотири -І (наприклад, 4М), з використанням одиночної безперервної операції. Потрібно зазначити, що у можливому варіанті, описаному вище, 4-байтове значення покажчика може бути записане у комірку пам'яті 8М-4 з ї-о використанням одиночної команди збереження. Безумовно, якщо 4-байтове значення покажчика записується у (Се) комірку, що перетинає межу 4-байтів, наприклад, 4М-2, то всі чотири байти даних не можуть бути передані з процесора 102-1 з використанням одиночної команди збереження, і значення покажчика, резидентно розміщене е у пам'яті 104, може бути недійсним протягом деякого періоду часу. с» Система 100 також може містити постійний запам'ятовуючий пристрій (ПЗП) 106, або інші статичні запам'ятовуючі пристрої, приєднані до шини 101, для зберігання статичної інформації та інструкцій для процесора 102-1. Для зберігання інформації та команд до шини 101 може бути приєднаний запам'ятовуючий пристрій 108, такий як магнітний або оптичний диск. Система 100 також може містити пристрій 110 відображення (наприклад, монітор на рідких кристалах СО (РДК)) і пристрій 112 введення даних (наприклад, клавіатуру, іФ) мишу, кульовий покажчик і т.д.), приєднані до шини 101. Система 100 може містити декілька мережних ко інтерфейсів 114-1...114-О, які можуть передавати і приймати електричні, електромагнітні або оптичні сигнали, що несуть потоки цифрових даних, які являють собою різні види інформації. У варіанті здійснення мережний бо інтерфейс 114-1 може бути приєднаний до шини 101 і до локальної мережі зв'язку ГАМ (ЛМ) 122, у той же час мережний інтерфейс 114-О може бути приєднаний до шини 101 і глобальної мережі зв'язку УУАМ (ГМ) 124.

Декілька мережних інтерфейсів 114-1...114-0 можуть підтримувати різні мережні протоколи, включаючи, наприклад, Сідабії Е(Пегпеї (наприклад, ІЕЕЄ Стандарт 802.3-2002, виданий у 2002), Рірег Спаппеї! (наприклад,

АМЗ5І Стандарт Х.3230-1994, виданий у 1994) і т.д. До ЛМ 122 і ГМ 124 може бути приєднано декілька мережних 65 Комп'ютерів 120-1...120-М. В одному варіанті здійснення ЛМ 122 і ГМ 124 можуть бути фізично окремими мережами зв'язку, у той же час в іншому варіанті здійснення ЛМ 122 і ГМ 124 можуть бути з'єднані через мережний шлюз або маршрутизатор (для зручності не зображені). Як інший варіант, ЛМ 122 і ГМ 124 може бути однією і тією ж мережею зв'язку.

Як зазначено вище, система 100 може забезпечувати послуги розрізнення ОМ5 (служба імен доменів). У варіанті здійснення для розрізнення (процесу визначення адрес) ОМЗ послуги розрізнення ОМ в основному можуть бути розділені між транспортуванням по мережі і функціями пошуку даних. Наприклад, система 100 може бути механізмом пошуку (ЦЕ) для сервера, оптимізованим для пошуку даних по великих наборах даних, у той же час множина мережних комп'ютерів 120-1...120-М може бути множиною механізмів протоколу (РЕ) клієнта, оптимізованих для обробки мережі зв'язку і транспортування. | ШЕ може бути потужним багатопроцесорним /о бервером, який зберігає у пам'яті 104 весь набір записів ОМ5, щоб сприяти високошвидкісному високопродуктивному пошуку і оновленню. В іншому варіанті здійснення послуги розрізнення ОМ можуть забезпечуватися множиною потужних багатопроцесорних серверів, або множиною І ШОЕ, кожний з яких зберігає у пам'яті підмножину всього набору записів ОМ, щоб сприяти високошвидкісному високопродуктивному пошуку і оновленню.

Навпаки, множина РЕ може бути звичайними вузькоспеціалізованими пристроями, які базуються на РС, що виконують ефективну багатозадачну операційну систему (наприклад, Кей Наї ГІМОХО 6.2), які мінімізують транспортне навантаження обробки мережі зв'язку на | ШЕ для максимізації доступних ресурсів для розрізнення

ОМ. Пристрої РЕ можуть обробляти нюанси протоколу ОМ5 провідної лінії зв'язку, реагувати на недійсні запити

ОМ та мультиплексувати дійсні запити ОМЗ в ШЕ через ЛМ 122. В іншому варіанті здійснення, що містить 2о Множину ЦОЕ, які зберігають підмножини записів ОМ5, РЕ можуть визначати, який пристрій | ОЕ повинен одержати кожний дійсний запит ОМ, і мультиплексувати дійсні запити ОМ у відповідні І ШЕ. Кількість РЕ для одного (ШОЕ може визначатися, наприклад, кількістю запитів ОМ, яка повинна оброблятися за секунду, і робочими характеристиками конкретної системи. Для визначення співвідношень відповідності і режимів також можуть використовуватися інші показники. с

У загальному випадку, можуть підтримуватися інші варіанти здійснення великого об'єму, які базуються на запитах, що включають, наприклад, розрізнення номерів телефонів, обробку сигналізації 557, визначення для і) геолокації, встановлення відповідності номера телефону з абонентом, визначення місцеположення і присутності абонента і т.д.

У варіанті здійснення центральний сервер 140-1 оперативної обробки транзакцій (ОЇ ТР) може бути со зо приєднаний до ГМ 124 і одержувати з різних джерел додатки, зміни і видалення (тобто, трафік оновлення) для бази даних 142-1. ОЇ ТР сервер 140-1 може передавати оновлення через ГМ 124 у систему 100, яка містить - локальну копію бази даних 142-1. ОЇ ТР сервер 140-1 може бути оптимізований для обробки трафіку оновлення у Ге! різних форматах і протоколах, включаючи, наприклад, Протокол Передачі Гіпертекстових файлів (НТТР),

Протокол Реєстратора Запису (ККР), Нарощуваний Протокол |Ініціалізації (ЕРР), Систему Керування ме)

Службами/Механізований Загальний Інтерфейс (МО) 800, та інші оперативні протоколи ініціалізації. Сукупність ї-

ІОЕ тільки для читання може бути розгорнена в архітектурі типу концентратора і спиці (лінії, що йде від центра до периферії) для забезпечення можливості високошвидкісного пошуку, який супроводжується об'ємними додатковими оновленнями з ОЇ ТР сервера 140-1.

В альтернативному варіанті здійснення дані можуть бути розподілені по декількох ОЇТР серверах « 40. 140-1...140-5, кожний з яких може бути приєднаний до ГМ 124. ОЇ ТР сервера 140-1...140-5 можуть одержувати з -птш) с різних джерел додатки, зміни і видалення (тобто, трафік оновлення) для баз даних, що відповідають їм, 142-1...142-5 (не зображені для зручності). ОЇ ТР сервера 140-1...140-5 можуть передавати оновлення через ГМ з 124 у систему 100, яка може містити копії баз даних 142-1...142-5, інші динамічно створювані дані і т.д.

Наприклад, у варіанті здійснення для геолокації, ОЇ ТР сервера 140-1...140-5 можуть одержувати трафік оновлення з груп віддалених датчиків. В іншому альтернативному варіанті здійснення множина мережних -І комп'ютерів 120-1...120-М також може одержувати через ГМ 124 або ЛМ 122 додатки, зміни і видалення (тобто, трафік оновлення) з різних джерел. У цьому варіанті здійснення множина мережних комп'ютерів 120-1...120-М і, може передавати у систему 100 оновлення, а також запити.

Ге) У варіанті здійснення розрізнення ОМ5 кожний РЕ (наприклад, кожний з множини мережних комп'ютерів 120-1...120-М) може комбінувати, або мультиплексувати, декілька повідомлень-запитів ОМ, одержаних через ве глобальну мережу зв'язку (наприклад, ГМ 124), в одиночний СуперПакет Запиту і передавати СуперПакет Запиту 4) через локальну мережу зв'язку (наприклад, ЛМ 122) в ШЕ (наприклад, систему 100). | ОЕ може комбінувати, або мультиплексувати, декілька відповідей на повідомлення-запити ЮОМ5 в одиночний СуперПакет Відповіді і передавати СуперПакет Відповіді через локальну мережу зв'язку у відповідний РЕ. В основному, максимальний ов розмір СуперПакету Відповіді або Запиту може бути обмежений максимальним блоком передачі (МТ) фізичного мережного рівня (наприклад, Сідабії Е(пегпе). Наприклад, стандартні розміри повідомлення запиту і відповіді (Ф) ОМ, що не перевищують 100 байтів і 200 байтів, відповідно, дозволяють мультиплексувати більше 30 запитів в ка одиночний СуперПакет Запиту, а також мультиплексувати більше 15 відповідей в одиночний СуперПакет

Відповіді. Однак, в одиночний СуперПакет Запиту може бути включена менша кількість запитів (наприклад, 20 бо запитів), щоб при формуванні відповіді уникнути переповнення МТИ (наприклад, у 10 відповідей). Для МТ більшого розміру кількість мультиплексованих запитів і відповідей, відповідно, може бути збільшена.

Кожний багатозадачний РЕ може мати вхідний потік і вихідний потік для керування запитами і відповідями р, відповідно. Наприклад, вхідний потік може демаршалінгувати (розпаковувати) компоненти запиту ОМ5 з вхідних пакетів запитів ОМ5, одержаних через глобальну мережу зв'язку, і мультиплексувати декілька мілісекунд 65 запитів в одиночний СуперПакет Запиту. Потім вхідний потік може передавати СуперПакет Запиту Через локальну мережу зв'язку в ШЕ. Навпаки, вихідний потік може одержувати СуперПакет Відповіді з ГЕ,

демультиплексувати відповіді, що містяться в ньому і маршалінгувати (упаковувати у стандартний формат) різні поля у дійсну відповідь ОМ, яка потім може бути передана через глобальну мережу зв'язку. В основному, як зазначено вище, можуть підтримуватися інші варіанти здійснення великого об'єму, що базуються на запитах.

У варіанті здійснення СуперПакет Запиту може також містити інформацію про стан, яка відповідає кожному запиту ОМ5, наприклад, таку як вихідна адреса, вид протоколу і т.д. | ОЕ може включати у СуперПакет Відповіді інформацію про стан і відповідні відповіді ОМ. Потім кожний РЕ може формувати і повертати повідомлення дійсних відповідей ОМ5 з використанням інформації, переданої з (ШЕ. Отже, кожний РЕ може, переважно, функціонувати як пристрій, що не змінює свого стану у процесі виконання, тобто, дійсні відповіді ОМ5 можуть 70 бути сформовані з інформації, що міститься у СуперПакеті Відповіді. В основному, (ШЕ може повертати

СуперПакет Відповіді в РЕ, з якого виходив вхідний СуперПакет, однак, очевидні інші можливі варіанти.

В альтернативному варіанті здійснення кожний РЕ може підтримувати інформацію про стан, яка відповідає кожному запиту ОМ, і включати у СуперПакет Запиту посилання, або дескриптор, на інформацію про стан. І ОЄЕ може включати у СуперПакет Відповіді посилання на інформацію про стан і відповідні відповіді ОМ. Потім кожний РЕ може формувати і повертати повідомлення дійсних відповідей ОМ5 з використанням посилань на інформацію про стан, переданих з ШОЕ, а також підтримуваної ним інформації про стан. У цьому варіанті здійснення | ШЕ може повертати СуперПакет Відповіді в РЕ, з якого виходив вхідний СуперПакет.

На Фіг.2 представлена структурна схема архітектури типу концентратора і спиць (зіркоподібної топології), відповідно до варіанту здійснення даного винаходу. В основному, система може містити локальну базу даних 200 (яка може знаходитися у центральному ОІ-ТР. концентраторі 140) ії одну або більшу кількість віддалених баз даних 210 (які можуть знаходитися у пристроях І ШЕ 100), з'єднаних з локальною базою даних 200 за допомогою будь-якого механізму з'єднання, наприклад, Інтернету або ЛМ 122. Бази даних можуть передавати і одержувати дані оновлення.

Відповідно до Фіг.3, у варіантах здійснення даного винаходу локальна база даних 200 передає у віддалену сч базу даних 210 Р файлів 300-1...300-Е відправки та файл ініціалізації 310 відправки для оновлення віддаленої бази даних 210. Файли оновлення можуть передаватися індивідуально або у пакетах, наприклад, декілька (8) файлів 300 відправки, один файл 300 відправки і один файл ініціалізації 310 відправки, множина файлів 300 відправки і один файл ініціалізації 310 відправки, одиночний файл 300 відправки, або одиночний файл ініціалізації 310 відправки. с зо У варіанті здійснення даного винаходу процесор 104 може одержувати з локальної бази даних 200 файл 300 відправки і/або файл ініціалізації 310 відправки, що містить дані оновлення. Система 150 може одержувати файл -

З00 відправки та файл ініціалізації 310 відправки у віддаленій базі даних 210 через інтерфейс 118 зв'язку. Ге!

Потім процесор 104 може порівняти дані оновлення у файлі З00 відправки або в файлі ініціалізації 310 відправки з відповідними даними у віддаленій базі даних 210. Якщо у віддаленій базі даних 210 дані інші, то (22) зв процесор 104 може застосувати файл 300 відправки або файл ініціалізації 310 відправки до віддаленої бази ї- даних 210. Відповідно, згодом віддалена база даних 210 може бути оновлена даними, що відповідають даним оновлення у локальній базі даних 200.

Фіг.А4 ілюструє файл 300 відправки, відповідно до варіанту здійснення даного винаходу. Поля файлу 300 можуть включати в себе, наприклад, ідентифікатор 400 файлу, час 402 формування файлу, кількість 404 « 70 транзакцій М у файлі, повний розмір 406 файлу, контрольну суму 408 або будь-який подібний індикатор контролю З) с помилок і транзакції 410-1...410-М (що містять ідентифікатори транзакцій). Вказані поля файлу відправки є можливими варіантами, призначеними для ілюстрації, але не для обмеження контексту варіантів здійснення ;» даного винаходу. У файл 300 відправки може бути включене будь-яке поле, яке може бути корисним.

Файл 300 відправки містить зміни у локальній базі даних 200 між двома моментами часу. Ці зміни можуть

Включати в себе, наприклад, додавання нових ідентифікаторів (тобто, ідентифікаторів записів даних), видалення -І існуючих ідентифікаторів, зміни одного або більшої кількості записів даних, що відповідають ідентифікатору, перейменування ідентифікатора, холосту команду і т.д. Одна або більша кількість вказаних змін може ік проводитися послідовно і може називатися транзакціями. Файл 300 відправки може містити унікальні

Ге) ідентифікатори цих транзакцій. Транзакції можуть бути записані у файлі З00 відправки у тому порядку, в якому 5р Вони здійснені у локальній базі даних 200. Додатково, для транзакцій, що містять більше однієї зміни, зміни ве можуть бути записані всередині транзакції у тому порядку, в якому вони здійснені у локальній базі даних 200. 4) В основному, ідентифікатори транзакцій можуть призначатися транзакціям у випадковому порядку. Тобто, ідентифікатори транзакцій не обов'язково монотонно зростають у часі. Наприклад, дві послідовні транзакції можуть мати ідентифікатори транзакцій 10004 і наступний за ним 10002. Відповідно, черговість здійснення ов транзакції може бути визначена її розміщенням у поточному файлі 300-Е або її розміщенням у попередньому файлі 300-(Е-1). В основному, для повного завершення оновлення віддаленої бази даних із застосуванням

Ф) одного файлу відправки, транзакції не можуть охоплювати сусідні файли 300. Це запобігає перериванню ка оновлення через мережну затримку, яка може привести до помилкових даних у віддаленій базі даних 210.

Фіг.5 зображає файл ініціалізації 310 відправки, відповідно до варіанту здійснення даного винаходу. Поля во файлу ініціалізації 310 відправки можуть включати в себе, наприклад, ідентифікатор 500 файлу, час 502 формування файлу, кількість 504 транзакцій М у файлі, повний розмір 506 файлу, контрольну суму 508 або будь-який подібний індикатор контролю помилок і копію 516 (даних) повної локальної бази даних. Файл ініціалізації 310 відправки може додатково містити поле 510, що є ідентифікатором 400 файлу останнього файлу

З00 відправки, сформованого до формування файлу 310, і поле 512, що є ідентифікатором останньої транзакції, 65 фіксованої у локальній базі даних 200 до формування файлу ініціалізації 310 відправки. Дані у локальній та віддаленій базах даних 200, 210 можуть бути розподілені по таблицях, що резидентно зберігаються у базах даних 200, 210. Бази даних 200, 210 можуть підтримувати довільну кількість таблиць. Отже, коли база даних має таблиці, файл ініціалізації 310 відправки може містити для кожної таблиці поле, яке вказує кількість записів, зроблених у таблиці. Наприклад, база даних імен доменів може містити таблицю доменів і таблицю серверів доменних імен. Отже, файл ініціалізації відправки може містити поле, яке вказує кількість записів у таблиці доменів і поле, яке вказує кількість записів у таблиці серверів доменних імен. Поле може визначати, наприклад, ім'я таблиці, ключ, що використовується для індексування записів у таблиці, і кількість записів у таблиці. Додатково, файл ініціалізації 310 відправки може містити поле, яке вказує версію файлу ініціалізації 310 відправки, звичайно 1.0. Вказані поля файлу ініціалізації відправки є можливими варіантами, призначеними 7/0 для ілюстрації, але не обмеження, контексту варіантів здійснення даного винаходу. В файл ініціалізації 310 відправки може бути включене будь-яке поле, яке може бути корисним.

Як зазначено вище, файл ініціалізації 310 відправки може містити, наприклад, копію повної локальної бази даних 200, уніфіковану за зчитуванням даних. Файл ініціалізації 310 відправки може стати уніфікованим з локальною базою даних 200 у момент часу ї між ів і Є, де їз є часом початку формування файлу ініціалізації 7/5 310 відправки, а Є є часом завершення формування. По суті, єдиною операцією, яка може з'явитися в файлі ініціалізації 310 відправки, є операція "додавання". Тобто, при формуванні файлу ініціалізації 310 відправки в нього можуть бути записані копії повної локальної бази даних 200 у момент часу Її. Отже, для запису локальної бази даних 200 в файл ініціалізації 310 відправки може бути виконана операція "додавання".

Ідентифікатори можуть бути записані в файл ініціалізації 310 відправки у випадковому порядку. В іншому варіанті, за наявності зовнішніх ідентифікаторів, записи даних, на які є посилання, можуть бути записані до запису даних, що має посилання.

Додавання полів 510 і 512 може забезпечувати файл ініціалізації 310 відправки деякою інформацією про файли 300 відправки, які можуть бути сформовані і передані у віддалену базу даних 210 під час формування файлу ініціалізації 310 відправки. Однак, формування файлу 300 відправки і формування файлу ініціалізації 310 сч Відправки можуть бути не пов'язані один з одним відносно відсутності залежності між ними при формуванні. Така структура і процес можуть запобігти менш ефективному підходу, при якому формування і застосування файлу і) відправки може бути припинене до завершення формування файлу ініціалізації відправки. При продовженні формування і застосування файлів 300 відправки під час формування файлу ініціалізації 310 відправки, як у варіанті здійснення даного винаходу, може здійснюватися суворий контроль помилок файлів З00 відправки, а с зо також накладення обмежень на віддалену базу даних 210, наприклад, можуть бути зроблені обмеження відносно однозначності або обмеження на зовнішні ідентифікатори. Накладення обмежень може захищати цілісність - даних у віддаленій базі даних 210 за допомогою відхилення транзакцій, що порушують реляційні моделі Ге! віддаленої бази даних 210. Наприклад, обмеження відносно однозначності може перешкоджати повторному збереженню у базі даних 210 одного і того ж ключа. (22)

На Фіг.б6 представлена часова діаграма, що ілюструє формування файлу відправки та файлу ініціалізації ї- відправки, відповідно до варіанту здійснення даного винаходу. Відповідно до Фіг.б, файли 300 відправки (з 8-1 по 8і-21) формуються з регулярними інтервалами часу. В альтернативному варіанті здійснення файли 300 відправки можуть формуватися з нерегулярними інтервалами часу. У загальному випадку, формування файлу відправки не займає інтервал часу повністю. Наприклад, якщо файли формуються у 5-хвилинні інтервали часу, « то для завершення формування файлу не потрібно повністю 5 хвилин. Додатково, якщо у локальній базі даних з с 200 проводяться зміни під час формування файлу 300 відправки, то ці зміни будуть зібрані у наступному файлі

З00 відправки. Наприклад, якщо формування файлу відправки 5/-4 починається о 12:05:00 і завершується о з 12:05:02, то будь-які зміни у локальній базі даних 200, здійснені між 12:05:00 і 12:05:02, збираються у файл відправки 51-5 (наприклад, 300-5), який охоплює інтервал часу з 12:05:00 до 12:10:00.

Фігб ілюструє файли 300-5 і 300-19 відправки. У вказаних файлах, серед інших полів, зображені -І ідентифікатор 601 файлу (51-5, 8і-19), час 603 формування файлу, та ідентифікатори 605 транзакцій (наприклад, 10002). Слід зазначити, що ідентифікатори транзакцій можуть бути не впорядкованими монотонно. Як згадано ік вище, ідентифікатори транзакцій можуть мати довільні значення. Однак, безпосередньо відповідні транзакції

Ге) записані у файл З00 відправки у порядку, в якому вони здійснені у локальній базі даних 200.

Оскільки формування файлу ініціалізації 310 відправки і формування файлу 300 відправки можуть бути не ве пов'язані, то файл ініціалізації 310 відправки може формуватися у будь-який момент часу. Наприклад, файл 4) ініціалізації 310 відправки може формуватися до, протягом або після формування файлу 300 відправки. Фіг.б ілюструє файл ініціалізації 310 відправки, що формується у проміжок часу між формуванням четвертого і п'ятого файлів відправки (наприклад, 1-4 і 8-5).

У варіанті здійснення файл ініціалізації 310 відправки може, серед інших полів, містити ідентифікатор 610 файлу (іві-1), ідентифікатор 615 файлу для останнього файлу відправки, сформованого перед формуванням

Ф) файлу ініціалізації відправки, та ідентифікатор 620 транзакції для останньої транзакції, завершеної перед ка формуванням файлу ініціалізації відправки. У даному можливому варіанті останнім сформованим файлом відправки є файл відправки 5/-4, а останньою завершеною транзакцією є транзакція 10001. Формування файлу бо ініціалізації 310 відправки починається 611 о 12:07:29. Коли починається формування файлу ініціалізації 310 відправки, перша половина транзакцій у файлі 300-5 відправки (1-5), транзакції 10002, 10005 і 10001 були вже завершені у локальній базі даних 200. Відповідно, файл ініціалізації 310 відправки може мати інформацію про дані транзакції і може зібрати дані транзакції в файлі ініціалізації 310 відправки. Однак, файл ініціалізації 310 відправки не може мати інформації про подальші транзакції 10003 і 10004, які здійснюються після початку 65 формування файлу ініціалізації відправки.

При формуванні файлу ініціалізації 310 відправки файли відправки, починаючи з файлу 300-5 відправки,

можуть продовжувати формуватися з регулярними інтервалами часу. Дані файли можуть передаватися віддаленій базі даних 210 і застосовуватися.

Формування файлу ініціалізації 310 відправки може бути завершене о 1:15:29, у проміжку часу між формуванням 18-го і 19-го файлів З00 відправки (51-18 і 81-19), ії не може впливати на формування 19-го файлу 300-19 відправки.

Після одержання і завантаження у віддаленій базі даних 210 файлу ініціалізації 310 відправки віддалена база даних 210 може не враховувати файли відправки, сформовані до формування файлу ініціалізації 310 відправки. Це можливо, наприклад, внаслідок того, що файл ініціалізації 310 відправки містить всі зміни у 70 локальній базі даних 200, які були записані у попередні файли 300 відправки. У цьому можливому варіанті віддаленій базі даних 210 може не бути потрібним враховувати файли відправки з першого по четвертий (з 51-1 по 8/-4). Зміни, записані у даних файлах відправки, з 851-1 по 81-4, також можуть бути записані в файлі ініціалізації 310 відправки. Вказані попередні файли відправки (з 51-1 по 51-4) можуть бути видалені або, в іншому варіанті, заархівовані.

Аналогічно, віддалена база даних 210 може не враховувати транзакції, завершені до формування файлу ініціалізації 310 відправки, які були включені у файл 300 відправки, сформований згодом. Дані транзакції можуть бути включені в файл ініціалізації 310 відправки при його формуванні. Наприклад, тому віддаленій базі даних 210 може не бути потрібним враховувати перші три транзакції 10002, 10005, 10001 з файлу відправки в51-5.

Дані транзакції, записані у файл відправки 5-5, можуть також бути записані в файлі ініціалізації 310 Відправки. Дані завершені транзакції можуть бути видалені, або в іншому варіанті, заархівовані.

На Фіг.7 представлена блок-схема варіанту здійснення даного винаходу, в якому можуть бути сформовані файли оновлення локальної бази даних. Система може формувати (705) декілька періодичних оновлень, що базуються на додаткових змінах у локальній базі даних. Кожне оновлення може містити одну або більшу кількість транзакцій. Потім система може передати (710) періодичні оновлення у віддалену базу даних. При формуванні сч ов періодичних оновлень, система може почати формувати (715) оновлення ініціалізації у момент часу запуску.

Оновлення ініціалізації може містити версію повної локальної бази даних. Система може визначити (720) останнє і) періодичне оновлення, сформоване до моменту часу запуску, і останню транзакцію, завершену до моменту часу запуску. Потім система може передати (725) оновлення ініціалізації у віддалену базу даних. Оновлення ініціалізації може містити ідентифікатор оновлення, що відповідає останньому сформованому періодичному с зо оновленню, та ідентифікатор транзакції, що відповідає останній завершеній транзакції.

Наприклад, ОЇ ТР 140 може формувати (705) файли 300 відправки з деяким регулярним або нерегулярним - інтервалом часу. Потім ОЇ ТР 140 може передати (710) файли 300 відправки у віддалену базу даних 210. При Ге! формуванні файлів З00 відправки, ОЇ ТР 140 може почати формування (715) файлу ініціалізації 310 відправки у момент часу 611 запуску. Файл ініціалізації 310 відправки може містити копію повної локальної бази даних 200. ме)

Потім ОЇ ТР 140 може визначити (720) останній файл 300 відправки, сформований до моменту часу 611 запуску ї- для формування файлу ініціалізації 310 відправки, і останню транзакцію, завершену до моменту часу 611 зануску для формування файлу ініціалізації 310 відправки. Потім ОЇ ТР 140 може передати (725) файл ініціалізації 310 відправки у віддалену базу даних 210. Файл ініціалізації 310 відправки може містити ідентифікатор 615 файлу відправки, що відповідає останньому сформованому файлу 300 відправки, та ідентифікатор транзакції 620, що «

Відповідає останній завершеній транзакції. з с На Фіг.8 представлена блок-схема варіанту здійснення даного винаходу, в якому віддалена база даних може одержувати файли оновлень з локальної бази даних. Система може одержати (805) декілька періодичних ;» оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій. Періодичні оновлення можуть бути одержані окремо або у пакетах. У деякий момент часу система може одержати (810) оновлення ініціалізації.

Оновлення ініціалізації може містити версію повної локальної бази даних. Система може зчитати (815) з -І оновлення ініціалізації ідентифікатор останнього періодичного оновлення і ідентифікатор останньої транзакції.

Потім система може визначити (820) останнє періодичне оновлення, яке відповідає ідентифікатору оновлення, і ік останню транзакцію, яка відповідає ідентифікатору транзакції. Періодичне оновлення і транзакція можуть бути,

Ге) відповідно, останнім сформованим оновленням і останньою завершеною транзакцією до формування оновлення бо ініціалізації. Система може застосувати (825) до віддаленої бази даних незавершені транзакції, що залишилися, пи у відповідному періодичному оновленні. Потім система може застосувати (830) до віддаленої бази даних 4) періодичні оновлення, що залишилися, сформовані після останнього періодичного оновлення. Застосування оновлення ініціалізації, переважно, заповнює будь-які раніше втрачені періодичні оновлення.

Наприклад, ШЕ 100 може одержати (805) файли 300 відправки з деяким регулярним або нерегулярним дв інтервалом часу. Файли 300 відправки можуть бути одержані окремо або у пакетах. У деякий момент часу | ОЕ 100 може одержати (810) файл ініціалізації 310 відправки. (ШОЕ 100 може зчитати (815) з файлу ініціалізації

Ф) 310 відправки ідентифікатор 615 файлу відправки та ідентифікатор 620 транзакції. Потім І(ОЕ 100 може ка визначити (820) файл 300 відправки, що відповідає ідентифікатору 615 файлу відправки, і транзакцію 605, яка відповідає ідентифікатору 620 транзакції. Файл відправки і транзакція можуть бути, відповідно, останнім бо сформованим файлом відправки і останньою завершеною транзакцією до формування файлу ініціалізації 310 відправки. (ОЕ 100 може застосувати (825) до віддаленої бази даних 210 незавершені транзакції 605, що залишилися, у відповідному файлі З00 відправки. Потім | ШЕ 100 може застосувати (830) до віддаленої бази даних 210 файли 300 відправки, що залишилися, які йдуть за останнім файлом відправки 5-4.

В альтернативному варіанті здійснення, наприклад, (ШЕ 100 може відкинути або заархівувати файли 300 65 відправки, які не були застосовані до віддаленої бази даних 210, і/або мають час 603 формування до часу 611 формування файлу ініціалізації відправки. Відкинуті або заархівовані файли 300 відправки можуть включати в себе файл відправки 51-4, що відповідає ідентифікатору 615 файлу відправки.

Зрозуміло, що після застосування файлу ініціалізації 310 відправки будь-які більш пізні файли 300 відправки, які могли бути вже застосовані до віддаленої бази даних 210, можуть не зберегтися, оскільки віддалена база даних 210 може стати уніфікованою за зчитуванням з файлом ініціалізації 310 відправки.

Відповідно, ці більш пізні файли 300 відправки можуть бути застосовані повторно.

У варіанті здійснення даного винаходу, файли 300 відправки та файл ініціалізації 310 відправки можуть передаватися з локальної бази даних 200 у віддалену базу даних 210 без повідомлення про успішне одержання даних, тобто, без сигналу АСК/МАСК для вказування того, що файли були успішно одержані. Це, переважно, 7/0 скорочує додаткову службову сигналізацію, яку може створювати сигнал АСК/МАСК.

В альтернативному варіанті здійснення з віддаленої бази даних 210 може передаватися сигнал АСК/МАСК для вказування того, що файли успішно одержані. У цьому варіанті здійснення сигнал АСК/МАСК може передаватися у системах з ненадійним зв'язком.

На Фіг.9 представлена блок-схема іншого варіанту здійснення даного винаходу, в якому система може перевіряти достовірність файлів оновлення, переданих з локальної бази даних і одержаних у віддаленій базі даних. Тут, система може передати (905) множину періодичних оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій. Періодичні оновлення можуть бути передані окремо або у пакетах. У деякий момент часу система може передати (910) оновлення ініціалізації і застосувати оновлення ініціалізації до віддаленої бази даних. Оновлення ініціалізації може містити версію повної локальної бази даних. Спочатку го система, за допомогою порівняння баз даних, може ідентифікувати (915) розходження між локальною і віддаленою базами даних. Система може визначити (920), чи є розходження дійсними або помилковими. Потім система може застосувати (925) до віддаленої бази даних періодичні оновлення, відповідно до варіанту здійснення даного винаходу. Даний варіант здійснення, переважно, може забезпечувати відсутність помилок у віддаленій базі даних, що є результатом одержання оновлень з локальної бази даних. с

Наприклад, ОЇ ТР 140 може передати (905) у віддалену базу даних 210 файли 300 відправки з деяким регулярним або нерегулярним інтервалом часу. Файли 300 відправки можуть бути передані окремо або у і) пакетах. У деякий момент часу ОЇ ТР 140 може передати (910) файл ініціалізації 310 відправки в ГЕ 100, і ГОє 100 може застосувати файл ініціалізації 310 відправки до віддаленої бази даних 210. ОЇ ТР 140 може порівняти локальну базу даних 200 з віддаленою базою даних 210 та ідентифікувати (915) розходження між ними. Потім с зо ОГТР 140 може визначити (920), чи є розходження дійсними або помилковими. Потім ОЇТР 140 може поінформувати ШЕ 100 для застосування (925) до віддаленої бази даних 210 файлів 300 відправки, відповідно « до варіанту здійснення даного винаходу. Потім (ШОЕ 100 може застосувати файли 300 відправки до віддаленої Ге! бази даних 210.

В альтернативному варіанті здійснення система може застосовувати файли відправки та файл ініціалізації ме) відправки до ідентифікації і перевірки достовірності розходжень. У вигляді іншого варіанту система може ї- застосовувати файли відправки та файл ініціалізації відправки після ідентифікації і перевірки достовірності розходжень.

Зрозуміло, що процес перевірки достовірності може бути виконаний на будь-яких даних, переданих з джерела в адресат через мережу зв'язку для застосування переданих даних до адресата. «

На Фіг.10А представлена блок-схема варіанту здійснення перевірки достовірності файлу відправки та файлу пе) с ініціалізації відправки, відповідно до даного винаходу. Після передачі у віддалену базу даних декількох періодичних оновлень та оновлення ініціалізації система може перевірити достовірність даних оновлень. Кожне ;» оновлення може містити одну або більшу кількість транзакцій, виконаних у локальній базі даних. Кожна транзакція може містити одну або більшу кількість подій. Подія є дією або можливим здійсненням у базі даних, наприклад, додавання, зміни, видалення і т.д., відносно даних у базі даних. -І Спочатку система може порівняти (1000) запис у віддаленій базі даних з відповідним записом у локальній базі даних. Система може сформувати (1005) виключення, що описує розходження між записами віддаленої і і, локальної баз даних, причому виключення може бути сформоване для кожного розходження. Розходженням

Ге) може бути будь-яка відмінність, щонайменше, в одному значенні даних між двома версіями одного запису.

Наприклад, у локальній базі даних може бути запис даних (12345, хуг.сот, 123.234.345). Відповідний запис пи даних у віддаленій базі даних, яка передбачається ідентичною, може відповідати (12345, арс.сот, 123.234.345). 4) Відповідно, у другому значенні даних запису є розходження. Отже, варіант здійснення даного винаходу може сформувати виключення, яке описує вказане розходження. Виключення може описувати розходження, просто вказуючи на те, що є розходження; визначаючи місцеположення розходження; описуючи відмінність між двома ов Значеннями даних при розходженні і т.д. Запис даних у локальній базі даних відповідає запису даних у віддаленій базі даних (і навпаки), якщо два записи обов'язково містять ідентичні дані. (Ф) Зрозуміло, що розходження може відноситися до відмінності в одному або більшій кількості значень даних й ка записі або до запису загалом.

Система може зіставити (1010) кожному виключенню ідентифікатор виключення, причому ідентифікатор бо Виключення може відповідати ідентифікатору запису. Наприклад, запис даних (12345, хул.сот, 123.234.345) може мати ідентифікатор 410. Відповідно, ідентифікатором виключення може бути також 410. Кожне виключення може бути класифіковане як таке, що належить будь-якому з декількох видів виключень (або розходжень). Може бути сформований список виключень для включення в нього видів виключень та ідентифікатора виключення для згрупованих там виключень. Список виключень і різні види виключень детально описані нижче. Система також б5 Може зіставити (1015) кожній події в оновленні ідентифікатор події, причому ідентифікатор події може відповідати ідентифікатору запису. Наприклад, запис даних (12345, хул.сот, 123.234.345) може мати ідентифікатор 410. Відповідно, ідентифікатором події може бути також а10. Кожна подія в оновленні може бути знайдена з передісторії подій. Передісторією подій може бути лістинг і т.д. подій, виконані на записах локальної бази даних за деякий період часу. Передісторія подій детально описана нижче.

Потім система може визначити (1020), чи є оновлення запису достовірним. На Фіг.10В8 представлена блок-схема варіанту здійснення визначення перевірки достовірності. Дане визначення може бути зроблене наступним чином. Може бути здійснене порівняння (1022) кожної події з кожним виключенням. Якщо кожне виключення підтверджене (1024) подією, то оновлення може бути визначене (1026), як достовірне, і дане оновлення може бути застосоване до віддаленої бази даних. Інакше, якщо кожне виключення не підтверджене 7/0. Й1024) подією, то оновлення може бути визначене (1028), як недостовірне, і виключення можуть реєструватися як помилки. Виключення може бути підтвердженим, коли ідентифікатору виключення відповідає ідентифікатор події, і відповідна подія відповідає достовірній послідовності подій, що відповідають виду виключення. Достовірні послідовності детально описані нижче. Якщо виключення підтверджене, то система може видалити ідентифікатор виключення зі списку виключень. Підтверджене виключення може вказувати, що розходження є 7/5 достовірним, наприклад, віддалена база даних ще не одержала оновлення, але при одержанні оновлення дійсно буде відповідати локальній базі даних.

При перевірці достовірності система може ідентифікувати приховані помилки або збої у періодичному оновленні та оновленнях ініціалізації. Система може забезпечувати можливість структурної і семантичної коректності даних оновлення, можливість успішного застосування даних оновлення, яке не викликає формування виключень або іншої небажаної зупинки, можливість точного виявлення помилок при порівнянні локальної і віддаленої баз даних між собою, і неможливість випадкового видалення значимих даних. Система може забезпечувати можливість успішного застосування до віддаленої бази даних періодичного оновлення та оновлень ініціалізації.

Переважно, при перевірці достовірності може бути виявлено багато помилок, що виникають при спробі сч г Застосування оновлення до віддаленої бази даних. Наприклад, при спробі застосування можуть виявлятися помилки централізації даних, попередження про те, що об'єкт вже існує у віддаленій базі даних, або (8) попередження про те, що є порушення зовнішнього ідентифікатора. Отже, після виконання процесу перевірки достовірності відповідно до варіанту здійснення даного винаходу, система може зробити спробу застосування вказаних оновлень до віддаленої бази даних. Спроба може бути неуспішною, що може вказувати на наявністьв (У зо оновленнях додаткових помилок, які роблять оновлення недостовірним. Відповідно, додаткові спроби застосування вказаних оновлень до віддаленої бази даних не можуть бути здійснені. -

В альтернативному варіанті здійснення до виконання перевірки достовірності може бути зроблена спроба Ге! застосувати, щонайменше, одне з оновлень. Якщо спроба є неуспішною, то перевірка достовірності може бути пропущена і оновлення відкинуто. З іншого боку, якщо спроба є успішною, то може бути виконана перевірка Ме з5 достовірності, і достовірне оновлення зберігається, а для недостовірного оновлення реєструються розходження. ча

У можливому варіанті здійснення ОЇ ТР 140 може здійснювати перевірку достовірності файлів З00 відправки та файлів ініціалізації 310 відправки для забезпечення успішного застосування до віддаленої бази даних 210 файлів 300 відправки та файлів ініціалізації 310 відправки.

В альтернативних варіантах здійснення перевірку достовірності можуть виконувати мережні комп'ютери 121, «

МЕ 100 або будь-яка комбінація існуючих систем. в с Відповідно до Фіг.10А, ОЇ ТР 140 може порівняти локальну базу даних 200 і віддалену базу даних 210 для визначення будь-яких виключень (або розходжень) між ними. Виключення можуть включати три види: у з віддаленій базі даних 210 можуть існувати дані, які відсутні у локальній базі даних 200; у локальній базі даних 200 можуть існувати дані, які відсутні у віддаленій базі даних 210; або відповідні дані можуть існувати і у локальній базі даних 200, і у віддаленій базі даних 210, але дані "можуть відрізнятися. Безумовно, -І відповідні дані можуть існувати і у локальній базі даних 200, і у віддаленій базі даних 210, і дані можуть бути ідентичними, у цьому випадку дані можуть вважатися достовірними, отже, від ОЇ ТР 140 не потрібно ніякої се) додаткової обробки.

Ге) Зрозуміло, що розходження може відноситися до одного або більшої кількості значень даних у записі або до

Запису загалом. пи Відповідно, ОЇ ТР 140 може порівняти (1000) відповідні записи у локальній базі даних 200 і віддаленій базі 4) даних 210. ОЇ ТР 140 може сформувати (1005) виключення, яке описує розходження між записом у віддаленій базі даних 210 і записом у локальній базі даних 200, причому виключення може бути сформоване для кожного розходження. ОЇ ТР 140 може зіставити (1010) кожному виключенню ідентифікатор виключення, причому в ідентифікатор виключення може відповідати ідентифікатору запису. Може бути сформований список виключень для включення видів виключень та ідентифікатора виключення для виключення, що належить до даного виду

Ф) виключення. У варіанті здійснення виключення може бути визначене, як виключення (або розходження) "Списку ка 1", якщо виключення належить до першого виду виключень, виключення "Списку 2", якщо виключення належить до другого виду виключень, або виключення "Списку 3", якщо виключення належить до третього виду виключень. бо Фіг11 ілюструє можливий список 1140 виключень.

Зрозуміло, що наявність ідентифікатора виключення у списку виключень не означає, що файл 300 відправки або файл ініціалізації 310 відправки не придатний, оскільки, наприклад, всі три види виключень можуть виникати обгрунтовано через затримку у часі між змінами у локальній базі даних 200 і оновленнями, що застосовуються до віддаленої бази даних 310. Така затримка, наприклад, може бути викликана 65 перевантаженням мережі зв'язку. По суті, перевірка достовірності може забезпечувати механізм" для виключення обгрунтованих виключень з помилкових даних.

Для файлу ініціалізації 310 відправки, ОЇ ТР 140 може порівняти локальну базу даних 200 і віддалену базу даних 210 за допомогою виконання двонаправленого перегляду всіх таблиць в обох базах даних 200, 210.

Тобто, всі дані у локальній базі даних 200 можуть порівнюватися відносно всіх даних у віддаленій базі даних 210. Потім всі дані у віддаленій базі даних 210 можуть порівнюватися відносно всіх даних у локальній базі даних 200. Це, переважно, забезпечує всебічне порівняння баз даних 200, 210 для виявлення всіх розходжень.

Для файлу 300 відправки ОЇ ТР 140 може порівняти тільки ті записи даних у локальній базі даних 200 і віддаленій базі даних 210, які записані у файлі З00 відправки. Це, переважно, забезпечує швидкодіючий запит для виявлення заданих розходжень. 70 В іншому варіанті може бути зроблена випадкова вибірка даних в файлі ініціалізації 310 відправки і/або файлі 300 відправки. Потім ОЇ ТР 140 може порівняти дані, вибрані випадковим чином, у локальній базі даних 200 і віддаленій базі даних 210.

Список 1140 виключень може відповідати відсутнім подіям, наприклад, додавання (ада), зміни (тод) і видалення (аеї) для локальної бази даних 200, які не узгоджуються з віддаленою базою даних 210. Отже, для ідентифікації таких подій-кандидатів, ОЇ ТР 140 може дослідити останні транзакції, фіксовані у локальній базі даних 200. В основному, у таблиці реєстрації, яка зберігається у локальній базі даних 200, може бути сформований елемент для кожної фіксованої транзакції. Елемент може містити ідентифікатор запису, який був змінений, транзакцію (або подію), що змінила запис (наприклад, ада, тод і/або деї), порядковий номер реєстрації, який вказує черговість транзакції і т.д.

Можлива таблиця 1100 реєстрації зображена на Фіг.11. У цьому можливому варіанті файл 300 відправки містить транзакції 1108-1114, зображені у таблиці реєстрації 1100. Перший елемент 1101 вказує, що у першій транзакції 1108 дані (сервера доменних імен) п! і п2 були додані до даних (домен), що відповідають ідентифікатору 41. Отже, ідентифікатором є аї, подією є додавання "ада", а порядковим номером реєстрації є 11526. Аналогічно, другий елемент 1102 вказує, що у другій транзакції 1109 дані п8 і пО були додані до даних, сч ов що відповідають ідентифікатору а2. Третій елемент ПОЗ вказує, що у третій транзакції 1110 дані, що відповідають ідентифікатору 43, були видалені. Четвертий елемент 1104 вказує, що у четвертій транзакції 1111, і) дані, що відповідають ідентифікатору 41, були змінені для додавання даних по. Для п'ятої транзакції 1112 п'ятий елемент 1105 вказує, що дані пб і п7 були додані до даних, які відповідають ідентифікатору а3. Для шостої транзакції 1113 шостий елемент 1106 вказує, що дані, які відповідають ідентифікатору 44, були змінені с для видалення даних пЗ3. К Ий елемент 1107 в Вй транзакції 1114 вказує, що дані, які відповідають ідентифікатору д5, були видалені. М

Відповідно, згідно з Фігт!ОА, ОЇ ТР 140 може зіставити (1015) кожній події в оновленні ідентифікатор. Ф) події, причому ідентифікатор події може відповідати ідентифікатору запису. Кожна подія в оновленні може бути знайдена з передісторії подій. Передісторія подій, індексована і впорядкована за ідентифікатором події, може іа бути сформована з таблиці 1100 реєстрації. Можлива передісторія 1120 подій зображена на Фіг.11. Тут, першийі р четвертий елементи 1101, 1104 у таблиці 1100 реєстрації вказують зміни для даних, що відповідають ідентифікатору а1. Отже, передісторія 1120 подій містить ідентифікатор 491 1121 і дві події 1126, додавання "ада" ії подальшу зміну "той", виконані на даних, що відповідають ідентифікатору 41. Другий елемент 1102 « вказує зміни для даних, що відповідають ідентифікатору а2. Отже, передісторія 1120 подій містить 70 ідентифікатор 42 1122 і подію 1127 додавання "ада". Передісторія 1120 подій містить ідентифікатор аЗ 1123 і 8 с дві події 1128, видалення "де" з подальшою зміною "той", що вказується третім і п'ятим елементами 1103, ц 1105, які містять зміни для даних, що відповідають ідентифікатору 43. Шостий елемент 1106 вказує зміни для и"? даних, що відповідають ідентифікатору 44. Відповідно, передісторія 1120 подій містить ідентифікатор 44 1124 і подію 1129 зміни "той". БИЙ елемент 1107 вказує зміни для даних, що відповідають ідентифікатору 5, і передісторія 1120 подій містить ідентифікатор 45 1125 і подію 1130 видалення "ае!". Ідентифікатори 1121-1125 -| впорядковані з а1 по 45. со Відповідно до Фіг.10А, ОЇ ТР 140 може визначити (1020), чи є оновлення достовірним. Це визначення може бути виконане, наприклад, відповідно до варіанту здійснення за Фіг.10В. Спочатку ОЇ ТР 140 може порівняти (Се) (1022) ідентифікатори 1121-1125 подій з ідентифікаторами 1140 виключень для визначення, які ідентифікатори 1» 50 мають відповідність. Наприклад, відповідно до Фіг.11, ідентифікатор 1121 події а1 у хронології 1120 подій відповідає ідентифікатору виключення 41 у "Списку 2" списку 1140 виключень. Після виявлення відповідних події (45) і виключення, ОЇ ТР 140 може визначити (1024), чи підтверджене виключення подією. Підтвердження може бути виконане наступним чином. Для кожного ідентифікатора 1121-1125 події у хронології 1120 подій, ОЇ ТР 140 може визначити, чи є достовірною кожна послідовність подій 1126-1130 у хронології 1120 подій. Це може бути здійснено, наприклад, шляхом дослідження списку 1140 виключень для того, щоб визначити, до якого виду виключень належить кожний ідентифікатор виключення, визначення, якою повинна бути достовірна

ІФ) послідовність подій для цього виду виключень, і потім пошуку у передісторії 1120 подій відповідного іме) ідентифікатора події та послідовності подій для ідентифікатора події. Достовірні послідовності для кожного виду виключень детально описані нижче. Якщо послідовність подій 1126-1130 у хронології 1120 подій відповідає 60 достовірній послідовності, то відповідний ідентифікатор події 1121-1125 має достовірну послідовність. По суті, виключення, що відповідає ідентифікатору виключення, може бути підтверджене. І, відповідна транзакція 1108-1114, що містить вказаний ідентифікатор події, є обгрунтованою, а не помилковою. У даному випадку, ОЇ ТР 140 може видалити ідентифікатор виключення зі списку 1140 виключень.

Для виду виключень "Списку 1" достовірною послідовністю подій може бути (това) " (аеї). Дана послідовність 65 може містити послідовність з нульової або більшої кількості подій зміни "той", за якими йде подія видалення "де", за якою йде довільна подія. Вид виключень "Списку 1" може відповідати даним, які можуть існувати у віддаленій базі даних 210, але бути відсутніми у локальній базі даних 200. У цьому випадку дані, можливо, були нещодавно видалені з локальної бази даних 200 і транзакція ще не була записана у файл 300 відправки.

Отже, файл 300 відправки ще не міг бути застосований до віддаленої бази даних 210. Таким чином, ці дані

Можуть ще залишатися у віддаленій базі даних 210. Це може вважатися обгрунтованим розходженням, оскільки передбачається, що у деякий момент часу файл 300 відправки буде сформований і застосований до віддаленої бази даних 210. Отже, якщо для ідентифікатора виключення у Списку 1 зі списку 1140 виключень у хронології 1120 подій виявлена будь-яка така послідовність 1126-1130, то відповідна транзакція може вважатися достовірною. 70 Наприклад, відповідно до Фіг.11, ідентифікатор а5 1125 і відповідні йому дані були видалені з локальної бази даних 200, як ілюструє В й елемент 1114 таблиці 1100 реєстрації і вказує хронологія 1120 подій. Під час перевірки достовірності 45 був видалений з локальної бази даних 200, але не видалений з віддаленої бази даних 210. Отже, список 1140 виключень містить ідентифікатор а5 у Списку 1. Відповідно до хронології 1120 подій, подією 1130, що відповідає ідентифікатору 45 1125, є видалення "де!". ОЇ ТР 140 може порівняти достовірну 75 послідовність виду виключень "Списку 1", тобто (тод) " (дае), з подією 45 1130 у хронології 1120 подій.

Оскільки достовірна послідовність "Списку 1" і подія 1130 відповідають, то транзакція 1114 видалення, що відповідає ідентифікатору 45, може вважатися обгрунтованою і не є помилкою. Відповідно, ідентифікатор а5 може бути видалений зі списку 1140 виключень.

Достовірною послідовністю подій для виду виключень "Списку 2" може бути (ад4а). Дана послідовність може містити подію додавання "ада", за якою йде довільна подія. Вид виключень "Списку 2" може відповідати даним, які існують у локальній базі даних 200, але не існують у віддаленій базі даних 210. У цьому випадку дані могли бути нещодавно додані у локальну базу даних 200, і транзакція ще не була записана у файл З00 відправки. Отже, файл 300 відправки міг бути ще не застосований до віддаленої бази даних 210. Отже, дані можуть не існувати у віддаленій базі даних 210. Це також може вважатися обгрунтованим розходженням, Га оскільки, очікується, що у деякий момент часу файл 300 відправки буде сформований і застосований до віддаленої бази даних 210. Відповідно, якщо для ідентифікатора виключення у Списку 2 зі списку 1140 о виключень виявлена будь-яка така послідовність 1126-1130 у хронології 1120 подій, то відповідна транзакція може вважатися достовірною.

Відповідно до Фіг.11, ідентифікатори 41 ї а2 1121, 1123 можуть бути зіставлені з даними, які, наприклад, со спочатку були додані у локальну базу даних 200. Оскільки послідовності подій 1126, 1127 для них починаються з події додавання "ада", то ідентифікатори а1 і 42 1121, 1123 відповідають достовірним послідовностям для виду в виключень "Списку 2". Відповідно, транзакції 1108, 1109, що містять вказані ідентифікатори, можуть вважатися Ге»! достовірними, і ідентифікатори 41 і 42 можуть бути видалені зі списку 1140 виключень. Слід зазначити, що ідентифікатор 43 1123 також у своїй послідовності 1128 містить подію додавання "ада". Однак, подія додавання іа 3з5 ада" не є першою у послідовності 1128. Відповідно, послідовність 1128 не відноситься до виду "Списку 2". -

Додатково, оскільки 43 не позначений у Списку 2 списку 1140 виключень, то ОЇ ТР 140 не може здійснити його перевірку по достовірній послідовності для Списку 2.

Достовірними послідовностями подій для виду виключень "Списку З" можуть бути (аеї), (ада) або (тод). Дані « послідовності можуть містити подію видалення "де!", за якою йде подія додавання "ада", за якою йде довільна 70 подія, або подія зміни "тоа", за якою йде довільна подія. Вид виключень "Списку 3" може відповідати даним, 8 с які існують в обох базах даних 200, 210, але відмінні. У цьому випадку дані могли бути нещодавно змінені у ц локальній базі даних 200, і транзакція ще не була записана у файл 300 відправки. Отже, файл 300 відправки ще и"? не міг бути застосований до віддаленої бази даних 210. Отже, дані, що відповідають ідентифікатору, можуть бути ще не змінені у віддаленій базі даних 210. Знову, це може вважатися обгрунтованим розходженням, оскільки очікується, що у деякий момент часу файл 300 відправки буде сформований і застосований до -І віддаленої бази даних 210. Відповідно, якщо для ідентифікатора виключення у "Списку 3" зі списку 1140 виключень виявлена будь-яка така послідовність 1126-1130 у хронології 1120 подій, то відповідна транзакція о може вважатися достовірною. (Се) Наприклад, відповідно до Фіг.11, ідентифікатори 43 ії 44 1123, 1124 можуть бути зіставлені з даними, які були змінені у локальній базі даних 200. У випадку ідентифікатора аз 1123, ідентифікатор аз 1123 і його дані ть спочатку були видалені, а потім додані зворотно з новими даними, так що послідовність подій 1128 може містити с» видалення "деї", за яким йде додавання "ада". У випадку ідентифікатора а4 1124, дані 44 були змінені для видалення даних, так що послідовність подій 1129 може містити зміну "той". Оскільки вказані послідовності подій 1128, 1129 відповідають достовірним послідовностям для виду виключень "Списку 3", то відповідні їм транзакції 1110, 1112, 1113 можуть вважатися достовірними, і ідентифікатори 43 і а4 можуть бути видалені зі списку 1140 виключень. іФ) Відповідно до Фіг.10В, якщо всі виключення, позначені у списку 1140 виключень своїми ідентифікаторами, ко були обгрунтовані (1024) подіями, наприклад, якщо список 1140 виключень є пустим, то ОЇ ТР 140 може визначити (1026) файл 300 відправки або файл ініціалізації 310 відправки, як достовірний, і поінформувати ШОЕ бо 100 для застосування файлу 300 відправки або файлу ініціалізації 310 відправки до віддаленої бази даних 210.

Потім ГОЕ 100 може застосувати файл 300 відправки або файл ініціалізації 310 відправки до віддаленої бази даних 210.

Ї навпаки, якщо всі виключення не були підтверджені (1024) подіями, наприклад, якщо список 1140 виключень не є пустим, то виключення, що залишилися, можуть вказувати на помилки у файлі З00 відправки або файлі 65 ініціалізації 310 відправки. Відповідно, ОЇ ТР 140 може визначити (1028) файл З00 відправки або файл ініціалізації 310 відправки, як недостовірний, і зареєструвати помилки у файлі помилок.

В альтернативному варіанті здійснення, якщо, наприклад, файл 300 відправки або файл ініціалізації 310 відправки був визначений як недостовірний, то після заздалегідь визначеного періоду часу ОЇ ТР 140 може повторити процес перевірки достовірності відносно недостовірного файлу З00 відправки або файлу ініціалізації 310 відправки для підтвердження того, що розходження дійсно є помилками. Вказана заздалегідь визначена затримка забезпечує мережі більший час для передачі якого-небудь повільного файлу 300, 310 відправки, і більший час на те, щоб бази даних 200,210 стали уніфікованими за зчитуванням.

У варіанті здійснення даного винаходу дані у віддаленій базі даних 210 можуть "відставати" від даних у локальній базі даних 200 на значний інтервал часу. Відповідно, для порівняння баз даних 200, 210 їі для 7/0 виявлення помилок, бази даних 200, 210 можуть бути зроблені уніфікованими за зчитуванням у той момент часу, коли вони стануть точними копіями одна одної. В основному, віддалена база даних 210 може бути приведена, з повторенням всіх завершених транзакцій, до локальної бази даних 200, причому дані у віддаленій базі даних 210 можуть бути зроблені по суті ідентичними даним у локальній базі даних 200.

Відповідно, для прискорення перевірки достовірності, будь-який сформований у поточний час файл 7/5 ініціалізації 310 відправки і наступні файли 300 відправки можуть бути застосовані до віддаленої бази даних 210 до початку перевірки достовірності. По суті, кількість розходжень може бути істотно зменшена. Така пакетна обробка файлів 300, 310 відправки може бути визначена як утворення блоків. Перший і останній з цих файлів 300, 310 відправки у блоці може бути названий нижнім і верхнім "водяним знаком", відповідно. Перший блок, що називається початковим блоком, може містити файл ініціалізації 310 відправки. Всі наступні блоки, що 2о називаються кінцевими блоками, можуть містити тільки файли 300 відправки.

Утворення блоків може забезпечувати перевірку достовірності групи замість перевірки достовірності окремо.

Відповідно, при виявленні у блоці помилки, недостовірним може бути позначений весь блок, а не тільки файл

З00 відправки або файл ініціалізації 310 відправки, де виникла помилка.

Механізми і способи, що відповідають варіантам здійснення даного винаходу, можуть бути реалізовані з сч ов використанням універсального мікропроцесора, запрограмованого відповідно до варіантів здійснення. Отже, варіанти здійснення даного винаходу також включають носій інформації, що зчитується комп'ютером, який може і) містити інструкції, які можуть використовуватися для програмування процесора для виконання способу, що відповідає варіантам здійснення даного винаходу. Вказаний носій може включати в себе будь-який вид диска, включаючи гнучкий диск, оптичний диск, компакт-диски СО-КОМ і т.д. с зо Вище детально описано і проілюстровано декілька варіантів здійснення даного винаходу. Однак, має бути очевидним, що без відхилення від суті і об'єму даного винаходу можуть бути здійснені зміни і модифікації « винаходу, які охоплюються наведеним вище описом і доданою формулою винаходу. б

Claims (27)

Формула винаходу 35 і -

1. Спосіб оновлення віддаленої бази даних через мережу, що включає: формування множини періодичних оновлень, що базуються на інкрементних змінах у локальній базі даних, причому кожне з множини періодичних оновлень містить щонайменше одну транзакцію, « передачу множини періодичних оновлень у віддалену базу даних через мережу, ш-в с при цьому при формуванні множини періодичних оновлень виконують: формування ініціалізуючого оновлення, що містить версію локальної бази даних у момент часу запуску, :з» визначення останнього періодичного оновлення з множини періодичних оновлень на основі моменту часу запуску, визначення останньої транзакції на основі моменту часу запуску і -І передачу через мережу у віддалену базу даних ініціалізуючого оновлення, ідентифікатора останнього періодичного оновлення та ідентифікатора останньої транзакції для використання іс), при оновленні відділеної бази даних. со 2.

Спосіб за п. 1, в якому передача ініціалізуючого оновлення включає: зіставлення з останнім періодичним оновленням ідентифікатора останнього періодичного оновлення і - зіставлення з останньою транзакцією ідентифікатора останньої транзакції. с» З.

Спосіб за п. 1, в якому множина періодичних оновлень формується з регулярними або нерегулярними інтервалами часу.

4. Спосіб за п. 1, в якому момент часу запуску формування ініціалізуючого оновлення ідентичний моменту вв часу запуску формування періодичного оновлення.

5. Спосіб за п. 1, в якому момент часу запуску формування ініціалізуючого оновлення більш пізній, ніж (Ф) момент часу запуску формування періодичного оновлення. ГІ

6. Спосіб за п. 1, в якому періодичне оновлення містить множину транзакцій, кожна з яких має унікальний ідентифікатор транзакції. во

7. Спосіб оновлення віддаленої бази даних через мережу, що включає: одержання через мережу множини періодичних оновлень, які базуються на інкрементних змінах у локальній базі даних, причому кожне з множини періодичних оновлень містить щонайменше одну транзакцію, одержання через мережу ініціалізуючого оновлення, що містить версію локальної бази даних у момент часу запуску, 65 зчитування з ініціалізуючого оновлення ідентифікатора останнього періодичного оновлення, зчитування з ініціалізуючого оновлення ідентифікатора останньої транзакції,

визначення останнього періодичного оновлення з ідентифікатора останнього періодичного оновлення, причому згадане визначення останнього періодичного оновлення базується на моменті часу запуску, визначення останньої транзакції з ідентифікатора останньої транзакції, причому згадане визначення останньої транзакції базується на моменті часу запуску, застосування до віддаленої бази даних транзакцій, сформованих після останньої транзакції, і застосування до віддаленої бази даних періодичних оновлень, сформованих після останнього періодичного оновлення.

8. Спосіб за п. 7, що додатково включає: 70 відкидання періодичних оновлень, сформованих до моменту часу запуску ініціалізуючого оновлення.

9. Спосіб за п. 7, в якому множина періодичних оновлень приймається по одному у періодичні інтервали часу.

10. Спосіб за п. 7, в якому множина періодичних оновлень приймається у пакетах у періодичні інтервали часу.

11. Спосіб за п. 7, в якому періодичне оновлення містить множину транзакцій, кожна з яких має унікальний ідентифікатор транзакції.

12. Спосіб оновлення віддаленої бази даних через мережу, що включає: формування множини періодичних оновлень, які базуються на інкрементних змінах у локальній базі даних, кожне з множини періодичних оновлень містить щонайменше одну транзакцію, і формування ініціалізуючого оновлення, що містить версію локальної бази даних у момент часу запуску, ідентифікатор оновлення, що відповідає останньому періодичному оновленню, сформованому до моменту часу запуску, та ідентифікатор транзакції, що відповідає останній транзакції, завершеній до моменту часу запуску, і передачу через мережу у віддалену базу даних ініціалізуючого оновлення , ідентифікатора оновлення та ідентифікатора транзакції.

13. Спосіб за п. 12, в якому множина періодичних оновлень формується з регулярними інтервалами часу.

14. Спосіб за п. 12, в якому множина періодичних оновлень формується з нерегулярними інтервалами часу. сч

15. Спосіб за п. 12, в якому момент часу запуску формування ініціалізуючого оновлення ідентичний моменту часу запуску формування періодичного оновлення. і)

16. Спосіб за п. 12, в якому момент часу запуску формування ініціалізуючого оновлення більш пізній, ніж момент часу запуску формування періодичного оновлення.

17. Система для оновлення віддаленої бази даних через мережу, що містить: с зо щонайменше один процесор, зв'язаний з мережею, і пам'ять, зв'язану з процесором, яка містить локальну базу даних і команди, адаптовані для виконання - процесором способу оновлення віддаленої бази даних через мережу, при цьому зазначені команди включають в (ду себе команди для формування множини періодичних оновлень, які базуються на інкрементних змінах у локальній базі даних, ме) з5 причому кожне з множини періодичних оновлень містить щонайменше одну транзакцію, ї- передачі множини періодичних оновлень у віддалену базу даних через мережу, при цьому команди для формування множини періодичних оновлень включають в себе команди для формування ініціалізуючого оновлення, що містить версію локальної бази даних у момент часу запуску, визначення останнього періодичного оновлення з множини періодичних оновлень на основі моменту часу « Запуску, шщ с визначення останньої транзакції на основі моменту часу запуску і передачі через мережу у віддалену базу даних ініціалізуючого оновлення, ідентифікатора останнього ;» періодичного оновлення та ідентифікатора останньої транзакції.

18. Система за п. 17, в якій при передачі ініціалізуючого оновлення останнє періодичне оновлення зіставлене з ідентифікатором останнього періодичного оновлення, і -І остання транзакція зіставлена з ідентифікатором останньої транзакції.

19. Система за п. 17, в якій множина періодичних оновлень формується з регулярними або нерегулярними і, інтервалами часу. Ге)

20. Система за п. 17, в якій момент часу запуску формування ініціалізуючого оновлення ідентичний моменту 5о часу запуску формування періодичного оновлення. ве

21. Система за п. 17, в якій момент часу запуску формування ініціалізуючого оновлення більш пізній, ніж 4) момент часу запуску формування періодичного оновлення.

22. Система за п. 17, в якій періодичне оновлення містить множину транзакцій, кожна з яких має унікальний ідентифікатор транзакції.

23. Система для оновлення віддаленої бази даних через мережу, що містить: щонайменше один процесор, зв'язаний з мережею, і (Ф, пам'ять, зв'язану з процесором, яка містить локальну базу даних і команди, адаптовані для виконання ка процесором, для оновлення віддаленої бази даних через мережу, при цьому зазначені команди включають в себе команди для во одержання через мережу множини періодичних оновлень, які базуються на інкрементних змінах у локальній базі даних, причому кожне з множини періодичних оновлень містить щонайменше одну транзакцію, одержання через мережу ініціалізуючого оновлення, що містить версію локальної бази даних у момент часу запуску, зчитування з ініціалізуючого оновлення ідентифікатора останнього періодичного оновлення, 65 зчитування з ініціалізуючого оновлення ідентифікатора останньої транзакції, визначення останнього періодичного оновлення з ідентифікатора останнього періодичного оновлення,

причому останнє періодичне оновлення базується на моменті часу запуску, визначення останньої транзакції з ідентифікатора останньої транзакції причому остання транзакція базується на моменті часу запуску, застосування до віддаленої бази даних транзакцій, сформованих після останньої транзакції, і застосування до віддаленої бази даних періодичних оновлень, сформованих після останнього періодичного оновлення.

24. Система за п. 23, в якій зазначені команди додатково включають в себе команди для відкидання періодичних оновлень, сформованих до моменту часу запуску ініціалізуючого оновлення. 70

25. Система за п. 23, в якій множина періодичних оновлень приймається по одному з регулярними або нерегулярними інтервалами часу.

26. Система за п. 23, в якій множина періодичних оновлень приймається у пакетах з регулярними або нерегулярними інтервалами часу.

27. Система за п. 23, в якій періодичне оновлення містить множину транзакцій, кожна з яких має унікальний 7/5 ідентифікатор транзакції, причому ідентифікатори транзакцій впорядковані випадковим чином. с щі 6) (зе) « (о) (о) і -

- . и? -і се) се) щ» сю» іме) 60 б5