Архивная копия
Архивная копия
Есть БД FB 1.5.3 SS Windows XP,2000.
Необходимо создать и поддерживать в автоматичсеком естественно режиме архивную копию. Это должна быть точная копия оперативной, но данные за какой-то временной период(в зависимости от настроек, например с давностью от 3 мес.до 5 лет).
Пополнение архива думаю лучше сделать с частотой, допустим 1 раз в сутки.
Вопрос в том, как это лучше реализовать? БД имеет несколько сотен таблиц и т.д. Производить процесс создания и контроля копии будет отдельное приложение, не то, которое работает с БД.
У Вас здесь прежполагаю, достаточно материала, чтобы решить самомму этот вопрос, но сейчас у меня этот вопрос имеет маленький лимит времени. Есть ли идеи как это лучше организовать? В архивную БД не должны попадать данные меньше нижнего временного диапазона, в свою очередь в оперативной БД при архивировании данных должна производиться чистка данных, скопированных в архивную копию.
То есть архивная БД должна иметь такую же структуру но данные, зависимые от даты будут иметь временно диапазон указанный выше, в оперативной БД соответственно данные с датой этого диапазона после копирования должны удаляться.
Необходимо создать и поддерживать в автоматичсеком естественно режиме архивную копию. Это должна быть точная копия оперативной, но данные за какой-то временной период(в зависимости от настроек, например с давностью от 3 мес.до 5 лет).
Пополнение архива думаю лучше сделать с частотой, допустим 1 раз в сутки.
Вопрос в том, как это лучше реализовать? БД имеет несколько сотен таблиц и т.д. Производить процесс создания и контроля копии будет отдельное приложение, не то, которое работает с БД.
У Вас здесь прежполагаю, достаточно материала, чтобы решить самомму этот вопрос, но сейчас у меня этот вопрос имеет маленький лимит времени. Есть ли идеи как это лучше организовать? В архивную БД не должны попадать данные меньше нижнего временного диапазона, в свою очередь в оперативной БД при архивировании данных должна производиться чистка данных, скопированных в архивную копию.
То есть архивная БД должна иметь такую же структуру но данные, зависимые от даты будут иметь временно диапазон указанный выше, в оперативной БД соответственно данные с датой этого диапазона после копирования должны удаляться.
Поддерживать архивную достаточно просто - односторонняя репликация.
А вот поддерживать оперативную... Вот тут Ж.
Подумай на выходных, есть ли у тебя агрегатные данные и как они пересчитываются, есть ли другие какие-нибудь алгоритмы (не отчёты, их можно и в архивной делать), использующие данные документов за значительный период.
Удаление данных - отдельная песня. Тупо резать по дате можно, пожалуй, только логи. Остальные документы удалять можно, как правило, только "связками" по зависимостям между ними, иначе оставленные "огрызки" могут нарушить логическую структуру базы. Особенно это касается связанных отношениями многие-ко-многим документов, таких как накладная/платёж и т.д.
А вот поддерживать оперативную... Вот тут Ж.
Подумай на выходных, есть ли у тебя агрегатные данные и как они пересчитываются, есть ли другие какие-нибудь алгоритмы (не отчёты, их можно и в архивной делать), использующие данные документов за значительный период.
Удаление данных - отдельная песня. Тупо резать по дате можно, пожалуй, только логи. Остальные документы удалять можно, как правило, только "связками" по зависимостям между ними, иначе оставленные "огрызки" могут нарушить логическую структуру базы. Особенно это касается связанных отношениями многие-ко-многим документов, таких как накладная/платёж и т.д.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Не-а. Нормальным людям она бы, конечно, помогла, но автор-то хочет чтобы данные не дублировались. Вот если это ограничение снять, тогда действительно: любой репликатор + свой скрипт по удалению данных из оперативной БД. А так только заказная софтина.WildSery писал(а):Поддерживать архивную достаточно просто - односторонняя репликация.
Таких требований автор вроде не выдвигал.Dimitry Sibiryakov писал(а):Не-а. Нормальным людям она бы, конечно, помогла, но автор-то хочет чтобы данные не дублировались.
Кстати, подумалось, что бредовая вообще-то идея, хранить в архивной не всё, а только то, что убито в оперативной. Отчёты тогда где ваще выполнять?
Архивная копия
База около 10 Гб.
Хотелка это не моя, просто есть такая задача - осуществить с помощью отдельной программы поддрежание архивной копии с данными имеющими определенную давность, в определенном диапазоне времени, в оперативной базе эти данные после добавления в архивную должны вычищаться. В архивной в свою очередь будут вычищаться данный выходящие за диапазон времени хранения.
К примеру, если давность архива установлена 3 мес.-5 лет,
то в оперативной БД сразу после процесса архивирования последних данных должны остаться данные до 3 мес. А в архивной после 3-х месяцев, но до 5 лет.
Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере. Бэкапы будут производиться и к оперативной и к архивной БД(вопрос Бэкапов разбирать не нужно).
Хотелка это не моя, просто есть такая задача - осуществить с помощью отдельной программы поддрежание архивной копии с данными имеющими определенную давность, в определенном диапазоне времени, в оперативной базе эти данные после добавления в архивную должны вычищаться. В архивной в свою очередь будут вычищаться данный выходящие за диапазон времени хранения.
К примеру, если давность архива установлена 3 мес.-5 лет,
то в оперативной БД сразу после процесса архивирования последних данных должны остаться данные до 3 мес. А в архивной после 3-х месяцев, но до 5 лет.
Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере. Бэкапы будут производиться и к оперативной и к архивной БД(вопрос Бэкапов разбирать не нужно).
Только начинаю изучать логику программы, могу только сказать, "агрегатные данные" есть и алгоритмы безусловно, использующие данные за значительный период, но точно известно то, что данных, которые должны остаться в оперативной БД будет для этого достаточно.Подумай на выходных, есть ли у тебя агрегатные данные и как они пересчитываются, есть ли другие какие-нибудь алгоритмы (не отчёты, их можно и в архивной делать), использующие данные документов за значительный период.
Удаление данных - отдельная песня. Тупо резать по дате можно, пожалуй, только логи. Остальные документы удалять можно, как правило, только "связками" по зависимостям между ними, иначе оставленные "огрызки" могут нарушить логическую структуру базы. Особенно это касается связанных отношениями многие-ко-многим документов, таких как накладная/платёж и т.д.
Связи все известны и их можно отследить и учесть притсоздании архивной копии.
Вопрос состоит концепции. Как лучше реализовать ЭТО?
С уважением.
При этом предполагаеться учитывать, что данные архивной БД могут служить не только для просмотра, но и для изменения, хоть и очень редкого... вкаких-то случаях это может быть принципиально.
изменения в архивной БД синхронизировать с оперативной не нужно.
При этом архивная копия содержит данные только одной БД (на этом же сервере)
[предупреждение - Вы можете редактировать свои сообщения. плодить новые на каждое предложение не нужно.]
изменения в архивной БД синхронизировать с оперативной не нужно.
При этом архивная копия содержит данные только одной БД (на этом же сервере)
[предупреждение - Вы можете редактировать свои сообщения. плодить новые на каждое предложение не нужно.]
Re: Архивная копия
Ты не понял вопроса.Nat писал(а):Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере.
Для корректности отчётов, захватывающих период больше чем сейчас в оперативной базе, или вообще "сквозных" по всем данным, в архивной тебе нужно хранить не только то, что нет в оперативной, но и данные самой оперативной.
Т.е. "архивная" = "старые данные" + "оперативная" - "самые свежие изменения оперативной"
Re: Архивная копия
Уточнил вопрос, действительно я не понял задачи, уважаемый WildSery прав, нужно именно это. На самом деле это значительно упрощпет мою задачу, и если я правильно понимаю, здесь уже достаточно односторонней репликации. Только в чем смысл такой архивной копии, только в оптимизации работы с оперативной?WildSery писал(а):Ты не понял вопроса.Nat писал(а):Что касается гетерогенных запросов, не думаю, что они понадобяться, архивная копия должна быть этого же формата (FB 1.5.3) и на этом же сервере.
Для корректности отчётов, захватывающих период больше чем сейчас в оперативной базе, или вообще "сквозных" по всем данным, в архивной тебе нужно хранить не только то, что нет в оперативной, но и данные самой оперативной.
Т.е. "архивная" = "старые данные" + "оперативная" - "самые свежие изменения оперативной"
А только в этом и смысл. Особенно когда архивная на другом сервере.
Оперативная чтобы быстро работала и быстро восстанавливалась в случае сбоя, благодаря небольшому сравнительно объёму.
Архивная - для отчётности, скорость там особо не нужна, работе оперативной не мешает, из-за небольшой и только отчётной нагрузки практически не падает от каких-нибудь сбоев.
Можно и ещё придумать аргументы.
Кроме того, стоит подумать (со временем), чтобы архивная база вообще была на другой платформе (например, кубы вертеть чтобы).
Опять же, всё зависит от объёмов и характера нагрузки.
Оперативная чтобы быстро работала и быстро восстанавливалась в случае сбоя, благодаря небольшому сравнительно объёму.
Архивная - для отчётности, скорость там особо не нужна, работе оперативной не мешает, из-за небольшой и только отчётной нагрузки практически не падает от каких-нибудь сбоев.
Можно и ещё придумать аргументы.
Кроме того, стоит подумать (со временем), чтобы архивная база вообще была на другой платформе (например, кубы вертеть чтобы).
Опять же, всё зависит от объёмов и характера нагрузки.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Ему же нужно иметь в архивной БД те записи, что удалены из оперативной. Хотя, если у него в базе удаление - нормальная операция, то можно и не отключать. Только придется чистить оперативную БД под специальным пользователем, чтобы эта зачистка не реплицировалась.WildSery писал(а):Это почему? Не работает что ли?Dimitry Sibiryakov писал(а):Репликацию удалений отключаешь и все.
У меня это пользователь "Archivator"Dimitry Sibiryakov писал(а):Только придется чистить оперативную БД под специальным пользователем, чтобы эта зачистка не реплицировалась.
Кроме того, "зачистка" не бесследная, в специальной таблице ведётся учёт id-шников таких документов, во избежание недоразумений, а также чтобы архивная база "знала", каких документов нет в оперативной.