Архивная копия

Модераторы: kdv, CyberMax

Ответить
Nat
Сообщения: 37
Зарегистрирован: 20 авг 2007, 17:23

Архивная копия

Сообщение Nat » 24 авг 2007, 11:46

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

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 24 авг 2007, 12:40

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

Nat
Сообщения: 37
Зарегистрирован: 20 авг 2007, 17:23

Сообщение Nat » 24 авг 2007, 12:53

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

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 24 авг 2007, 13:13

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

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 24 авг 2007, 14:01

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

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 24 авг 2007, 14:33

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

Nat
Сообщения: 37
Зарегистрирован: 20 авг 2007, 17:23

Архивная копия

Сообщение Nat » 28 авг 2007, 10:26

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

Nat
Сообщения: 37
Зарегистрирован: 20 авг 2007, 17:23

Сообщение Nat » 28 авг 2007, 10:54

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

Nat
Сообщения: 37
Зарегистрирован: 20 авг 2007, 17:23

Сообщение Nat » 28 авг 2007, 11:39

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

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

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

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

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 28 авг 2007, 12:53

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

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Re: Архивная копия

Сообщение WildSery » 28 авг 2007, 14:03

Nat писал(а):Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере.
Ты не понял вопроса.
Для корректности отчётов, захватывающих период больше чем сейчас в оперативной базе, или вообще "сквозных" по всем данным, в архивной тебе нужно хранить не только то, что нет в оперативной, но и данные самой оперативной.
Т.е. "архивная" = "старые данные" + "оперативная" - "самые свежие изменения оперативной"

Nat
Сообщения: 37
Зарегистрирован: 20 авг 2007, 17:23

Re: Архивная копия

Сообщение Nat » 28 авг 2007, 14:28

WildSery писал(а):
Nat писал(а):Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере.
Ты не понял вопроса.
Для корректности отчётов, захватывающих период больше чем сейчас в оперативной базе, или вообще "сквозных" по всем данным, в архивной тебе нужно хранить не только то, что нет в оперативной, но и данные самой оперативной.
Т.е. "архивная" = "старые данные" + "оперативная" - "самые свежие изменения оперативной"
Уточнил вопрос, действительно я не понял задачи, уважаемый WildSery прав, нужно именно это. На самом деле это значительно упрощпет мою задачу, и если я правильно понимаю, здесь уже достаточно односторонней репликации. Только в чем смысл такой архивной копии, только в оптимизации работы с оперативной?

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 28 авг 2007, 14:48

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

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

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

Nat
Сообщения: 37
Зарегистрирован: 20 авг 2007, 17:23

Сообщение Nat » 28 авг 2007, 14:54

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

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 28 авг 2007, 16:17

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

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 28 авг 2007, 20:02

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

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 29 авг 2007, 07:52

WildSery писал(а):
Dimitry Sibiryakov писал(а):Репликацию удалений отключаешь и все.
Это почему? Не работает что ли?
Ему же нужно иметь в архивной БД те записи, что удалены из оперативной. Хотя, если у него в базе удаление - нормальная операция, то можно и не отключать. Только придется чистить оперативную БД под специальным пользователем, чтобы эта зачистка не реплицировалась.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 29 авг 2007, 11:03

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

Ответить