iBase.ru Forum

Есть БД FB 1.5.3 SS Windows XP,2000.
Необходимо создать и поддерживать в автоматичсеком естественно режиме архивную копию. Это должна быть точная копия оперативной, но данные за какой-то временной период(в зависимости от настроек, например с давностью от 3 мес.до 5 лет).
Пополнение архива думаю лучше сделать с частотой, допустим 1 раз в сутки.
Вопрос в том, как это лучше реализовать? БД имеет несколько сотен таблиц и т.д. Производить процесс создания и контроля копии будет отдельное приложение, не то, которое работает с БД.
У Вас здесь прежполагаю, достаточно материала, чтобы решить самомму этот вопрос, но сейчас у меня этот вопрос имеет маленький лимит времени. Есть ли идеи как это лучше организовать? В архивную БД не должны попадать данные меньше нижнего временного диапазона, в свою очередь в оперативной БД при архивировании данных должна производиться чистка данных, скопированных в архивную копию.
То есть архивная БД должна иметь такую же структуру но данные, зависимые от даты будут иметь временно диапазон указанный выше, в оперативной БД соответственно данные с датой этого диапазона после копирования должны удаляться.

Поддерживать архивную достаточно просто - односторонняя репликация.
А вот поддерживать оперативную... Вот тут Ж.
Подумай на выходных, есть ли у тебя агрегатные данные и как они пересчитываются, есть ли другие какие-нибудь алгоритмы (не отчёты, их можно и в архивной делать), использующие данные документов за значительный период.
Удаление данных - отдельная песня. Тупо резать по дате можно, пожалуй, только логи. Остальные документы удалять можно, как правило, только "связками" по зависимостям между ними, иначе оставленные "огрызки" могут нарушить логическую структуру базы. Особенно это касается связанных отношениями многие-ко-многим документов, таких как накладная/платёж и т.д.

Хорошо, ответить смогу во вторник, до вторника не будет возможности.
Спасибо!

WildSery писал(а):Поддерживать архивную достаточно просто - односторонняя репликация.

Не-а. Нормальным людям она бы, конечно, помогла, но автор-то хочет чтобы данные не дублировались. Вот если это ограничение снять, тогда действительно: любой репликатор + свой скрипт по удалению данных из оперативной БД. А так только заказная софтина.

Dimitry Sibiryakov писал(а):Не-а. Нормальным людям она бы, конечно, помогла, но автор-то хочет чтобы данные не дублировались.

Таких требований автор вроде не выдвигал.
Кстати, подумалось, что бредовая вообще-то идея, хранить в архивной не всё, а только то, что убито в оперативной. Отчёты тогда где ваще выполнять?

А следующей хотелкой будут гетерогенные запросы. Фигли думать, трясти надо. И база поди немеряных размеров - мегабайт аж под 200.

База около 10 Гб.
Хотелка это не моя, просто есть такая задача - осуществить с помощью отдельной программы поддрежание архивной копии с данными имеющими определенную давность, в определенном диапазоне времени, в оперативной базе эти данные после добавления в архивную должны вычищаться. В архивной в свою очередь будут вычищаться данный выходящие за диапазон времени хранения.
К примеру, если давность архива установлена 3 мес.-5 лет,
то в оперативной БД сразу после процесса архивирования последних данных должны остаться данные до 3 мес. А в архивной после 3-х месяцев, но до 5 лет.
Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере. Бэкапы будут производиться и к оперативной и к архивной БД(вопрос Бэкапов разбирать не нужно).

Подумай на выходных, есть ли у тебя агрегатные данные и как они пересчитываются, есть ли другие какие-нибудь алгоритмы (не отчёты, их можно и в архивной делать), использующие данные документов за значительный период.
Удаление данных - отдельная песня. Тупо резать по дате можно, пожалуй, только логи. Остальные документы удалять можно, как правило, только "связками" по зависимостям между ними, иначе оставленные "огрызки" могут нарушить логическую структуру базы. Особенно это касается связанных отношениями многие-ко-многим документов, таких как накладная/платёж и т.д.

