Стандарты резервного копирования в RAC (ASM) c помощью RMAN и не только

Здравствуйте Господа!

Нужен совет, как все же, правильно поступить с резервным копированием, если это RAC и ASM соответственно.

Текущая картина такова

GROUP_NUMBER NAME
------------ ---------
1 DATA1
2 FRA
3 OCRVOTE
4 REDO1
5 REDO2
6 BACKUPS

Сама база живет в DATA1 и REDO1,2. Архивныелоги во FRA.

BACKUPS (место для резервных копий в ASM на 5TB), сама база около 2TB.

Собственно два вопроса и некоторые подвопросы мучают, а именно:

1. Можно ли быть спокойным, что бэкапы только в ASM? или нужно дублировать на сырое устройство? Будет ли тогда например РМАН "понимать" свои бэкапсеты? Что будет с резервным копированием, если что-то случится с инстансом ASM? Можно ли использовать в ASM компрессию бэкапсетов?

2. В не RAC среде я создавал допинстанс dbnamercat, как репозиторную БД для РМАНа и был спокоен и доволен, опробована в бою.
Но если это RAC, как быть в таком случае? Создавать rcat1 и rcat2? То есть по принципу, как и целевая или для RAC используется другая стратегия? И если верить многим статьям использования РМАН в режиме nocatalog считается рискованным методом...
Стоит ли выполнять еще и холодное резервное копирование, даже если база 24х7, при использовании ASM.
RET.POLICY наверно отдельная тема.

В общем если, кто то поделится опытом и мыслями буду признателен.

Спасибо.

КМК держать backup на ASM не самое удачное решение
В случае падения ASM Вам сначала потребуется восстановить ASM
Я бы backups вынес как отдельный том и расшарил его хотя бы как NFS
причем предусмотрел что этот том подключен напрямую к основной backup node
а к другим по NFS.
В случае ее падения, отключаешь NFS и вручную монтируешь том на ту ноду с которой будешь выполнять восстановление.

Единственно, одной FRA для archivelog маловато. Лучше иметь еще хотя бы одно destination. У Вас standby есть?

с RAW devices oracle с 12 версии не работает, RMAN не умеет работать с RAW как с устройством для размещения backupset. На RAW можно залить файлы с помощью tar, но зачем?

"Холодный" backup и 24x7 сочетаются слабо
Как вариант, если дисковый массив поддерживает storage snapshot возможно его применение для получения backup. Но именно storage snapshot поможет слабо, так как преимуществ никаких.
Для этого используют либо BCC (Business Copy Volume), либо split mirror чтобы backup не просаживал производительность PROD.

Но RMAN в последнее время работает стабильно, поэтому особого смысла заморачиваться с этим не имеет, тем более у Вас база на ASM.

Спасибо за советы!

А что касается каталога РМАН - отдельного инстанса rcatdb_name? У Вас он используется?

Ребята, подскажите плиз!

Если используем RAC, то - как правило база каталога (в ней регим целевую) тоже создается как и целевая то есть к примеру инстансы: rcat1 и rcat2 имя репозит.базы rcat?
Или в RAC каталог строится иначе?

Romaved,

Тут нет никакой связи. База каталога по идее должна жить на отдельном железе.
Никто не запрещает делать из нее RAC, но в большинстве случаев это было бы излишней тратой денег.

dimacrat
Romaved, Тут нет никакой связи. База каталога по идее должна жить на отдельном железе. Никто не запрещает делать из нее RAC, но в большинстве случаев это было бы излишней тратой денег.

У нас на была на VM, всегда можно было перебросить ее в удобное место

Окей. Значит отдельная БД или на железе или на vm. И лучше вне ASM.
Спасибо.

Romaved
Окей. Значит отдельная БД или на железе или на vm. И лучше вне ASM. Спасибо.

Насколько я помню, каталог RMAN (Как и каталог Grid Control) , если он не используется ни для чего другого, не требует лицензирования.

Часто, эти два каталога размещают на одной служебной базе.

Vadim Lejnin
У нас на была на VM, всегда можно было перебросить ее в удобное место

VM, значит, ок, а ASM, значит, не ок. Да?