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

Чета каша какая-то
RMAN рулит бэкапами (в том числе и архивлогов) и к мультиплекированию журналов отношения не имеет

Если у тебя навернется диск на котором лежат по одному журналу из каждой группы, БД продолжит работать с остальными членами этих групп. Конечно, ситуацию нужно будет побыстрее разрулить, но не смертельно.
Кстати, если на этом навернувшемся диске лежала копия контролфайла, то БД упадет, даже если есть еще живые контролфайлы.
Архивные журналы тоже ничто не мешает мультиплексировать

А при чем тут RMAN я не понял. Но на всякий случай поизучай команду CATALOG :-)

nata44845То есть ты говоришь, что редологи в сеть мультиплексировать можно,Теоретически, конечно, можно
Но я бы не стал. Пара независимых локальных девайсов вполне достаточно (ну и если есть нормальный дисковый массив, то и на него можно)
Если уж совсем приспичило именно удаленно, я бы использовал (если позволяет редакция) стендбайный контролфайл, standby redo logs и передачу редо-потока через LGWRnata44845 и даже если сеть пропадет база все равно будет работать на других редологах из группы?Скорее всего, возникнет достаточно большая задержка в случае недоступности (как и в случае доступа из ОС)
nata44845Или я чего-то не понимаю, и рман хоть как поднимает базу ровно по архивлоги? Я думала он редологи тоже захватывает, чтобы прямо прямо на последний момент попасть? Или такое не реально.Надо определиться с понятием "поднятие базы".
Обычный RESTORE, RECOVER с текущим контролфайлом и оперативными журналами на своем месте прекрасно все подхватит и докатит до концаnata44845К примеру поднимала БД на тестовом сервере, чистая БД, меняла в spfile имя, меняла ID, поднимала CF из бэкапа поверх текущего, подтягивала данные о копии (man>catalog START WITH ‘X’;) так как пути к копии поменялись, меняла директории системных и прочих файлов, поднимала базу, в конце alter database open resetlogs; Тут что-то все понамешано
Какая-то "чистая БД", смена какого-то ID перед восстановлением собственно бэкапаnata44845То есть редологи не попали, или их можно попробовать подсунуть если они все таки есть (к примеру мультиплексировали в сеть, винт накрылся, редологи остались)?Можно

Только будет достаточно большая задержка, пока система определит, что сетевой диск недоступен (база подвиснет)
Надо настраивать сетевые таймауты на уровне OS

Но, если редакция EE, то поднятый стендбай-экземпляр (без датафайлов) вполне может себе принимать как оперативные, так и архивные логи
Насколько понимаю, отдельно его лицензировать не требуется (могу ошибаться, но т.к. файлов данных нет...)

Насколько помню, 10 суток -- это конфигурация Failover Clusterстарый sig.pdf Failover – In this type of recovery, nodes are arranged in a cluster and share
one disk array . A Failover cluster is a group of systems, bound together into a
common resource pool. In this type of recovery method, the Production node
acts as the primary node. When the primary node fails, one of the surviving
nodes in the cluster acts as the primary node. Solutions like Oracle Failsafe
(included with Oracle Database EE or SE, SE1), or third party vendor solutions
(e.g. Veritas, HP Service Guard, HACMP, Linux HA - Heartbeat) are used to
manage Failover environments. In this type of environment, Oracle permits
licensed Oracle customers to run some Technology Programs on an
unlicensed spare computer for up to a total of ten separate days in any given
calendar year .
Я имею ввидуData Guard Concepts and Administration
Introduction to Redo Transport Services Redo transport services performs the automated transfer of redo data between Oracle databases. The following redo transport destinations are supported:
...
Archive Log repository

This destination type is used for temporary offsite storage of archived redo log files. An archive log repository consists of an Oracle database instance and a physical standby control file. An archive log repository does not contain datafiles, so it cannot support role transitions.

The procedure used to create an archive log repository is identical to the procedure used to create a physical standby database, except for the copying of datafiles.Информацию по его лицензированию я нигде не нашел
С одной стороны -- софт установлен и запущен
А с другой -- это вспомогательный узел типа OBSERVER-а, который также является частью DataGuard, но отдельно не лицензируется
Подробности таки лучше узнавать у Oracle

В крайнем случае, поднять ALR на том же хосте (ему ресурсов-то нужно чуть) и именно его Standby Redo Logs держать на сетевом диске.
Как мимнимум, это устранит зависание боевой БД на время таймаута при отвале сетевого диска