Только начинаю изучать логику программы, могу только сказать, "агрегатные данные" есть и алгоритмы безусловно, использующие данные за значительный период, но точно известно то, что данных, которые должны остаться в оперативной БД будет для этого достаточно.
Связи все известны и их можно отследить и учесть притсоздании архивной копии.
Вопрос состоит концепции. Как лучше реализовать ЭТО?
С уважением.

При этом предполагаеться учитывать, что данные архивной БД могут служить не только для просмотра, но и для изменения, хоть и очень редкого... вкаких-то случаях это может быть принципиально.

изменения в архивной БД синхронизировать с оперативной не нужно.

При этом архивная копия содержит данные только одной БД (на этом же сервере)

[предупреждение - Вы можете редактировать свои сообщения. плодить новые на каждое предложение не нужно.]

Если начальство велит занимаццо фигней, и веление сие непреодолимо, то концепция состоит в следующем - садимся за комп и пишем программу, эту фигню реализующую.

Nat писал(а):Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере.

Ты не понял вопроса.
Для корректности отчётов, захватывающих период больше чем сейчас в оперативной базе, или вообще "сквозных" по всем данным, в архивной тебе нужно хранить не только то, что нет в оперативной, но и данные самой оперативной.
Т.е. "архивная" = "старые данные" + "оперативная" - "самые свежие изменения оперативной"

WildSery писал(а):

Nat писал(а):Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере.

Ты не понял вопроса.
Для корректности отчётов, захватывающих период больше чем сейчас в оперативной базе, или вообще "сквозных" по всем данным, в архивной тебе нужно хранить не только то, что нет в оперативной, но и данные самой оперативной.
Т.е. "архивная" = "старые данные" + "оперативная" - "самые свежие изменения оперативной"

Уточнил вопрос, действительно я не понял задачи, уважаемый WildSery прав, нужно именно это. На самом деле это значительно упрощпет мою задачу, и если я правильно понимаю, здесь уже достаточно односторонней репликации. Только в чем смысл такой архивной копии, только в оптимизации работы с оперативной?

А только в этом и смысл. Особенно когда архивная на другом сервере.
Оперативная чтобы быстро работала и быстро восстанавливалась в случае сбоя, благодаря небольшому сравнительно объёму.
Архивная - для отчётности, скорость там особо не нужна, работе оперативной не мешает, из-за небольшой и только отчётной нагрузки практически не падает от каких-нибудь сбоев.
Можно и ещё придумать аргументы.

Кроме того, стоит подумать (со временем), чтобы архивная база вообще была на другой платформе (например, кубы вертеть чтобы).

Опять же, всё зависит от объёмов и характера нагрузки.

Спасибо! Теперь мне логически все понятно, займусь реализацией.

А чего там реализовывать-то? В IBReplicator-е 2.5 есть все, что тебе нужно. Репликацию удалений отключаешь и все.

Dimitry Sibiryakov писал(а):Репликацию удалений отключаешь и все.

Это почему? Не работает что ли?

WildSery писал(а):

Dimitry Sibiryakov писал(а):Репликацию удалений отключаешь и все.

Это почему? Не работает что ли?

Ему же нужно иметь в архивной БД те записи, что удалены из оперативной. Хотя, если у него в базе удаление - нормальная операция, то можно и не отключать. Только придется чистить оперативную БД под специальным пользователем, чтобы эта зачистка не реплицировалась.

Dimitry Sibiryakov писал(а):Только придется чистить оперативную БД под специальным пользователем, чтобы эта зачистка не реплицировалась.

У меня это пользователь "Archivator"
Кроме того, "зачистка" не бесследная, в специальной таблице ведётся учёт id-шников таких документов, во избежание недоразумений, а также чтобы архивная база "знала", каких документов нет в оперативной.