|
|
|
MobiLink, проблема большого download потока
|
|||
|---|---|---|---|
|
#18+
Некоторые вводные данные: 1. MobiLink синхронизация, 5 БД ASA9 БД1 - консалидированная БД БД2 - удаленная, содежит данные БД3 - БД5 БД3,БД4,БД5 - удаленные БД 2. MLServer работает с Isolation_Level = 1 3. Структура БД одиноковая и содержит 2 таблицы, "A" и "B", у "B" есть внешний ключ на "A". 4. Синхронизация по timestamp полю (last_updated >= <last_updated>) Т.к. БД2 содержит много данных, то и процесс построения download потока для нее занимает больше времени чем для остальных. Допустим что во время выполнения запроса из таблицы "A" для download потока БД2, удачно завершилась синхронизация БД3, при этом были добавлены строки в таблицы "A" и "B". Курсор из таблицы "A" для download потока БД2, не будет содержать этих данных, а вот Курсор из таблицы "B" для download потока БД2 уже да (транзакция заверщена). Но такие изменения на БД2 не применятся, по причине что некоторых строк из "B" нет строк из "A". Вопрос, как можно такое исправить ? У меня есть 2 идеи: 1. сделать условие не last_updated >= <last_updated>, а last_updated between <last_updated> and <current_updated> 2. синхронизировать БД2 в отдельное время от остальных БД Если кто-то разбирался с этим в ML, подскажите. Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2008, 14:34 |
|
||
|
MobiLink, проблема большого download потока
|
|||
|---|---|---|---|
|
#18+
Чего-то я так и не понял, на чем ты застрял. Что именно ты хочешь исправлять? .... А! Кажется я догадался: Для ML репликации таблицы должны иметь два default timestamp поля. Одно поле (включенное в репликацию) для даты реального обновления полей. Естественно первое поле можно и выбросить. Второе (не реплицируемое) только для нужд ML, вот по нему и включаешь выборку. Но главное в том, что то last_updated поле по которому делается синхронизация само на удаленную базу уезжать не должно. Оно будет заполненно на удаленной базе через default и будет хранить дату реального появления данных в базе, иными словами дату синхронизации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2008, 18:10 |
|
||
|
MobiLink, проблема большого download потока
|
|||
|---|---|---|---|
|
#18+
Странно, что не воспользовались SQL Remote для таких целей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2008, 22:19 |
|
||
|
MobiLink, проблема большого download потока
|
|||
|---|---|---|---|
|
#18+
Анатолий ИвановСтранно, что не воспользовались SQL Remote для таких целей. dbRemote тоже работает :), но для большого количества удаленных БД это не вариант, имхо. Не умею я объснять, попробую дома еще раз все продумать и описать понятнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2008, 11:56 |
|
||
|
MobiLink, проблема большого download потока
|
|||
|---|---|---|---|
|
#18+
В плане идеи могу предложить модифицированный вариант 1 1. сделать условие не last_updated >= <last_updated>, а last_updated between <last_updated> and @g_session_started где @g_session_started - глобальная переменная сессии, которую надо создать и присвоить ей значение в begin_connection скрипте уровня соединения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2008, 21:11 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=44&tid=2011298]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 234ms |
| total: | 380ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...