Здравствуйте!
Есть задача от начинающего dba. Возможно, для кого-то тривиальная, но я пока смутно представляю, как её решить. Если вы поделитесь своими соображением, опытом, советом, буду очень благодарен.

Вводная информация:

Есть БД, в которой довольно большое количество DML операций, подавляющее количество это UPDATE, вот немного информации за последний час:






Да, здесь hardparse, но это затраты на него пока не сильно волнуют.

Как следствие - объём БД не растёт сильно, но генерируется довольно большое количество redo => arhcived log'ов.

Задача: Организовать еженочный бекап. БД должна быть доступна 24/7.

Теперь немного об ограничениях: В данный момент полный объём файловой системы для арклогов - приблизительно равен объёму сгенерированных арклогов за двое суток. Но скоро начнётся продакшн и увеличится поступление информации в 300 раз. Насколько понимаю, ни о каком хранении арклогов до точки краха БД не может быть речи, негде будет хранить арклоги. Отказаться от архайв режима не могу, не будет доступен горячий бекап.
Посоветуйте: каким образом/чем можно организовать бекап, чтобы он был хотя бы для восстановления на момент бекапа при данных условиях?

Пока вижу ситуацию так: В виду высокой генерации арклогов, думаю удалять их по шедулеру, скажем, каждые 20 минут. Потом, часов в 12, начинается горячее резервирование, возможно, при помощи RMAN. Сформированный бекапсет (контрольник, файлы данных и арклоги) буду хранить для восстановления. Остальные, вновь сформированные, арклоги будут продолжаться удаляться.

Может быть есть смысл думать в другом направление, уменьшение генерации redo или что-нибудь ещё.

Если вы поделитесь своим мнением

landy,

Масса апдейтов в таблицу W_WLD_MA
Содержание одного из низ:
UPDATE W_WLD_MA SET LAST_COMM_DATE = '15072016101427' WHERE MAIN_PROC_CD = '485' AND LR_GUBUN = '1' AND SUB_PROC_CD = '0'

Т.е. обновляется дата состояния объекта. Объектов довольно много получается.

landyНе знаю скрытого смысла - но зачем обновлять 22 раза в секунду LAST_COMM_DATE (имхо вероятность
смены условия за этот период мала, но опять же нужно знать специфику приложения)
Я бы обратил внимание разработчиков на это - пусть подумают как правильнее сделать
Ну либо пусть от своего бюджета отпилят на диски для хранения архивлогов )))
Приходит сигнал от робота о смене состояния контроллера, измерений. В одном роботе таких котроллеров и измерителей очень много. Таких роботов очень много. Получается такой вот udpatовый шквал.

Вячеслав Любомудров, спасибо за замечание.
Per sec
Executes (SQL): 632.1



Из этого блока подойдёт инфа для корректного анализа?

KoTTTКто мешает бэкапить только архивлоги хоть каждый час, полчаса и т.д.?
Не мешает никто, было бы куда бэкатить, здесь сталкиваемся с ограничениями в ресурсах :( нет места для такого объёма арклогов.

Вячеслав Любомудров,

Да, это хороший вариант, спасибо, теперь нужно будет только позаботиться о достаточно большом UNDO. Правильно понимаю?

Вячеслав Любомудров,

из-за смутного понимания и не определённых вариантов к действию, хочу сказать Вам большое спасибо за то, что рассеяли это непонимание.

Вячеслав ЛюбомудровНепонимание у тебя в постановке:
"БД должна быть доступна 24/7" и "восстановления на момент бекапа" -- как-то не сходится
Насколько известно, более критично - наличие доступной БД, чем отсутствие в ней части данных за время с последнего бекапа до возобновления работы БД. Так и получается.

landyКстати, если БД EE - можно посмотреть в эту сторону
Включить block change tracking, сделать инкрементально обновляемую копию(обновлять раз в час или два)
И хранить архивлоги только за последний час/два - удалять ненужные после обновления копии
Как-то так
О, вот это довольно хороший вариант. Спасибо, landy!

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