Спосіб, система, пристрій та носій інформації для перевірки достовірності оновлення для запису у віддаленій базі даних, спосіб перевірки достовірності віддаленої бази даних і достовірності передачі даних через
Номер патенту: 80540
Опубліковано: 10.10.2007
Формула / Реферат
1. Спосіб перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється через мережу, причому оновлення містить щонайменше одну подію, який включає в себе:
порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних,
формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження,
зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення відповідає ідентифікатору запису,
зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події відповідає ідентифікатору запису,
визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають запису.
2. Спосіб за п. 1, в якому оновлення для запису є достовірним, якщо кожне виключення, що відповідає запису, підтверджене подією, що відповідає запису.
3. Спосіб за п. 2, в якому види виключень включають в себе:
перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних,
другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і
третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних.
4. Спосіб за п. 3, в якому подія підтверджує виключення, якщо:
подія являє собою видалення запису з локальної бази даних, і виключення належить до першого виду виключень,
подія являє собою додавання запису у локальну базу даних, і виключення належить до другого виду виключень,
подія являє собою зміну запису у локальній базі даних, і виключення належить до третього виду виключень, або
подія являє собою видалення запису з локальної бази даних з подальшим додаванням запису у локальну базу даних,
виключення належить до третього виду виключень.
5. Спосіб за п. 1, що додатково включає:
повторення способу перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним, при визначенні оновлення недостовірним.
6. Спосіб за п. 1, в якому порівняння включає:
порівняння повної локальної бази даних з повною віддаленою базою даних.
7. Спосіб перевірки достовірності віддаленої бази даних, що включає:
передачу у віддалену базу даних множини періодичних оновлень, що базуються на додаткових змінах у локальній базі даних, кожне з множини періодичних оновлень містить щонайменше одну транзакцію,
передачу у віддалену базу даних ініціалізуючого оновлення, що містить версію локальної бази даних у вигляді локальної бази даних на момент часу запуску, при цьому ініціалізуюче оновлення застосовується до віддаленої бази даних,
ідентифікацію розходжень між локальною базою даних і віддаленою базою даних,
визначення, чи є розходження достовірними,
поінформування віддаленої бази даних для застосування періодичних оновлень, час запуску яких більш пізній, ніж час запуску ініціалізуючого оновлення.
8. Спосіб за п. 1, що додатково включає:
повторення способу перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним, при визначенні оновлення недостовірним.
9. Спосіб за п. 7, в якому розходження включають в себе:
перший вид розходжень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних,
другий вид розходжень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і
третій вид розходжень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних.
10. Система для перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється через мережу зв'язку, в якій оновлення містить щонайменше одну подію, система включає:
щонайменше один процесор, приєднаний до мережі зв'язку, і
пам'ять, з'єднану з процесором, пам'ять містить базу даних і команди, адаптовані для виконання процесором, для реалізації перевірки достовірності оновлення запису у віддаленій базі даних, яке здійснюється через мережу зв'язку, причому команди забезпечують виконання процессором
порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних,
формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження,
зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення відповідає ідентифікатору запису,
зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події відповідає ідентифікатору запису, і
визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають запису.
11. Система за п. 10, в якій оновлення для запису є достовірним, якщо кожне виключення, що відповідає запису, підтверджене подією, що відповідає запису.
12. Система за п. 11, в якій види виключень включають в себе:
перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних,
другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних,
третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних.
13. Система за п. 12, в якій подія підтверджує виключення, якщо:
подією є видалення запису з локальної бази даних, і виключення належить до першого виду виключень,
подією є додавання запису у локальну базу даних, і виключення належить до другого виду виключень,
подією є зміна запису у локальній базі даних, і виключення належить до третього виду виключень, або
подією є видалення запису з локальної бази даних з подальшим додаванням запису у локальну базу даних, і виключення належить до третього виду виключень.
14. Система за п. 10, в якій, при визначенні оновлення недостовірним, процесор повторює виконання команд для перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним.
15. Система за п. 11, в якій процесор порівнює повну локальну базу з повною віддаленою базою даних.
16. Система за п. 10, що додатково містить:
щонайменше один віддалений процесор, приєднаний до мережі зв'язку, і
віддалену пам'ять, з'єднану з віддаленим процесором, у віддаленій пам'яті зберігаються віддалена база даних і команди, адаптовані для виконання віддаленим процесором, для:
створення нового елемента на основі нової інформації, одержаної через мережу з бази даних, і
запису покажчика на новий елемент у віддалену базу даних з використанням одиночної безперервної операції, без обмеження доступу до віддаленої бази даних для здійснення пошуку.
17. Система за п. 16, в якій команди додатково адаптовані для фізичного видалення існуючого елемента після запису покажчика у базу даних.
18. Система за п. 16, в якій одиночною безперервною операцією є команда збереження.
19. Система за п. 18, в якій віддалений процесор має розмір слова щонайменше у n-байтів, віддалена пам'ять має розрядність щонайменше у n-байтів та команда збереження записує n-байтів в адресу віддаленої пам'яті, розміщену на межі n-байтів.
20. Машинозчитуваний носій інформації, який містить програмні команди, адаптовані для виконання процесором, для перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється через мережу зв'язку, причому оновлення містить щонайменше одну подію, при цьому команди забезпечують виконання процесором:
порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних,
формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження,
зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення відповідає ідентифікатору запису,
зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події відповідає ідентифікатору запису, і
визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають запису.
21. Машинозчитуваний носій інформації за п. 20, в якому, при визначенні оновлення недостовірним, команди забезпечують повторення перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним.
22. Машинозчитуваний носій інформації за п. 20, в якому оновлення для запису є достовірним, якщо кожне виключення, що відповідає запису, підтверджене подією, що відповідає запису.
23. Машинозчитуваний носій інформації за п. 20, в якому види виключень включають в себе:
перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних,
другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і
третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних.
24. Спосіб перевірки достовірності передачі даних через мережу, що включає: ідентифікацію розходжень даних між джерелом і адресатом, ідентифікацію змін даних у джерелі, які були включені у передачу, і
порівняння розходжень зі змінами для визначення, чи є передача достовірною.
25. Спосіб за п. 24, в якому джерелом і адресатом є сервери доменних імен.
26. Спосіб за п. 24, в якому розходження включають в себе: ім'я домену, яке існує у джерелі і відсутнє в адресаті,
ім'я домену, яке існує в адресаті і відсутнє у джерелі, і
відповідні імена доменів, які відрізняються у джерелі та в адресаті.
27. Спосіб за п. 24, в якому зміни містять щонайменше одне з додавання імені домену у сервер доменних імен, видалення імені домену з сервера доменних імен і зміни імені домену у сервері доменних імен.
28. Пристрій для перевірки достовірності оновлення для запису у віддаленій базі даних, що містить:
засіб ідентифікації розходжень даних між джерелом і адресатом, засіб ідентифікації змін даних у джерелі, які були включені у передачу, і засіб порівняння розходжень зі змінами для визначення, чи є передача достовірною.
Текст
1. Спосіб перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється через мережу, причому оновлення містить щонайменше одну подію, який включає в себе: порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних, формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження, зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення відповідає ідентифікатору запису, зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події відповідає ідентифікатору запису, визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають запису. 2 (19) 1 3 6. Спосіб за п. 1, в якому порівняння включає: порівняння повної локальної бази даних з повною віддаленою базою даних. 7. Спосіб перевірки достовірності віддаленої бази даних, що включає: передачу у віддалену базу даних множини періодичних оновлень, що базуються на додаткових змінах у локальній базі даних, кожне з множини періодичних оновлень містить щонайменше одну транзакцію, передачу у віддалену базу даних ініціалізуючого оновлення, що містить версію локальної бази даних у вигляді локальної бази даних на момент часу запуску, при цьому ініціалізуюче оновлення застосовується до віддаленої бази даних, ідентифікацію розходжень між локальною базою даних і віддаленою базою даних, визначення, чи є розходження достовірними, поінформування віддаленої бази даних для застосування періодичних оновлень, час запуску яких більш пізній, ніж час запуску ініціалізуючого оновлення. 8. Спосіб за п. 1, що додатково включає: повторення способу перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним, при визначенні оновлення недостовірним. 9. Спосіб за п. 7, в якому розходження включають в себе: перший вид розходжень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних, другий вид розходжень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і третій вид розходжень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних. 10. Система для перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється через мережу зв'язку, в якій оновлення містить щонайменше одну подію, система включає: щонайменше один процесор, приєднаний до мережі зв'язку, і пам'ять, з'єднану з процесором, пам'ять містить базу даних і команди, адаптовані для виконання процесором, для реалізації перевірки достовірності оновлення запису у віддаленій базі даних, яке здійснюється через мережу зв'язку, причому команди забезпечують виконання процессором порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних, формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження, зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення відповідає ідентифікатору запису, зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний 80540 4 ідентифікатор події відповідає ідентифікатору запису, і визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають запису. 11. Система за п. 10, в якій оновлення для запису є достовірним, якщо кожне виключення, що відповідає запису, підтверджене подією, що відповідає запису. 12. Система за п. 11, в якій види виключень включають в себе: перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних, другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних. 13. Система за п. 12, в якій подія підтверджує виключення, якщо: подією є видалення запису з локальної бази даних, і виключення належить до першого виду виключень, подією є додавання запису у локальну базу даних, і виключення належить до другого виду виключень, подією є зміна запису у локальній базі даних, і виключення належить до третього виду виключень, або подією є видалення запису з локальної бази даних з подальшим додаванням запису у локальну базу даних, і виключення належить до третього виду виключень. 14. Система за п. 10, в якій, при визначенні оновлення недостовірним, процесор повторює виконання команд для перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним. 15. Система за п. 11, в якій процесор порівнює повну локальну базу з повною віддаленою базою даних. 16. Система за п. 10, що додатково містить: щонайменше один віддалений процесор, приєднаний до мережі зв'язку, і віддалену пам'ять, з'єднану з віддаленим процесором, у віддаленій пам'яті зберігаються віддалена база даних і команди, адаптовані для виконання віддаленим процесором, для: створення нового елемента на основі нової інформації, одержаної через мережу з бази даних, і запису покажчика на новий елемент у віддалену базу даних з використанням одиночної безперервної операції, без обмеження доступу до віддаленої бази даних для здійснення пошуку. 17. Система за п. 16, в якій команди додатково адаптовані для фізичного видалення існуючого елемента після запису покажчика у базу даних. 18. Система за п. 16, в якій одиночною безперервною операцією є команда збереження. 5 80540 6 19. Система за п. 18, в якій віддалений процесор має розмір слова щонайменше у n-байтів, віддалена пам'ять має розрядність щонайменше у n-байтів та команда збереження записує n-байтів в адресу віддаленої пам'яті, розміщену на межі nбайтів. 20. Машинозчитуваний носій інформації, який містить програмні команди, адаптовані для виконання процесором, для перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється через мережу зв'язку, причому оновлення містить щонайменше одну подію, при цьому команди забезпечують виконання процесором: порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних, формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження, зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення відповідає ідентифікатору запису, зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події відповідає ідентифікатору запису, і визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають запису. 21. Машинозчитуваний носій інформації за п. 20, в якому, при визначенні оновлення недостовірним, команди забезпечують повторення перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним. 22. Машинозчитуваний носій інформації за п. 20, в якому оновлення для запису є достовірним, якщо кожне виключення, що відповідає запису, підтверджене подією, що відповідає запису. 23. Машинозчитуваний носій інформації за п. 20, в якому види виключень включають в себе: перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних, другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних. 24. Спосіб перевірки достовірності передачі даних через мережу, що включає: ідентифікацію розходжень даних між джерелом і адресатом, ідентифікацію змін даних у джерелі, які були включені у передачу, і порівняння розходжень зі змінами для визначення, чи є передача достовірною. 25. Спосіб за п. 24, в якому джерелом і адресатом є сервери доменних імен. 26. Спосіб за п. 24, в якому розходження включають в себе: ім'я домену, яке існує у джерелі і відсутнє в адресаті, ім'я домену, яке існує в адресаті і відсутнє у джерелі, і відповідні імена доменів, які відрізняються у джерелі та в адресаті. 27. Спосіб за п. 24, в якому зміни містять щонайменше одне з додавання імені домену у сервер доменних імен, видалення імені домену з сервера доменних імен і зміни імені домену у сервері доменних імен. 28. Пристрій для перевірки достовірності оновлення для запису у віддаленій базі даних, що містить: засіб ідентифікації розходжень даних між джерелом і адресатом, засіб ідентифікації змін даних у джерелі, які були включені у передачу, і засіб порівняння розходжень зі змінами для визначення, чи є передача достовірною. Вимога на пріоритет/перехресне посилання на пов'язані заявки. Дана не попередня заявка заявляє пріоритет попередньої заявки [на патент США з реєстраційним номером 60/330.842 від 1 листопада 2001 року], повністю включеної у даний опис за допомогою посилання, і попередньої заявки [на патент США з реєстраційним номером 60/365.169 від 19 березня 2002 року], повністю включеної у даний опис за допомогою посилання. Даний винахід відноситься до комп'ютерних баз даних, більш конкретно, до способу і системи для надійної перевірки достовірності оновлень віддаленої бази даних. Зі збільшенням розміру баз даних і внаслідок їх сильно розподіленої структури стає все в більшій мірі проблематичним забезпечення однакових версій даних у пов'язаних базах даних. Якщо відбуваються істотні зміни в одній базі даних, то може бути потрібне оновлення інших баз даних для включення вказаних змін у найкоротші терміни. Здійснення таких оновлень може спричинити часте переміщення великих об'ємів даних оновлення у декілька баз даних. Потенційно, такий процес може бути надзвичайно складним. Вказана проблема додатково поєднується з ненадійним зв'язком у системах. У цьому випадку дані можуть бути втрачені при транспортуванні. При цьому потрібна повторна передача даних, і інші бази даних знову оновлюються. Таке повторення істотно знижує ефективність системи і зменшує ділянку, в якій бази даних містять найновіші дані. Фіг.1 - структурна схема системи, відповідно до варіанту здійснення даного винаходу. Фіг.2 структурна схема системи концентратора, відповідно до варіанту здійснення даного винаходу. Фіг.3 ілюструє можливу передачу оновлень бази даних з локальної бази даних у віддалену 7 базу даних, відповідно до варіанту здійснення даного винаходу. Фіг.4 ілюструє файл відправки, відповідно до варіанту здійснення даного винаходу. Фіг.5 ілюструє файл ініціалізації відправки, відповідно до варіанту здійснення даного винаходу. Фіг.6 - часова діаграма, що ілюструє формування файлу відправки та файлу ініціалізації відправки, відповідно до варіанту здійснення даного винаходу. Фіг.7 - блок-схема варіанту здійснення даного винаходу, в якому можуть бути сформовані файли оновлення локальної бази даних. Фіг.8 - блок-схема варіанту здійснення даного винаходу, в якому віддалена база даних може одержувати файли оновлення з локальної бази даних. Фіг.9 - блок-схема іншого варіанту здійснення даного винаходу, в якому віддалена база даних може одержувати файли оновлення з локальної бази даних і перевіряти їх достовірність. Фіг.10А - блок-схема варіанту здійснення даного винаходу, в якому може бути перевірена достовірність файлів оновлення. Фіг.10В - блок-схема іншого варіанту здійснення даного винаходу, в якому може бути перевірена достовірність файлів оновлення. Фіг.11 - ілюстрація перевірки достовірності файлу оновлення, відповідно до варіанту здійснення даного винаходу. Варіанти здійснення даного винаходу забезпечують спосіб і системі для перевірки достовірності оновлень віддаленої бази даних, що здійснюються через мережу зв'язку. Може бути здійснене порівняння запису локальної бази даних і запису віддаленої бази даних, і можуть бути сформовані виключення. Кожне виключення може описувати «розходження між записами віддаленої і локальної баз даних. З кожним виключенням може бути зіставлений ідентифікатор виключення, причому ідентифікатор виключення може відповідати ідентифікатору запису. З кожною подією в оновленні може бути зіставлений ідентифікатор події, причому ідентифікатор події може відповідати ідентифікатору запису. Для визначення, чи є оновлення достовірним, може бути здійснене порівняння подій і виключень, які відповідають запису. Фіг.1 - структурна схема, що ілюструє систему, відповідно до варіанту здійснення даного винаходу. В основному система 100 може містити велику резидентну базу даних, через мережу зв'язку одержувати запити на пошук і забезпечувати відповіді по пошуку. Наприклад, система 100 може являти собою симетричний багатопроцесорний (SMP) комп'ютер, наприклад, такий як IBM RS/6000®M80 або S80, що виробляється компанією IBM (Armonk, штат НьюЙорк), Sun Enterprise™10000, що виробляється Sun Microsystems (Santa Clara, штат Каліфорнія) і т.д. Система 100 також може являти собою багатопроцесорний персональний комп'ютер, наприклад, такий як CompaqProLiant™ML530 (щο має два процесори Intel Pentium® III, 866МГц), що 80540 8 виробляється компанією Hewlett-Packard (Palo Alto, штат Каліфорнія). Система 100 може також містити багатопроцесорну операційну систему, наприклад, таку як IBM AIX® 4L Sun Solaris™ 8 Operating Environment, Red Hat LINUX® 6.2, і т.д. Система 100 може одержувати через мережу 124 зв'язку періодичні оновлення, які можуть паралельно включатися у базу даних. Варіанти здійснення даного винаходу можуть досягати дуже високої продуктивності оновлення і пошуку по базі даних за допомогою включення кожного оновлення у базу даних без використання блокування бази даних або засобів керування доступом. У варіанті здійснення система 100 може містити, щонайменше, один процесор 102-1, приєднаний до шини 101. Процесор 102-1 може містити внутрішній кеш (наприклад, кеш L1, не зображений). Між процесором 102-1 і шиною 101 може бути резидентно розміщений кеш 103-1 вторинної пам'яті (наприклад, кеш L2, кеші L2/L3 і т.д.). У переважному варіанті здійснення система 100 може містити декілька процесорів 102-1...102Р, приєднаних до шини 101. Між декількома процесорами 102-1...102-Р і шиною 101 також може бути резидентно розміщено декілька кешів 103-1...103-Р вторинної пам'яті (наприклад, архітектура крізного перегляду) або, у вигляді іншого варіанту, до шини 101 може бути приєднаний, щонайменше, один кеш 103-1 вторинної пам'яті (наприклад, архітектура з передісторією). Система 100 може містити пам'ять 104, наприклад, таку як оперативний запам'ятовуючий пристрій (ОЗП), і т.д., приєднану до шини 101 для зберігання інформації та інструкцій, які повинні виконуватися декількома процесорами 102-1...102-Р. Пам'ять 104 може зберігати велику базу даних, наприклад, для перетворення імен доменів Інтернет в адреси в Інтернет, для перетворення імен або номерів телефонів у мережні адреси, для забезпечення і оновлення даних профілю абонента, для забезпечення і оновлення даних присутності користувача і т.д. Переважно, розмір бази даних і кількість перетворень за секунду можуть бути дуже великими. Наприклад, пам'ять 104 може містити, щонайменше, 64Гбайт ОЗП і може містити базу даних імен доменів у 500М (тобто, 500´106) записів, базу даних абонентів у 500М записів, базу даних мобільності номерів телефонів у 450М записів і т.д. У можливій архітектурі 64-бітової системи, наприклад, такої як система, що містить, щонайменше, один 64-бітовий процесор 102-1 зі зворотним порядком байтів, приєднаний, щонайменше, до 64-бітової шини 101, і 64-бітову пам'ять 104, 8-байтове значення покажчика може бути записане в адресу (комірки) пам'яті на межі 8байтів (тобто, адреса пам'яті, що ділиться на вісім, або, наприклад, κΝ) з використанням одиночної безперервної операції. В основному, наявність кешу 103-1 вторинної пам'яті може просто затримувати запис 8-байтового покажчика у пам'ять 104. Наприклад, в одному варіанті здійснення, кешем 103-1 вторинної пам'яті може 9 бути кеш крізного перегляду, що діє у режимі крізного запису так, щоб одиночна команда збереження 8-байтів могла переміщувати вісім байтів даних з процесора 102-1 у пам'ять 104 без переривання і всього лише за два такти системних годин. В іншому варіанті здійснення кешем 103-1 вторинної пам'яті може бути кеш крізного перегляду, що діє у режимі зворотного запису так, щоб 8-байтовий покажчик міг бути спочатку записаний у кеш 103-1 вторинної пам'яті, який потім, у більш пізній час, може записати 8байтовий покажчик у пам'ять 104, наприклад, при запису у пам'ять 104 рядка кешу, в якому зберігається 8-байтавий покажчик (тобто, наприклад, коли «скидається у пам'ять» визначений рядок кешу, або повністю кеш вторинної пам'яті). Зрештою, з точки зору процесора 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-байтове значення покажчика може бути записане у комірку пам'яті 8N-4 з використанням одиночної команди збереження. 80540 10 Безумовно, якщо 4-байтове значення покажчика записується у комірку, що перетинає межу 4 байтів, наприклад, 4Ν-2, то всі чотири байти даних не можуть бути передані з процесора 102-1 з використанням одиночної команди збереження, і значення покажчика, резидентно розміщене у пам'яті 104, може бути недійсним протягом деякого періоду часу. Система 100 також може містити постійний запам'ятовуючий пристрій (ПЗП) 106, або інші статичні запам'ятовуючі пристрої, приєднані до шини 101 для зберігання статичної інформації та інструкцій для процесора 102-1. Для зберігання інформації та команд до шини 101 може бути приєднаний запам'ятовуючий пристрій 108, такий як магнітний або оптичний диск. Система 100 також може містити пристрій 110 відображення (наприклад, монітор на рідких кристалах LCD (РДК)) і пристрій 112 введення даних (наприклад, клавіатуру, мишу, кульовий покажчик і т.д.), приєднані до шини 101. Система 100 може містити декілька мережних інтерфейсів 114-1...114-О, які можуть передавати і приймати електричні, електромагнітні або оптичні сигнали, що несуть потоки цифрових даних, які являють собою різні види інформації. У варіанті здійснення мережний інтерфейс 114-1 може бути приєднаний до шини 101 і до локальної мережі зв'язку LAN (ЛМ) 122, у той же час мережний інтерфейс 114-О може бути приєднаний до шини 101 і глобальної мережі зв'язку WAN (ГМ) 124. Декілька мережних інтерфейсів 114-1...114-О можуть підтримувати різні мережні протоколи, включаючи, наприклад, Gigabit Ethernet (наприклад, IEEE Стандарт 802.32002, виданий у 2002), Fiber Channel (наприклад, ANSI Стандарт Х.3230-1994, виданий у 1994) і т.д. До ЛМ 122 і ГМ 124 може бути приєднано декілька мережних комп'ютерів 120-1...120-Ν. В одному варіанті здійснення ЛМ 122 і ГМ 124 можуть бути фізично окремими мережами зв'язку, у той же час в іншому варіанті здійснення ЛМ 122 і ΓΜ 124 можуть бути з'єднані через мережний шлюз або маршрутизатор (для зручності не зображені). Як інший варіант, ЛМ 122 і ГМ 124 можуть бути однією і тією ж мережею. Як зазначено вище, система 100 може забезпечувати послуги розрізнення DNS (служба імен доменів). У варіанті здійснення для розрізнення (процесу визначення адрес) DNS послуги розрізнення DNS в основному можуть бути розділені між транспортуванням по мережі і функціями пошуку даних. Наприклад, система 100 може бути механізмом пошуку (LUE) для сервера, оптимізованим для пошуку даних по великих наборах даних, у той же час множина мережних комп'ютерів 120-1...120-Ν може бути множиною механізмів протоколу (РЕ) клієнта, оптимізованих для обробки мережі зв'язку і транспортування. LUE може бути потужним багатопроцесорним сервером, який зберігає у пам'яті 104 весь набір записів DNS, щоб сприяти високошвидкісному високопродуктивному пошуку і оновленню. В іншому варіанті здійснення послуги розрізнення DNS можуть забезпечуватися множиною потужних багатопроцесорних серверів, або множиною LUE, 11 кожний з яких зберігає у пам'яті підмножину всього набору записів DNS, щоб сприяти високошвидкісному високопродуктивному пошуку і оновленню. Навпаки, множина РЕ може бути звичайними вузькоспеціалізораними пристроями, які базуються на PC, що виконують ефективну багатозадачну операційну систему (наприклад, Red Hat LINUX® 6.2), які мінімізують транспортне навантаження обробки мережі зв'язку на LUE для максимізації доступних ресурсів для розрізнення DNS. Пристрої РЕ можуть обробляти нюанси протоколу DNS провідної лінії зв'язку, реагувати на недійсні запити DNS і мультиплексувати дійсні запити DNS в LUE через ЛМ 122. В іншому варіанті здійснення, що містить множину LUE, які зберігають підмножини записів DNS, РЕ можуть визначати, який пристрій LUE повинен одержати кожний дійсним запит DNS, і мультиплексувати дійсні запити DNS у відповідні LUE. Кількість РЕ для одного LUE може визначатися, наприклад, кількістю запитів DNS, яка повинна оброблятися за секунду, і робочими характеристиками конкретної системи. Для визначення співвідношень відповідності і режимів також можуть використовуватися інші показники. У загальному випадку, можуть підтримуватися інші варіанти здійснення великого об'єму, що базуються на запитах, які включають, наприклад, розрізнення номерів телефонів, обробку сигналізації SS7, визначення для встановлення відповідності номера телефону з абонентом, визначення місцеположення і присутності абонента і т.д. У варіанті здійснення центральний сервер 1401 оперативної обробки транзакцій (OLTP) може бути приєднаний до ГМ 124 і одержувати з різних джерел додатки, зміни і видалення (тобто, трафік оновлення) для бази даних 142-1. OLTP сервер 140-1 може передавати оновлення через ГМ 124 у систему 100, яка містить локальну копію бази даних 142-1. OLTP сервер 140-1 може бути оптимізований для обробки трафіку оновлення у різних форматах і протоколах, включаючи, наприклад, Протокол Передачі Гіпертекстових файлів (HTTP), Протокол Реєстратора Запису (RRP), Нарощуваний Протокол Ініціалізації (ЕРР), Систему Керування Службами/Механізований Загальний Інтерфейс (MGI) 800, та інші оперативні протоколи ініціалізації. Сукупність LUE тільки для читання може бути розгорнена в архітектурі типу концентратора і спиці (лінії, що йде від центра до периферії) для забезпечення можливості високошвидкісного пошуку, що супроводжується об'ємними додатковими оновленнями з OLTP сервера 140-1. В альтернативному варіанті здійснення дані можуть бути розподілені по декількох OLTP серверах 140-1...140-S, кожний з яких може бути приєднаний до ГМ 124. OLTP сервера 140-1...140S можуть одержувати з різних джерел додатки, зміни і видалення (тобто, трафік оновлення) для баз даних, що відповідають їм, 142-1…142-S (не зображені для зручності). OLTP сервера 1401...140-S можуть передавати оновлення через ГМ 124 у систему 100, яка може містити копії баз 80540 12 даних 142-1...142-S, інші дані, що динамічно створюються, і т.д. Наприклад, у варіанті здійснення для геолокації, OLTP сервера 1401...140-S можуть одержувати трафік оновлення з груп віддалених датчиків. В іншому альтернативному варіанті здійснення множина мережних комп'ютерів 120-1...120-N також може одержувати через ГМ 124 або ЛМ 122 додатки, зміни і видалення (тобто, трафік оновлення) з різних джерел. У цьому варіанті здійснення множина мережних комп'ютерів 120-1...120-N може передавати у систему 100 оновлення, а також запити. У варіанті здійснення система 100 може містити віддалену базу даних (наприклад, віддалена база даних 210). З OLTP сервера 140-1 через ГМ 124, наприклад, може бути одержана нова інформація, або трафік оновлення. У варіанті здійснення нова інформація може містити зміни, щонайменше, одного елемента, який існує у віддаленій базі даних. Система 100 на основі нової інформації, одержаної через мережу зв'язку, може створити новий елемент віддаленої бази даних, і без обмеження доступу до віддаленої бази даних для пошуку, записати у віддалену базу даних покажчик на новий елемент з використанням одиночної безперервної операції, наприклад, такої як інструкція збереження. У варіанті здійснення, процесор 102-1 може містити розмір слова, щонайменше, у n-байтів, пам'ять 104 може мати розрядність, щонайменше, у n-байтів, та інструкція збереження може записувати nбайтів у віддалену адресу пам'яті, розміщену на межі n-байтів. В іншому варіанті здійснення система 100 може фізично видалити з пам'яті 104 існуючий елемент, що відповідає новому елементу, після запису покажчика у віддаленій базі даних. У варіанті здійснення розрізнення DNS кожний РЕ (наприклад, кожний з декількох мережних комп'ютерів 120-1...120-N) може комбінувати, або мультиплексувати, декілька повідомлень запитів DNS, одержаних через глобальну мережу зв'язку (наприклад, ГМ 124), в одиночний СуперПакет Запиту і передавати СуперПакет Запиту через локальну мережу зв'язку (наприклад, ЛМ 122) в LUE (наприклад, систему 100). LUE може комбінувати, або мультиплексувати, декілька відповідей на повідомлення-запити DNS в одиночний СуперПакет Відповіді і передавати СуперПакет Відповіді через локальну мережу зв'язку у відповідний РЕ. В основному, максимальний розмір СуперПакета Відповіді або Запиту може бути обмежений максимальним блоком передачі (MTU) фізичного мережного рівня (наприклад, Gigabit Ethernet). Наприклад, стандартні розміри повідомлення запиту і відповіді DNS, що не перевищують 100 байтів і 200 байтів, відповідно, дозволяють мультиплексувати більше 30 запитів в одиночний СуперПакет Запиту, а також мультиплексувати більше 15 відповідей в одиночний СуперПакет Відповіді. Однак, в одиночний СуперПакет Запиту може бути включена менша кількість запитів (наприклад, 20 запитів), щоб при формуванні відповіді уникнути 13 переповнення MTU (наприклад, у 10 відповідей). Для MTU більшого розміру кількість мультиплексованих запитів і відповідей, відповідно, може бути збільшена. Кожний багатозадачний РЕ може мати вхідний потік і вихідний потік для керування запитами і відповідями DNS, відповідно. Наприклад, вхідний потік може демаршалінгувати (розпаковувати) компоненти запиту DNS з вхідних; пакетів запитів DNS, одержаних через глобальну мережу зв'язку, і мультиплексувати декілька мілісекунд запитів в одиночний СуперПакет Запиту. Потім вхідний потік може передавати СуперПакет Запиту через локальну мережу зв'язку в LUE. Навпаки, вихідний потік може одержувати СуперПакет Відповіді з LUE, демультиплексувати відповіді, що містяться в ньому, і маршалінгувати (упаковувати у стандартний формат) різні поля у дійсну відповідь DNS, яка потім може бути передана через глобальну мережу зв'язку. В основному, як зазначено вище, можуть підтримуватися інші варіанти здійснення великого об'єму, що базуються на запитах. У варіанті здійснення СуперПакет Запиту може також містити інформацію про стан, яка відповідає кожному запиту DNS, наприклад, таку як вихідна адреса, вид протоколу і т.д. LUE може включати у СуперПакет Відповіді інформацію про стан і відповідні відповіді DNS. Потім кожний РЕ може формувати і повертати повідомлення дійсних відповідей DNS з використанням інформації, переданої з LUE. Отже, кожний РЕ може, переважно, функціонувати як пристрій, що не змінює свого стану у процесі виконання, тобто, дійсні відповіді DNS можуть бути сформовані з інформації, що міститься у СуперПакеті Відповіді. В основному, LUE може повертати СуперПакет Відповіді в РЕ, з якого виходив вхідний СуперПакет, однак, очевидні інші можливі варіанти. В альтернативному варіанті здійснення кожний РЕ може підтримувати інформацію про стан, яка відповідає кожному запиту DNS, і включати у СуперПакет Запиту посилання, або дескриптор, на інформацію про стан. LUE може включати у СуперПакет Відповіді посилання на інформацію про стан і відповідні відповіді DNS. Потім кожний РЕ може формувати і повертати повідомлення дійсних відповідей DNS з використанням посилань на інформацію про стан, переданих з LUE, а також підтримуваної ним інформації про стан. У цьому варіанті здійснення LUE може повертати СуперПакет Відповіді в РЕ, з якого виходив вхідний СуперПакет. На Фіг.2 представлена структурна схема архітектури тину концентратора і спиць (зіркоподібної топології) відповідно до варіанту здійснення даного винаходу. В основному, система може містити локальну базу даних 200 (яка може знаходитися у центральному OLTP концентраторі 140) і одну або більшу кількість віддалених баз даних 210 (які можуть знаходитися у пристроях LUE 100), з'єднаних з локальною базою даних 200 за допомогою будь-якого механізму з'єднання, наприклад, Інтернету або ЛМ 80540 14 122. Бази даних можуть передавати і одержувати дані оновлення. Відповідно до Фіг.3, у варіантах здійснення даного винаходу локальна база даних 200 передає у віддалену базу даних 210 F файлів 3001...300-F відправки та файл ініціалізації 310 відправки для оновлення віддаленої бази даних 210. Файли оновлення можуть передаватися індивідуально або у пакетах, наприклад, множина файлів 300 відправки, один файл 300 відправки і один файл ініціалізації 310 відправки, множина файлів 300 відправки і один файл ініціалізації 310 відправки, одиночний файл 300 відправки, або одиночний файл ініціалізації 310 відправки. У варіанті здійснення даного винаходу процесор 104 може одержувати з локальної бази даних 200 файл 300 відправки і/або файл ініціалізації 310 відправки, що містить дані оновлення. Система 150 може одержувати файл 300 відправки та файл ініціалізації 310 відправки у віддаленій базі даних 210 через інтерфейс 118 зв'язку. Потім процесор 104 може порівняти дані оновлення у файлі 300 відправки або в файлі ініціалізації 310 відправки з відповідними даними у віддаленій базі даних 210. Якщо у віддаленій базі даних 210 дані інші, то процесор 104 може застосувати файл 300 відправки або файл ініціалізації 310 відправки до віддаленої бази даних 210. Відповідно, згодом віддалена база даних 210 може бути оновлена даними, що відповідають даним оновлення у локальній базі даних 200. Фіг.4 ілюструє файл 300 відправки, відповідно до варіанту здійснення даного винаходу. Поля файлу 300 можуть включати в себе, наприклад, ідентифікатор 400 файлу, час 402 формування файлу, кількість 404 транзакцій N у файлі, повний розмір 406 файлу, контрольну суму 408 або будьякий подібний індикатор контролю помилок і транзакції 410-1...410-N (що містять ідентифікатори транзакцій). Вказані поля файлу відправки є можливими варіантами, призначеними для ілюстрації, але не для обмеження контексту варіантів здійснення даного винаходу. У файл 300 відправки може бути включене будь-яке поле, яке може бути корисним. Файл 300 відправки містить зміни у локальній базі даних 200 між двома моментами часу. Ці зміни можуть включати в себе, наприклад, додавання нових ідентифікаторів (тобто, ідентифікаторів записів даних), видалення існуючих ідентифікаторів, зміни одного або більшої кількості записів даних, що відповідають ідентифікатору, перейменування ідентифікатора, холосту команду і т.д. Одна або більша кількість вказаних змін може здійснюватися послідовно і може називатися транзакціями. Файл 300 відправки може містити унікальні ідентифікатори даних транзакцій. Транзакції можуть бути записані у файлі 300 відправки у тому порядку, в якому вони здійснені у локальній базі даних 200. Додатково, для транзакцій, що містять більше однієї зміни, зміни можуть бути записані всередині транзакції у тому порядку, в якому вони здійснені у локальній базі даних 200. 15 В основному, ідентифікатори транзакцій можуть призначатися транзакціям у випадковому порядку. Тобто, ідентифікатори транзакцій не обов'язково монотонно зростають у часі. Наприклад, дві послідовні транзакції можуть мати ідентифікатори транзакцій 10004 і наступний за ним 10002. Відповідно, черговість здійснення транзакції може бути визначена її розміщенням у поточному файлі 300-F або її розміщенням у попередньому файлі 300-(F-1). В основному, для повного завершення оновлення віддаленої бази даних із застосуванням одноп файлу відправки, транзакції не можуть охоплювати сусідні файли 300. Це запобігає перериванню оновлення через мережну затримку, яка може привести до помилкових даних у віддаленій базі даних 210. Фіг.5 ілюструє файл ініціалізації 310 відправки, відповідно до варіанту здійснення даного винаходу. Поля файлу ініціалізації 310 відправки можуть включати в себе, наприклад, ідентифікатор 500 файлу, час 502 формування файлу, кількість 504 транзакцій N у файлі, повний розмір 506 файлу, контрольну суму 508 або будь-який подібний індикатор контролю помилок і копію 516 (даних) повної локальної бази даних. Файл ініціалізації 310 відправки може додатково містити поле 510, що є ідентифікатором 400 файлу останнього файлу 300 відправки, сформованого до формування файлу 310, і поле 512, що є ідентифікатором останньої транзакції, фіксованої у локальній базі даних 200 до формуванні файлу ініціалізації 310 відправки. Дані у локальній і віддаленій базах даних 200, 210 можуть бути розподілені по таблицях, що резидентно зберігаються у базах даних 200, 210. Бази даних 200, 210 можуть підтримувати довільну кількість таблиць. Отже, коли база даних має таблиці, файл ініціалізації 310 відправки може містити для кожної таблиці поле, яке вказує кількість записів, зроблених у таблиці. Наприклад, база даних імен доменів може містити таблицю доменів і таблицю серверів доменних імен. Отже, файл ініціалізації відправки може містити поле, яке вказує кількість записів у таблиці доменів і поле, яке вказує кількість записів у таблиці серверів доменних імен. Поле може визначати, наприклад, ім'я таблиці, ключ, що використовується для індексування записів у таблиці, і кількість записів у таблиці. Додатково, файл ініціалізації 310 відправки може містити поле, яке вказує версію файлу ініціалізації 310 відправки, звичайно 1.0. Вказані поля файлу ініціалізації відправки є можливими варіантами, призначеними для ілюстрації, але не обмеження, контексту варіантів здійснення даного винаходу. В файл ініціалізації 310 відправки може бути включене будь-яке поле, яке може бути корисним. Як зазначено вище, файл ініціалізації 310 відправки може містити, наприклад, копію повної локальної бази даних 200, уніфіковану за зчитуванням даних. Файл ініціалізації 310 відправки може стати уніфікованим з локальною базою даних 200 у момент часу t між ts і tf, де ts є часом початку формування файлу ініціалізації 310 відправки, a tf є часом завершення формування. По суті, єдиною операцією, яка може з'явитися в 80540 16 файлі ініціалізації 310 відправки, є операція "додавання" Тобто, при формуванні файлу ініціалізації 310 відправки в нього можуть бути записані копії повної локальної бази даних 200 у момент часу t. Отже, для запису локальної бази даних 200 в файл ініціалізації 310 відправки може бути виконана операція "додавання". Ідентифікатори можуть бути записані в файл ініціалізації 310 відправки у випадковому порядку. В іншому варіанті, за наявності зовнішніх ідентифікаторів, записи даних, на які є посилання, можуть бути записані до запису даних, що має посилання. Додавання полів 510 і 512 може забезпечувати файл ініціалізації 310 відправки деякою інформацією про файли 300 відправки, які можуть бути сформовані і передані у віддалену базу даних 210 під час формування файлу ініціалізації 310 відправки. Однак, формування файлу 300 відправки і формування файлу ініціалізації 310 відправки можуть бути не пов'язані один з одним відносно відсутності залежності між ними при формуванні. Така структура і процес можуть запобігти менш ефективному підходу, при якому формування і застосуванні файлу відправки може бути припинене до завершення формування файлу ініціалізації відправки. При продовженні формування і застосування файлів 300 відправки під час формування файлу ініціалізації 310 відправки, як у варіанті здійснення даного винаходу, може здійснюватися суворий контроль помилок файлів 300 відправки, а також накладення обмежень на віддалену базу даних 210, наприклад, можуть бути зроблені обмеження відносно однозначності або обмеження на зовнішні ідентифікатори. Накладення обмежень може захищати цілісність даних у віддаленій базі даних 210 за допомогою відхилення транзакцій, що порушують реляційні моделі віддаленої бази даних 210. Наприклад, обмеження відносно однозначності може перешкоджати повторному збереженню у базі даних 210 одного і того ж ключа. На Фіг.6 представлена часова діаграма, що ілюструє формування файлу відправки та файлу ініціалізації відправки, відповідно до варіанту здійснення даного винаходу. Згідно з Фіг.6, файли 300 відправки (з sf-1 no s-21) формуються з регулярними інтервалами часу. В альтернативному варіанті здійснення файли 300 відправки можуть формуватися з нерегулярними інтервалами часу. У загальному випадку, формування файлу відправки не займає інтервал часу повністю. Наприклад, якщо файли формуються у 5-хвилинні інтервали часу, то для завершення формування файлу не потрібно повністю 5 хвилин. Додатково, якщо у локальній базі даних 200 проводяться зміни під час формування файлу 300 відправки, то дані зміни будуть зібрані у наступному файлі 300 відправки. Наприклад, якщо формування файлу відправки sf4 починається о 12:05:00 і завершується о 12:05:02, то будь-які зміни у локальній базі даних 200, здійснені між 12:05:00 і 12:05:02, збираються у 17 файл відправки sf-5 (наприклад, 300-5), який охоплює інтервал часу з 12:05:00 до 12:10:00. Фіг.6 ілюструє файли 300-5 і 300-19 відправки. У вказаних файлах, серед інших полів, зображені ідентифікатор 601 файлу (sf-5, sf-19), час 603 формування файлу, та ідентифікатори 605 транзакцій (наприклад, 10002). Потрібно зазначити, що ідентифікатори транзакцій можуть бути не впорядкованими монотонно. Як згадано вище, ідентифікатори транзакцій можуть мати довільні значення. Однак, безпосередньо відповідні транзакції записані у файл 300 відправки у порядку, в якому вони здійснені у локальній базі даних 200. Оскільки формування файлу ініціалізації 310 відправки і формуванню файлу 300 відправки можуть бути не пов'язані, то файл ініціалізації 310 відправки може формуватися у будь-який момент часу. Наприклад, файл ініціалізації 310 відправки може формуватися до, протягом або після формування файлу 300 відправки. Фіг.6 ілюструє файл ініціалізації 310 відправки, що формується у проміжок часу між формуванням четвертого і п'ятого файлів відправки (наприклад, sf-4 і sf-5). У варіанті здійснення файл ініціалізації 310 відправки може, серед інших полів, містити ідентифікатор 610 файлу (isf-Ι), ідентифікатор 615 файлу для останнього файлу відправки, сформованого перед формуванням файлу ініціалізації відправки, та ідентифікатор 620 транзакції для останньої транзакції, завершеної перед формуванням файлу ініціалізації відправки. У даному можливому варіанті останнім сформованим файлом відправки є файл відправки sf-4, а останньою завершеною транзакцією є транзакція 10001. Формування файлу ініціалізації 310 відправки починається 611 о 12:07:29. Коли починається формування файлу ініціалізації 310 відправки, перша половина транзакцій у файлі 300-5 відправки (sf-5), транзакції 10002, 10005 і 10001 були вже завершені у локальній базі даних 200. Відповідно, файл ініціалізації 310 відправки може мати інформацію про ці транзакції і може зібрати ці транзакції в файлі ініціалізації 310 відправки. Однак, файл ініціалізації 310 відправки не може мати інформації про подальші транзакції 10003 і 10004, які здійснюються після початку формування файлу ініціалізації відправки. При формуванні файлу ініціалізації 310 відправки файли відправки, починаючи з файлу 300-5 відправки, можуть продовжувати формуватися з регулярними інтервалами часу. Дані файли можуть передаватися віддаленій базі даних 210 і застосовуватися. Формування файлу ініціалізації 310 відправки може бути завершене о 1:15:29, у проміжку часу між формуванням 18-го і 19-го файлів 300 відправки (sf-18 і sf-19), і не може впливати на формування 19-го файлу 300-19 відправки. Після одержання і завантаження у віддаленій базі даних 210 файлу ініціалізації 310 відправки віддалена база даних 210 може не враховувати файли відправки сформовані до формування файлу ініціалізації 310 відправки. Це можливо, наприклад, внаслідок того, що файл ініціалізації 80540 18 310 відправки містить всі зміни у локальній базі даних 200, які були записані у попередні файли 300 відправки. У цьому можливому варіанті віддаленій базі даних 210 може не бути потрібно враховувати файли відправки з першого по четвертий (з sf-1 no sf-4). Зміни, записані у даних файлах відправки, з sf-1 no sf-4, також можуть бути записані в файлі ініціалізації 310 відправки. Вказані попередні файли відправки (з sf-1 no sf-4) можуть бути видалені або, в іншому варіанті, заархівовані. Аналогічно, віддалена база даних 210 може не враховувати транзакції, завершені до формування файлу ініціалізації 310 відправки, які були включені у файл 300 відправки, сформований згодом. Дані транзакції можуть бути включені в файл ініціалізації 310 відправки при його формуванні. Наприклад, тому віддаленій базі даних 210 може не бути потрібно враховувати перші три транзакції 10002, 10005, 10001 з файлу відправки sf-5. Дані транзакції, записані у файл відправки sf-5, можуть також бути записані в файл ініціалізацій 310 відправки. Дані завершені транзакції можуть бути видалені, або в іншому варіанті, заархівовані. На Фіг.7 представлена блок-схема варіанту здійснення даного винаходу, в якому можуть бути сформовані файли оновлення локальної бази даних. Система може формувати (705) декілька періодичних оновлень, що базуються на додаткових змінах у локальній базі даних. Кожне оновлення може містити одну або більшу кількість транзакцій. Потім система може передати (710) періодичні оновлення у віддалену базу даних. При формуванні періодичних оновлень, система може почати формувати (715) оновлення ініціалізації у момент часу запуску. Оновлення ініціалізації може містити версію повної локальної бази даних. Система може визначити (720) останнє періодичне оновлення, сформоване до моменту часу запуску, і останню транзакцію, завершену до моменту часу запуску. Потім система може передати (725) оновлення ініціалізації у віддалену базу даних. Оновлення ініціалізації може містити ідентифікатор оновлення, що відповідає останньому сформованому періодичному оновленню, та ідентифікатор транзакції, що відповідає останній завершеній транзакції. Наприклад, OLTP 140 може формувати (705) файли 300 відправки з деяким регулярним або нерегулярним інтервалом часу. Потім OLTP 140 може передати (710) файли 300 відправки у віддалену базу даних 210. При формуванні файлів 300 відправки, OLTP 140 може почати формування (715) файлу ініціалізації 310 відправки у момент часу запуску 611. Файл ініціалізації 310 відправка може містити копію повної локальної бази даних 200. Потім OLTP 140 може визначити (720) останній файл 300 відправки, сформований до часу запуску 611 для формування файлу ініціалізації 310 відправки, і останню транзакцію, завершену до часу запуску 611 для формування файлу ініціалізації 310 відправки. Потій OLTP 140 може передати (725) файл ініціалізації 310 відправки у віддалену базу даних 210. Файл 19 ініціалізації 310 відправки може містити ідентифікатор 615 файлу відправки, що відповідає останньому сформованому файлу 300 відправки, і ідентифікатор транзакції 620, що відповідає останній завершеній транзакції. На Фіг.8 представлена блок-схема варіанту здійснення даного винаходу, в якому віддалена база даних може одержувати файли оновлень з локальної бази даних. Система може одержати (805) декілька періодичних оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій. Періодичні оновлення можуть бути одержані окремо або у пакетах. У деякий момент часу система може одержати (810) оновлення ініціалізації. Оновлення ініціалізації може містити версію повної локальної бази даних. Система може зчитати (815) з оновлення ініціалізації ідентифікатор останнього періодичного оновлення і ідентифікатор останньої транзакції. Потім система може визначити (820) останнє періодичне оновлення, що відповідає ідентифікатору оновлення, і останню транзакцію, що відповідає ідентифікатору транзакції. Періодичне оновлення і транзакція можуть бути, відповідно, останнім сформованим оновленням і останньою завершеною транзакцією до формування оновлення ініціалізації. Система може застосувати (825) до віддаленої бази даних незавершені транзакції, що залишилися у відповідному періодичному оновленні. Потім системі може застосувати (830) до віддаленої бази даних періодичні оновлення, що залишилися, сформовані після останнього періодичного оновлення. Застосування оновлення ініціалізації, переважно, заповнює будь-які раніше втрачені періодичні оновлення. Наприклад, LUE 100 може одержати (805) файли 300 відправки з деяким регулярним або нерегулярним інтервалом часу. Файли 300 відправки можуть бути одержані окремо або у пакетах. У деякий момент часу LUE 100 може одержати (810) файл ініціалізації 310 відправки. LUE 100 може зчитати (815) з файлу ініціалізації 310 відправки ідентифікатор 615 файлу відправки і ідентифікатор 620 транзакції. Потім LUE 100 може визначити (820) файл 300 відправки, що відповідає ідентифікатору 615 файлу відправки, і транзакцію 605, що відповідає ідентифікатору 620 транзакції. Файл відправки і транзакція можуть бути, відповідно, останнім сформованим файлом відправки і останньою завершеною транзакцією до формування файлу ініціалізації 310 відправки. LUE 100 може застосувати (825) до віддаленої бази даних 210 незавершені транзакції 605, що залишилися, у відповідному файлі 300 відправки. Потім LUE 100 може застосувати (830) до віддаленої бази даних 210 файли 300 відправки, що залишилися, які йдуть за останнім файлом відправки sf-4. В альтернативному варіанті здійснення, наприклад, LUE 100 може відкинути або заархівувати файли 300 відправки, які не були застосовані до віддаленої бази даних 210, і/або мають час формування 603 до часу формування 611 файлу ініціалізації відправки. Відкинуті або 80540 20 заархівовані файли 300 відправки можуть включати в себе файл відправки sf-4, що відповідає ідентифікатору 61 ί файлу відправки. Зрозуміло що після застосування файлу ініціалізації 310 відправки будь-які більш пізні файли 300 відправки, які могли бути вже застосовані до віддаленої бази даних 210, можуть не зберегтися, оскільки віддалена база даних 210 може стати уніфікованою за зчитуванням з файлом ініціалізації 310 відправки. Відповідно, ці більш пізні файли 300 відправки можуть бути застосовані повторно. У варіанті здійснення даного винаходу файли 300 відправки та файл ініціалізації 310 відправки можуть передаватися з локальної бази даних 200 у віддалену базу даних 210 без повідомлення (про успішне одержання даних , тобто, без сигналу ACK/NACK для вказування того, що файли були успішно одержані. Це, переважно, скорочує додаткову службову сигналізацію, яку може створювати сигнал ACK/NACK. В альтернативному варіанті здійснення з віддаленої бази даних 210 може передаватися сигнал ACK/NACK для вказування того, що файли успішно одержані. У цьому варіанті здійснення сигнал ACK/NACK може передаватися у системах з ненадійним зв'язком. На Фіг.9 представлена блок-схема іншого варіанту здійснення даного винаходу, в якому система може перевіряти достовірність файлів оновлення, переданих з локальної бази диких і одержаних у віддаленій базі даних. Тут, система може передати (905) множину періодичних оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій. Періодичні оновлення можуть бути передані окремо або у пакетах. У деякий момент часу система може передати (910) оновлення ініціалізації і застосувати оновлення ініціалізації до віддаленої бази даних. Оновлення ініціалізації може містити версію повної локальної бази даних. Спочатку система, за допомогою порівняння баз даних, може ідентифікувати (915) розходження між локальною і віддаленою базами даних. Система може визначити (920), чи є розходження дійсними або помилковими. Потім система може застосувати (925) до віддаленої бази даних періодичні оновлення, відповідно до варіанту здійснення даного винаходу. Даний варіант здійснення, переважно, може забезпечувати відсутність помилок у віддаленій базі даних, що є результатом одержання оновлень з локальної бази даних. Наприклад, OLTP 140 може передати (905) у віддалену базу даних 210 файли 300 відправки з деяким регулярним або нерегулярним інтервалом часу. Файли 300 відправки можуть бути передані окремо або у пакетах. У деякий момент часу OLTP 140 може передати (910) файл ініціалізації 310 відправки в LUE 100, і LUE 100 може застосувати файл ініціалізації 310 відправки до віддаленої бази даних 210. OLTP 140 може порівняти локальну базу даних 200 з віддаленою базою даних 210 та ідентифікувати (915) розходження між ними. Потім OLTP 140 може визначити (920), чи є розходження 21 дійсними або помилковими. Потім OLTP 143 може поінформувати LUE 100 для застосування (925) до віддаленої бази даних 210 файлів 300 відправки, відповідно до варіанту здійснення даного винаходу. Потім LUE 100 може застосувати файли 300 відправки до віддаленої бази даних 210. В альтернативному варіанті здійснення система може застосовувати файли відправки та файл ініціалізації відправки до ідентифікації і перевірки достовірності розходжень. У вигляді іншого варіанту система може застосовувати файли відправки та файл ініціалізації відправки після ідентифікації і перевірки достовірності розходжень. Зрозуміло, що процес перевірки достовірності може бути виконаний на будь-яких даних, переданих з джерела в адресат через мережу зв'язку для застосування переданих даних до адресата. На Фіг.10А представлена блок-схема варіанту здійснення перевірки достовірності файлу відправки та файлу ініціалізації відправки, відповідно до даного винаходу. Після передачі у віддалену базу даних декількох періодичних оновлень та оновлення ініціалізації система може перевірити достовірність цих оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій, виконаних у локальній базі даних. Кожна транзакція може містити одну або більшу кількість подій. Подія є дією або можливим здійсненням у базі даних, наприклад, додавання, зміни, видалення і т.д., відносно даних у базі даних. Спочатку система може порівняти (1000) запис у віддаленій базі даних з відповідним записом у локальній базі даних. Система може сформувати (1005) виключення, що описує розходження між записами віддаленої і локальної баз даних, причому виключення може бути сформоване для кожного розходження. Розходженням може бути будь-яка відмінність, щонайменше, в одному значенні даних між двома версіями одного запису. Наприклад, у локальній базі даних може бути запис даних (12345, xyz.com, 123.234.345). Відповідний запис даних у віддаленій базі даних, яка передбачається ідентичною, може відповідати (12345, abc.com, 123.234.345). Відповідно, у другому значенні даних запису є розходження. Отже, варіант здійснення даного винаходу може сформувати виключення, яке описує вказане розходження. Виключення може описувати розходження, просто вказуючи на те, що є розходження; визначаючи місцеположення розходження; описуючи відмінність між двома значеннями даних при розходженні і т.д. Запис даних у локальній базі даних відповідає запису даних у віддаленій базі даних (і навпаки), якщо два записи обов'язково містять ідентичні дані. Зрозуміло, що розходження може відноситися до відмінності в одному або більшій кількості значень даних у записі або до запису загалом. Система може зіставити„ (1010) кожному виключенню ідентифікатор виключення, причому ідентифікатор виключення може відповідати ідентифікатору запису. Наприклад, запис даних 80540 22 (12345, xyz.com, 123.234.345) може мати ідентифікатор d10. Відповідно, ідентифікатором виключення може бути також d10. Кожне виключення може бути класифіковане як таке, що належить будь-якому з декількох видів виключень (або розходжень). Може бути сформований список виключень для включення у нього видів виключень та ідентифікатора виключення для згрупованих там виключень. Список виключень і різні види виключень детально описані нижче. Система також може зіставити (1015) кожній події в оновленні ідентифікатор події, причому ідентифікатор події може відповідати ідентифікатору запису. Наприклад, запис даних (12345, xyz.com, 123.234.345) може мати ідентифікатор d10. Відповідно, ідентифікатором події може бути також d10. Кожна подія в оновленні може бути виявлена з передісторії подій. Передісторією подій може бути лістинг і т.д. подій, виконаних на записах локальної бази даних за деякий період часу. Передісторія подій детально описана нижче. Потім система може визначити (1020), чи є оновлення запису достовірним. На Фіг.10В представлена блок-схема варіанту здійснення визначення перевірки достовірності. Дане визначення може бути здійснене наступним чином. Може бути здійснене порівняння (1022) кожної події з кожним виключенням. Якщо кожне виключення підтверджене (1024) подією, то оновлення може бути визначене (1026), як достовірне, і дане оновлення може бути застосоване до віддаленої бази даних. Інакше, якщо кожне виключення не підтверджене (1024) подією, то оновлення може бути визначене (1028), як недостовірне, і виключення можуть реєструватися як помилки. Виключення може бути підтвердженим, коли ідентифікатору виключення відповідає ідентифікатор події, і відповідні подія відповідає достовірній послідовності подій, що відповідають виду виключення. Достовірні послідовності детально описані нижче. Якщо виключення підтверджене, то система може видалити ідентифікатор виключення зі списку виключень. Підтверджене виключення може вказувати, що розходження є достовірним, наприклад, віддалена база даних ще не одержала оновлення, але при одержанні оновлення дійсно буде· відповідати локальній базі даних. При перевірці достовірності система може ідентифікувати приховані помилки або збої у періодичному оновленні та оновленні ініціалізації. Система може забезпечувати можливість структурної і семантичної коректності даних оновлення, можливість успішного застосування даних оновлення, яке не спричиняє формування виключень або іншої небажаної зупинки, можливість очного виявлення помилок при порівнянні локальної і віддаленої баз даних між собою, і неможливість випадкового видалення значимих даних. Система може забезпечувати можливість успішного застосування до віддаленої бази даних періодичного оновлення та оновлення ініціалізації. 23 Переважно, при перевірці достовірності може бути виявлено багато помилок, що виникають при спробі застосування оновлення до віддаленої бази даних. Наприклад, при спробі застосування можуть виявлятися помилки централізації даних, попередження про те, що об'єкт вже існує у віддаленій базі даних, або попередження про те, що є порушення зовнішнього ідентифікатора. Отже, після виконання процесу перевірки достовірності відповідно до варіанту здійснення даного винаходу, система може зробити спробу застосування вказаних оновлень до віддаленої бази даних. Спроба може бути неуспішною, що може вказувати на наявність в оновленнях додаткових помилок, які роблять оновлення недостовірним. Відповідно, додаткові спроби застосування вказаних оновлень до віддаленої бази даних не можуть бути здійснені. В альтернативному варіанті здійснення до виконання перевірки достовірності може бути зроблена спроба застосувати, щонайменше, одне з оновлень. Якщо спроба є неуспішною, то перевірка достовірності може бути опущена і оновлення відкинуто. З іншого боку, якщо спроба є успішною, то може бути виконана перевірка достовірності, і достовірне оновлення зберігається, а для недостовірного оновлення реєструються розходження. У можливому варіанті здійснення OLTP 140 може здійснювати перевірку достовірності файлів 300 відправки та файлів ініціалізації 310 відправки для забезпечення успішного застосування до віддаленої бази даних 210 файлів 300 відправки та файлів ініціалізації 310 відправки. В альтернативних варіантах здійснення перевірку достовірності можуть виконувати мережні комп'ютери 121, LUE 100 або будь-яка комбінація існуючих систем. Відповідно до Фіг.10А, OLTP 140 може порівняти локальну базу даних 200 і віддалену базу даних 210 для визначення будь-яких виключень (або розходжень) між ними. Виключення можуть включати три види: у віддаленій базі даних 210 можуть існувати дані, які відсутні у локальній базі даних 200; у локальній базі даних 200 можуть існувати дані, які відсутні у віддаленій базі даних 210; або відповідні дані можуть існувати і у локальній базі даних 200, і у віддаленій базі даних 210, але дані можуть відрізнятися. Безумовно, відповідні дані можуть існувати і у локальній базі даних 200, і у віддаленій базі даних 210, і дані можуть бути ідентичними, у цьому випадку дані можуть вважатися достовірними, отже, від OLTP 140 не потрібно ніякої додаткової обробки. Зрозуміло, що розходження може відноситися до однієї або більшої кількості значень даних у записі або до запису загалом. Відповідно, OLTP 140 може порівняти (1000) відповідні записи у лої сальній базі даних 200 і віддаленій базі даних 210. OLTP 140 може сформувати (1005) виключення, яке описує розходження між записом у віддаленій базі даних 210 і записом у локальній базі даних 200, причому виключення може бути сформоване для кожного 80540 24 розходження. OLTP 140 може зіставити (1010) кожному виключенню ідентифікатор виключення, причому ідентифікатор виключення може відповідати ідентифікатору запису. Може бути сформований список виключень для включення видів виключень та ідентифікатора виключення для виключення, що належить до даного виду виключення. У варіанті здійснення виключення може бути визначене, як виключення (або розходження) "Списку 1", якщо виключення належить до першого виду виключень, виключення "Списку 2", якщо виключення належить до другого виду виключень, або виключення "Списку 3", якщо виключення не лежить до третього виду виключень. Фіг.11 ілюструє можливий список 1140 виключень. Зрозуміло, що наявність ідентифікатора виключення у списку виключень не означає, що файл 300 відправки або файл ініціалізації 310 відправки не придатний, оскільки, наприклад, всі три види виключень можуть виникати обґрунтовано через затримку у часі між змінами у локальній базі даних 200 і оновленнями, що застосовуються до віддаленої бази даних 310. Така затримка, наприклад, може бути викликана перевантаженням мережі зв'язку. По суті, перевірка достовірності може забезпечувати механізм для виключення обґрунтованих виключень з помилкових даних. Для файлу ініціалізації 310 відправки, OLTP 140 може порівняти локальну базу даних 200 і віддалену базу даних 210 за допомогою виконання двонаправленого перегляду всіх таблиць в обох базах даних 200, 210. То это, всі дані у локальній базі даних 200 можуть порівнюватися відносно всіх даних у віддаленій базі даних 210. Потім всі дані у віддаленій базі даних 210 можуть порівнюватися відносно всіх даних у локальній базі даних 200. Це, переважно, забезпечує всебічне порівняння баз даних 200,210 для виявлення всіх розходжень. Для файлу 300 відправки OLTP 140 може порівняти тільки ті записи даних у локальній базі даних 200 і віддаленій базі даних 210, які записані у файлі 300 відправки. Це, переважно, забезпечує швидкодіючий запит для виявлення заданих розходжень. В іншому варіанті може бути здійснена випадкова вибірка даних в файлі ініціалізації 310 відправки і/або файлі 300 відправки. Потім OLTP 140 може порівняти дані, вибрані випадковим чином, у локальній базі даних 200 і віддаленій базі даних 210. Список 1140 виключень може відповідати відсутнім подіям, наприклад, додавання (add), зміни (mod) і видалення (del) для локальної бази даних 200, які не узгоджуються з віддаленою базою даних 210. Отже, для ідентифікації таких подій-кандидатів, OLTP 140 може дослідити останні транзакції, фіксовані у локальній базі даних 200. В основному, у таблиці реєстрації, яка зберігається у локальній базі даних 200, може бути сформований елемент для кожної фіксованої транзакції. Елемент може містити ідентифікатор запису, що був змінений, транзакцію (або подію), 25 що змінила запис (наприклад, add, mod і/або del), порядковий номер реєстрації, що вказує черговість транзакції і т.д. Можлива таблиця 1100 реєстрації зображена на Фіг.11. У цьому можливому варіанті файл 300 відправки містить транзакції 1108-1114, зображені у таблиці реєстрації 1100. Перший елемент 1101 вказує, що у першій транзакції 1108 дані (сервера доменних імен) n1 і n2 були додані до даних (домен), що відповідають ідентифікатору d1. Отже, ідентифікатором є d1, подією є додавання "add", a порядковим номером реєстрації є 11526. Аналогічно, другий елемент 1102 вказує, що у другій транзакції 1109 дані n8 і n9 були додані до даних, що відповідають ідентифікатору d2. Третій елемент 1103 вказує, що у третій транзакції 1110 дані, що відповідають ідентифікатору d3, були видалені. Четвертий елемент 1104 вказує, що у четвертій транзакції 1111, дані, що відповідають ідентифікатору d1, були змінені для додавання даних n5. Для п'ятої транзакції 1112 п'ятий елемент 1105 вказує, що дані n6 і n7 були додані до даних, що відповідають ідентифікатору d3. Для шостої транзакції 1113 шостий елемент 1106 вказує, що дані, які відповідають ідентифікатору d4, були змінені для видалення даних n3. Rий елемент 1107 в Rій транзакції 1114 вказує, що дані, які відповідають ідентифікатору d5, були видалені. Відповідно, згідно з Фіг.10А, OLTP 140 може зіставити (1015) кожній події в оновленні ідентифікатор події, причому ідентифікатор події може відповідати ідентифікатору запису. Кожна подія в оновленні може бути знайдена з передісторії подій. Передісторія подій, індексована і впорядкована за ідентифікатором події, може бути сформована з таблиці 1100 реєстрації. Можлива передісторія 1120 подій зображена на Фіг.11. Тут, перший і четвертий елементи 1101, 1104 у таблиці 1100 реєстрації вказують зміни для даних, що відповідають ідентифікатору d1. Отже, передісторія 1120 подій містить ідентифікатор d1 1121 і дві події 1126, додавання "add" і подальшу зміну "mod", виконані на даних, що відповідають ідентифікатору d1. Другий елемент 1102 вказує зміни для даних, що відповідають ідентифікатору d2. Отже, передісторія 1120 подій містить ідентифікатор d2 1122 і подію 1127 додавання "add". Передісторія 1120 подій містить ідентифікатор d3 1123 і діві події 1128, видалення "del" з подальшою зміною "mod", що вказуються третім і п'ятим елементами 1103, 1105, які містять зміни для даних, що відповідають ідентифікатору d3. Шостий елемент 1106 вказує зміни для даних, що відповідають ідентифікатору d4. Відповідно, передісторія 1120 подій містить ідентифікатор d4 1124 і подію 1129 зміни "mod". Rий елемент 1107 вказує зміни для даних, що відповідають ідентифікатору d5, і передісторія 1120 подій містить ідентифікатор d5 1125 і подію 1130 видалення "del". Ідентифікатори 1121-1125 впорядковані з d1 по d5. Відповідно до Фіг.10А, OLTP 140 може визначити (1020), чи є оновлення достовірним. Дане визначення може бути виконане, наприклад, відповідно до варіанту здійснення за Фіг.10В. 80540 26 Спочатку OLTP 140 може порівняти (1022) ідентифікатори 1121-1125 подій з ідентифікаторами 1140 виключень для визначення, які ідентифікатори мають відповідність. Наприклад, відповідно до Фіг.11, ідентифікатор 1121 події d1 у хронології 1120 подій відповідає ідентифікатору виключення d1 у "Списку 2" списку 1140 виключень Після виявлення відповідних події і виключення, OLTP 140 може визначити (1024), чи підтверджене виключення подією. Підтвердження може бути виконане наступним чином. Для кожного ідентифікатора 1121-1125 події у хронології 1120 подій, OLTP 140 може визначити, чи є достовірною кожна послідовність подій 1126-1130 у хронології 1120 подій. Це може бути здійснено, наприклад, шляхом дослідження списку 1140 виключень для того, щоб визначити, до якого виду виключень належить кожний ідентифікатор виключення, визначення, якою повинна бути достовірна послідовність подій для цього виду виключень, і потім по луку у передісторії 1120 подій відповідного ідентифікатора події і послідовності подій для ідентифікатора події. Достовірні послідовності для кожного виду виключень детально описані нижче. Якщо послідовність подій 1126-1130 у хронології 1120 подій відповідає достовірній послідовності, то відповідний ідентифікатор події 1121-1125 має достовірну послідовність. По суті, виключення, що відповідає ідентифікатору виключення, може бути підтверджене. І, відповідна транзакція 1108-1114, що містить вказаний ідентифікатор події, є обґрунтованою, а не помилковою. У цьому випадку OLTP 140 може видалити ідентифікатор виключення зі списку 1140 виключень. Для виду виключень "Списку 1" достовірною послідовністю подій може бути (mod)*(del). Дана послідовність може містити послідовність з нульової або більшої кількості подій зміни "mod", за якими йде подія видалення "del", зa якою йде довільна подія. Вид виключень "Списку 1" може відповідати даним, які можуть існувати у віддаленій базі даних 210, але бути відсутнім у локальній базі даних 200. У цьому випадку дані, можливо, були нещодавно видалені з лекальної бази даних 200 і транзакція ще не була записана у файл 300 відправки. Отже, файл 300 відправки ще не міг бути застосований до віддаленої бази даних 210. Значить, ці дані можуть ще залишатися у віддаленій базі даних 210. Це може вважатися обґрунтованим розходженням, оскільки передбачається, що у деякий момент часу файл 300 відправки буде сформований і застосований до віддаленої бази даних 210. Отже, якщо для ідентифікатора виключення у Списку 1 зі списку 1140 виключень у хронології 1120 подій виявлена будь-яка така послідовність 1126-1130, то відповідна транзакція може вважатися достовірною. Наприклад, відповідно до Фіг.11, ідентифікатор d5 1125 і відповідні йому дані були видалені з локальної бази даних 200, як ілюструє Rий елемент 1114 таблиці 1100 реєстрації і вказує хронологія 1120 подій. Під час перевірки 27 достовірності d5 був видалений з локальної бази даних 200, але не видалений з віддаленої бази даних 210. Отже, список 1140 виключень містить ідентифікатор d5 у Списку 1. Згідно з хронологією 1120 подій, подією 1130, що відповідає ідентифікатору d5 1125, є видалення "del". OLTP 140 може порівняти достовірну послідовність виду виключень "Списку 1", тобто (mod)*(del), з подією d5 1130 у хронології 1120 подій. Оскільки достовірна послідовність "Списку 1" і подія 1130 відповідають, то транзакція 1114 видалення, що відповідає ідентифікатору d5, може вважатися обґрунтованою і не є помилкою. Відповідно, ідентифікатор d5 може бути видалений зі списку 1140 виключень. Достовірною послідовністю подій для виду виключень "Списку 2" може бути (add). Дана послідовність може містити подію додавання "add", за якою йде довільна подія. Вид виключень "Списку 2" може відповідати даним, які існують у локальній базі даних 200, але не існують у віддаленій базі даних 210. У цьому випадку дані могли бути нещодавно додані у локальну базу даних 200, і транзакція ще не була записана у файл 300 відправки. Отже, файл 300 відправки міг бути ще не застосований до віддаленої бази даних 210. Отже, дані можуть не існувати у віддаленій базі даних 210. Це також може вважатися обґрунтованим розходженням, оскільки, очікується, що у деякий момент часу файл 300 відправки буде сформований і застосований до віддаленої бази даних 210. Відповідно, якщо для ідентифікатора виключення у Списку 2 зі списку 1140 виключень виявлена будь-яка така послідовність 1126-1130 у хронології 1120 подій, то відповідна транзакція може вважатися достовірною. Відповідно до Фіг.11, ідентифікатори d1 і d2 1121, 1123 можуть бути зіставлені з даними, які, наприклад, спочатку були додані у локальну базу даних 200. Оскільки послідовності подій 1126, 1127 для них починаються з події додавання "add", то ідентифікатори d1 і d2 1121, 1123 відповідають достовірним послідовностям для виду виключень "Списку 2". Відповідно, транзакції 1108, 1109, що містять вказані ідентифікатори, можуть вважатися достовірними, і ідентифікатори d1 і d2 можуть бути видалені зі списку 1140 виключень. Потрібно зазначити, що ідентифікатор d3 1123 також у своїй послідовності 1128 містить подію додавання «add». Однак, подія додавання «add» не є першою у послідовності 1128. Відповідно, послідовність 1128 не відноситься до виду "Списку 2". Додатково, оскільки d3 не позначений у Списку 2 списку 1140 виключень, то OLTP 140 не може здійснити його перевірку по достовірній послідовності для Списку 2. Достовірними послідовностями подій для виду виключень "Списку 3" можуть бути (del), (add) або (mod). Дані послідовності можуть містити подію видалення "del", за якою йде подія додавання "add", за якою йде довільна подія, або подія зміни "mod", за якою йде довільна подія. Вид виключень "Списку 3" може відповідати даним, які існують в обох базах даних 200, 210, але відмінні. У цьому 80540 28 випадку дані могли бути нещодавно змінені у локальній базі даних 200, і транзакція ще не була записана у файл 300 відправки. Отже, файл 300 відправки ще не міг бути застосований до віддаленої бази даних 210. Отже, дані, що відповідають ідентифікатору, можуть бути ще не змінені у віддаленій базі даних 210. Знову, це може вважатися обґрунтованим розходженням, оскільки очісується, що у деякий момент часу файл 300 відправки буде сформований і застосований до віддаленої бази даних 210. Відповідно, якщо для ідентифікатора виключення у Списку 3 зі списку 1140 виключень виявлена будьяка така послідовність 1126-1130 у хронології 1120 подій, то відповідна транзакція може вважатися достовірною. Наприклад, відповідно до Фіг.11, ідентифікатори d3 і d4 1123, 1124 можуть бути зіставлені з даними, які були змінені у локальній базі даних 200. У випадку ідентифікатора d3 1123, ідентифікатор d3 1123 і його дані спочатку були видалені, а потім додані зворотно з новими даними, так що послідовність подій 1118 може містити видалення "del", за яким йде додавання "add". У випадку ідентифікатора d4 1124, дані d4 були змінені для видалення даних, так що послідовність подій 1129 може містити зміну "mod". Оскільки вказані послідовності подій 1128, 1129 відповідають достовірним послідовностям для виду виключень "Списку 3", то відповідні їм транзакції 1110, 1112, 1113 можуть вважатися достовірними, і ідентифікатори d3 і d4 можуть бути видалені зі списку 1140 виключень. Відповідно до Фіг.10В, якщо всі виключення, позначені у списку 1140 виключень своїми ідентифікаторами, були підтверджені (1024) подіями, наприклад, якщо список 1140 виключень є пустим, то OLTP 140 може визначити (1026) файл 300 відправки або файл ініціалізації 310 відправки, як достовірний, і поінформувати LUE 100 для застосування файлу 300 відправки або файлу ініціалізації 310 відправки до віддаленої бази даних 210. Потім LUE 100 може застосувати файл 300 відправки або файл ініціалізації 310 відправки до віддаленої бази даних 210. І навпаки, якщо всі виключення не були підтверджені (1024) подіями, наприклад, якщо список 1140 виключень не є пустим, то виключення, що залишилися можуть вказувати на помилки у файлі 300 відправки або файлі ініціалізації 310 відправки. Відповідно, OLTP 140 може визначити (1028) файл 300 відправки або файл ініціалізації 310 відправки, як недостовірний, і зареєструвати помилки у файлі помилок. В альтернативному варіанті здійснення, якщо, наприклад, файл 300 відправки або файл ініціалізації 310 відправки був визначений як недостовірний, то після заздалегідь визначеного періоду часу OLTP 140 може повторити процес перевірки достовірності відносно недостовірного файлу 300 відправки або файлу ініціалізації 310 відправки для підтвердження того, що розходження дійсно є помадками. Вказана заздалегідь визначена затримка забезпечує мережі більший час для передачі якого-небудь 29 повільного файлу 300, 310 відправки, і більший час на те, щоб бази даних 200, 210 стали уніфікованими за зчитуванням. У варіанті здійснення даного винаходу дані у віддаленій базі даних 210 можуть "відставати" від даних у локальній базі даних 200 на значний інтервал часу. Відповідно, для порівняння баз даних 200, 210 і для виявлення помилок, бази даних 200, 210 можуть бути зроблені уніфікованими за зчитуванням у той момент часу, коли вони стануть точними копіями одна одної. В основному, віддалена база даних 210 може бути приведена, з повторенням всіх завершених транзакцій, до лекальної бази даних 200, причому дані у віддаленій базі даних 210 можуть бути зроблені по суті ідентичними даним у локальній базі даних 200. Відповідно, для прискорення перевірки достовірності, будь-який сформований у поточний час файл ініціалізації 310 відправки і наступні файли 300 відправки можуть бути застосовані до віддаленої бази даних 210 до початку перевірки достовірності. По суті, кількість розходжень може бути істотно зменшена. Така пакетна обробка файлів 300, 310 відправки може бути визначена як утворення блоків. Перший і останній з цих файлів 300, 310 відправки у блоці може бути названий нижнім і верхнім «водяним знаком» відповідно. Перший блок, що називається початковим блоком, може містити файл ініціалізації 310 відправки. Всі наступні блоки, що називаються кінцевими блоками, можуть містити тільки файли 300 відправки. Утворення блоків може забезпечувати перевірку достовірності групи замість перевірки достовірності окремо. Відповідно, при виявленні у блоці помилки, недостовірним може бути позначений весь блок, а не тільки файл 300 відправки або файл ініціалізації 310 відправки, де виникла помилка. Механізми і способи, що відповідають варіантам здійснення даного винаходу, можуть бути реалізовані з використанням універсального мікропроцесора, запрограмованого згідно з варіантами здійснення винаходу. Отже, варіанти здійснення даного винаходу також включають носій інформації, що зчитується комп'ютером, який може містити інструкції, що можуть використовуватися для програмування процесора для виконання способу, який відповідає варіантам здійснення даного винаходу. Вказаний носій може включати в себе будь-який вид диска, включаючи гнучкий диск, оптичний диск, компакт-диски CDROM і т.д. Вище детально описано і проілюстровано декілька варіантів здійснення даного винаходу. Однак, має бути очевидно, що без відхилення від суті об'єму даного винаходу можуть бути здійснені зміни і модифікації винаходу, що охоплюються наведеним вище описом і доданою формулою винаходу. 80540 30 31 80540 32 33 80540 34
ДивитисяДодаткова інформація
Назва патенту англійськоюMethod, system, device, and information carrier for validating remote database updates; method for validating records in a remote database and data transmission over a communication system
Автори англійськоюBelow Aristotel Nicolas, McMillen Bredley Thomas
Назва патенту російськоюСпособ, система, устройство и носитель информации для проверки правильности обновления удаленной базы данных; способ проверки правильности записей в удаленной базе данных и правильности передачи данных через систему связи
Автори російськоюБелоу Аристотель Николас, Макмиллен Бредли Томас
МПК / Мітки
МПК: G06F 1/00, G06F 7/00, G06F 17/30, G06F 12/00, G06F 17/00, G06F 9/46, G06F 15/00
Мітки: передачі, система, запису, пристрій, віддаленої, віддаленій, перевірки, даних, інформації, носій, спосіб, оновлення, достовірності, базі
Код посилання
<a href="https://ua.patents.su/17-80540-sposib-sistema-pristrijj-ta-nosijj-informaci-dlya-perevirki-dostovirnosti-onovlennya-dlya-zapisu-u-viddalenijj-bazi-danikh-sposib-perevirki-dostovirnosti-viddaleno-bazi-danikh-i-do.html" target="_blank" rel="follow" title="База патентів України">Спосіб, система, пристрій та носій інформації для перевірки достовірності оновлення для запису у віддаленій базі даних, спосіб перевірки достовірності віддаленої бази даних і достовірності передачі даних через</a>
Спосіб і система для оновлення віддаленої бази даних (варіанти)
Номер патенту: 79943
Опубліковано: 10.08.2007
Автори: Белоу Арістотель Ніколас, МакМіллен Бредлі Томас, Хауорт Уілльям Фредерік, мол.
МПК: G06F 7/00, G06F 17/00, G06F 15/00, G06F 9/46, G06F 1/00, G06F 12/00, G06F 17/30
Мітки: віддаленої, оновлення, варіанти, система, спосіб, даних, базі
Формула / Реферат:
1. Спосіб оновлення віддаленої бази даних через мережу, що включає:формування множини періодичних оновлень, що базуються на інкрементних змінах у локальній базі даних, причому кожне з множини періодичних оновлень містить щонайменше одну транзакцію,передачу множини періодичних оновлень у віддалену базу даних через мережу,при цьому при формуванні множини періодичних оновленьвиконують: формування ініціалізуючого оновлення,...
Система і спосіб синхронізації і організації бази даних
Номер патенту: 65638
Опубліковано: 15.04.2004
Автори: Макгеф Френк Х., Малік Сенджой, Аммар Мустафа Х., Нават Шамкант Б., Махаджан Самір Р., Донаху Майкл Дж.
МПК: G06F 17/30, G06F 12/00
Мітки: система, спосіб, даних, організації, синхронізації, базі
Формула / Реферат:
1. Спосіб оновлення баз даних у комп'ютері клієнта, який відрізняється тим, що включає групування даних у базі даних сервера згідно з вибраними критеріями, призначення доступу до однієї або більше груп для певного комп'ютера клієнта, запис змін даних кожної з груп у відповідний файл модифікації, передачу до комп'ютерної системи клієнта, що має локальну базу даних, файла модифікації, який містить вибрану частину даних від принаймні однієї з...
Оптично зчитуваний носій запису, спосіб та пристрій для виготовлення такого носія запису, пристрій для запису інформації на такий носій запису та пристрій для зчитування інформації з такого носія запису
Номер патенту: 39846
Опубліковано: 16.07.2001
Автори: Пасман Йоханнес Херманус Теодорус, Мюлдер Хендрікус Антоніус Марія, Раймакерс Вільхельмус Петрус Марія, Веніс Арте Віллеміна, Кейперс Франціскус Ламбертус Йоханнус Марія
МПК: G11B 7/007
Мітки: пристрій, такого, інформації, носій, запису, носія, спосіб, зчитування, оптично, виготовлення, зчитуваний
Формула / Реферат:
1. Оптически считываемый носитель записи, содержащий чувствительный к излучению слой записи информации на подложке, имеющей форму диска, снабженной непрерывной дорожкой постоянной ширины, организованной в соответствии со спиральной или концентрической структурой дорожки, для записи вдоль нее информации с в существенной степени постоянной линейной скоростью, причем упомянутая дорожка выполнена в виде периодического радиального...
Спосіб підтримки передачі пакетних даних і передачі даних з низькою затримкою через множину каналів у системі безпровідного зв’язку, а також пристрій прийому пакетних даних через щонайменше один канал першого н
Номер патенту: 75612
Опубліковано: 15.05.2006
Автори: Бао Ґанґ, Разумов Леонід, Ландбі Стайн А.
МПК: H04Q 7/38, H04L 12/56
Мітки: підтримки, щонайменше, пристрій, множину, пакетних, даних, безпровідного, прийому, каналів, зв'язку, передачі, спосіб, системі, канал, затримкою, також, низькою, першого
Формула / Реферат:
1. Спосіб підтримки передачі пакетних даних і передачі даних з низькою затримкою через множину каналів передачі у системі безпровідного зв'язку, який включає:- передачу пакетних даних через набір каналів пакетних даних, - передачу керуючої інформації, пов'язаної з цими пакетними даними через канал сигналізації, причому канал сигналізації відокремлений від набору каналів передачі пакетних даних, і керуюча інформація ідентифікує...
Спосіб передачі інформації з використанням носія даних, носій інформації і пристрій для відтворення інформації з такого носія
Номер патенту: 26980
Опубліковано: 28.02.2000
Автор: Блютген Бйорн
МПК: G11B 20/10, H04N 5/76, G11B 7/24
Мітки: відтворення, даних, інформації, такого, передачі, пристрій, носія, використанням, носій, спосіб
Формула / Реферат:
1. Способ передачи информации с использованием носителя данных, заключающийся в форматировании данных с добавлением к основной информации цифровых субкодовых данных, записи полученной информации на носителе данных с образцами участков, имеющими различные физические свойства и представляющими основную и субкодовую информацию, считывании носителя записи с преобразованием образцов участков носителя в сигнал, изменения физической величины...
Попередній патент: З’єднувальний елемент, вузол з’єднання з таким з`єднувальним елементом, а також карман для нього
Наступний патент: Провід, переважно для перемичок та рейкових з’єднувачів (варіанти)
Випадковий патент: Польова гоніометрична система