НЕ-сетевой обмен данными между двумя БД

← →
mio (2002-12-03 14:11) [0]

Граждане! Дано: два IB-сервера с одинаковыми по структуре базами. Найти: методику переноса данных с одного на другой ПРИ ПОМОЩИ ФАЙЛОВОГО ОБМЕНА. Сетевой MIDAS с соединениями через DCOM, сокеты и вообще через сеть заказчика не удовлетворяет. Перенос всей БД в виде GBD-файла не удовлетворяет меня.

← →
Наталия (2002-12-03 14:20) [1]

www.ibase.ru
ищи по слову "репликация"

← →
Prooksius (2002-12-03 14:20) [2]

Полезно почитать это:
http://www.ibase.ru/develop.htm
Раздел Репликация
Можно, к примеру, генерировать скрипт для обновления базы и запускать на сервере со старой базой.

← →
kaif (2002-12-03 14:41) [3]

Можно делать Backup, перенос файла и Restore (база сильно сжимается при этом). Однако это только если база переносится целиком.

← →
asmith (2002-12-03 16:13) [4]

Можно организовать такую схему:
1.Source-сервер автоматически протоколирует все изменения данных в базе в виде специального лога - в нашей реализации лог формировали треггера и писали его в отдельную таблицу
2.Приложение-publisher по расписанию соединяется с Source-сервером, считывает лог и формирует XML-посылку, содержащую в себе все измененные записи из разных таблиц (XML хорош тем, что может хранить иерархические данные, т.е. с подчиненными таблицами; кроме того он самодокументируем) - в нашей реализации publisher построен как системный сервис
3.Далее посылка транспортируется тем или иным путем к приложению-subscriber-у (подписчику) или даже нескольким (publisher ведет список адресатов и методов отсылки) - мы реализовали для себя 2 вида транспорта - удаленная репликация по HTTP протоколу и локальная в пределах локальной сети.
4.В любом случае XML-посылка падает в заданный фолдер файловой системы подписчика, подписчик является системным сервисом, мониторящим изменение содержимого этого фолдера
5.Зафиксировав изменения, подписчик выбирает последовательно полученные посылки, парсит их и формирует SQL-пакет для выполнения его на Target-сервере.
Для обеспечения надежности работы все операции следует также протоколировать, обеспечивая возможность повторной публикации при неудаче предыдущей попытки. Можно использовать другой транспорт - приносить файлы на место и просто кидать их подписчику, посылать мылом с автоматическим извлечением присоединенных XML-посылок и опять таки их киданием подписчику.

← →
mio (2002-12-06 11:47) [5]

М-да...
Собственно, логические проблемы репликации меня НЕ интересуют.
Я всего лишь хотел спросить про метод, которым можно быстренько залить данные из БД в xml или в текстовый файл, или в любой двоичный, а потом восстановить из него. Причем хорошо бы, чтобы метод не был привязан к стркутуре сннкретных таблиц, ибо структура БД будет еще у меня меняться...

← →
Наталия (2002-12-06 11:53) [6]

← →
asmith (2002-12-06 14:01) [7]

В сети есть куча примеров генерации xml (или в текстового файла) по схеме набора данных, так что никакой привязки к структуре. Еще проще экспорт в CSV-файл.

НЕ-сетевой обмен данными между двумя БД Найти похожие ветки