Здравствуйте!
Есть задача от начинающего dba. Возможно, для кого-то тривиальная, но я пока смутно представляю, как её решить. Если вы поделитесь своими соображением, опытом, советом, буду очень благодарен.
Вводная информация:
Есть БД, в которой довольно большое количество DML операций, подавляющее количество это UPDATE, вот немного информации за последний час:
1.
2.
3.
4.
select COUNT(*) from v$sqlstats where last_active_time > to_date('2016-07-15 09:00','YYYY-MM-DD HH24:MI') and UPPER(sql_text) LIKE '%UPDATE%';
---
COUNT(*)
40089
1.
2.
3.
4.
select COUNT(*) from v$sqlstats where last_active_time > to_date('2016-07-15 09:00','YYYY-MM-DD HH24:MI') and UPPER(sql_text) LIKE '%INSERT%';
---
COUNT(*)
106
Да, здесь hardparse, но это затраты на него пока не сильно волнуют.
Как следствие - объём БД не растёт сильно, но генерируется довольно большое количество redo => arhcived log'ов.
Задача: Организовать еженочный бекап. БД должна быть доступна 24/7.
Теперь немного об ограничениях: В данный момент полный объём файловой системы для арклогов - приблизительно равен объёму сгенерированных арклогов за двое суток. Но скоро начнётся продакшн и увеличится поступление информации в 300 раз. Насколько понимаю, ни о каком хранении арклогов до точки краха БД не может быть речи, негде будет хранить арклоги. Отказаться от архайв режима не могу, не будет доступен горячий бекап.
Посоветуйте: каким образом/чем можно организовать бекап, чтобы он был хотя бы для восстановления на момент бекапа при данных условиях?
Пока вижу ситуацию так: В виду высокой генерации арклогов, думаю удалять их по шедулеру, скажем, каждые 20 минут. Потом, часов в 12, начинается горячее резервирование, возможно, при помощи RMAN. Сформированный бекапсет (контрольник, файлы данных и арклоги) буду хранить для восстановления. Остальные, вновь сформированные, арклоги будут продолжаться удаляться.
Может быть есть смысл думать в другом направление, уменьшение генерации redo или что-нибудь ещё.
Если вы поделитесь своим мнением
