|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
MikeDD, ну да, так и собирался делать... а вы предлагаете создать таблицу логов со структурой (имя_таблицы, имя_поля, тип_поля, значение)? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2018, 14:38 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, по вашему примеру хотел сделать http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=843731&msg=10516083 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2018, 14:40 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
aidynchikпо вашему примеру хотел сделать "Мопед не мой." Мой мопед не имеет проблем с блобами. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2018, 15:55 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, я просто взял его для примера... а как тогда? переделывать его в base64? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2018, 06:48 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
aidynchikа как тогда? переделывать его в base64? признаться, что задача тебе не по зубам и использовать готовые продукты. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2018, 12:20 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Стояла когда-то такая задача. Или подобная. Большое кол-во объектов. Уровней объектов доходило до 6. И с каждого объекта нужно было отправлять инфу очень хитро. 1.Часть инфы должна была идти на верхний уровень, часть на нижний, часть - на свой уровень, а еще некоторая инфа должна была попадать на нижний уровень через верхний. 2.Часть инфы должна была рассылаться по условиям согласно п.1 Т.е. очень хитрая репликация. 3. Проблему с уникальностью первичных ключей решили следующим образом. Каждый объект автоматизации имел свой уникальный ID, который генерился на головном серваке. Первичный ключ состоял из ID объекта, даты создания ключа и значения циклической последовательности для данной таблицы. Все это делалось на ORACLE. В нем в NUMBER влазило 24 цифирьки. Дату обрезали до часов. т.е. имели ID типа IIIIYYYYMMDDHHХХХХХХХХХХХХ. 4.Пробовали работать с GUID. Но в патчах ORACLE постоянно видели что GUID ихний имеет свойство повторяться и исправления по нему. 5. Такая система идентификации первичных ключей позволяла даже безболезненно восстанавливать упавшие объекты с верхнего уровня. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2018, 15:31 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
06.09.2018 15:31, bsa1959 пишет: > т.е. имели ID типа IIIIYYYYMMDDHHХХХХХХХХХХХХ. не на много лучше составных ключей Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2018, 15:36 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Мимопроходящийне на много лучше составных ключей Я ж конечно не гуру в SQL. Но такой подход позволил решить огромное кол-во задач. Стандартная репликация ORACLE всего этого делать не могла. Или мы не смогли ей воспользоваться под свои нужды...... В том числе и рассылкой инфы по объектам как Бог на душу положит. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2018, 15:45 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
bsa19594.Пробовали работать с GUID. Но в патчах ORACLE постоянно видели что GUID ихний имеет свойство повторяться и исправления по нему. надеюсь, в FB такой засады нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2018, 17:56 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Докнадеюсь, в FB такой засады нет? Это вопрос,скорее к разработчикам. Проверяется очень легко. Создаешь таблицу с первичным ключом GUID и запускаешь вставку записей на несколько дней..... У нас через 2-3 дня выскакивало нарушение уникальности..... Поприменяли патчи ORACLE, вроде все хорошо. А после загрузки другого патча или переходе на след.версию могло все повториться. Поэтму бросили мысли про GUID. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2018, 07:49 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Кстати... Тоже самое было у ORACLE с двухфазным commit через DBLINK. На плохих каналах связи или при пропадании канала этот двухфазный COMMIT уходил в такие дебри, что для восстановления обмена приходилось лезть глубоко внутрь системных таблиц. И на одной и второй БД, участвующих в обмене. Патчи помогали, но через какое-то время все могло вернуться. Мы все время грешили на индусов - разработчиков........ ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2018, 08:10 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
bsa1959Поприменяли патчи ORACLE, вроде все хорошо. А после загрузки другого патча или переходе на след.версию могло все повториться. Поэтму бросили мысли про GUID. Прелесть GUID же в том, что его можно генерить прямо на клиентах, не грузя лишний раз сервер. UuidCreateSequentional() - сильная вещь в винде, за линухи не скажу. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2018, 13:47 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
bsa1959Докнадеюсь, в FB такой засады нет? Это вопрос,скорее к разработчикам. в надежде на них и спросил ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2018, 16:18 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Как видно, под виндой засады нет, под линухом все вопросы к /dev/urandom. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2018, 17:12 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovКак видно, под виндой засады нет, под линухом все вопросы к /dev/urandom. Сервак у нас как раз под линухом был..... О как все через много лет прояснилось..... А ответ конечно великолепный. Типа - мопед не мой. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2018, 09:53 |
|
Синхронизация (репликация) БД Firebird
|
|||
---|---|---|---|
#18+
в общем я сделал так: 1. Добавил в таблицу логирования столбец DAT с типом BLOB 2. На таблицы с blob-полями навесил отдельные триггеры, изменения по BLOB-полям вставляются в таблицу логов отдельной записью. 3. При синхронизации на передатчике делаю селект из таблицы логов в Dataset 4. Сохраня Dataset в файл 5. На приемнике восстанавливаю датасет из файла 6. Пробегаюсь по датасету и вставляю все в таблицу логов приемника, а потом уже прогоняю sql-выражения. Таким боком не надо ничего придумывать с BLOB-полями, они передаются как есть. Возможно это колхоз, но работает ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2018, 07:10 |
|
|
start [/forum/topic.php?fid=40&msg=39699115&tid=1560987]: |
0ms |
get settings: |
8ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
63ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 151ms |
0 / 0 |