maverick2104,

Прочитать офф доку в любом случае нужно
Чтобы сориентироваться, можно посмотреть step by step, например:
Oracle Linux 6.7 with Oracle 11.2.0.4 RAC

(С учетом набора патчей, который мог обновится)

p.s.
> построение системы отказоустойчивости БД при помощи парной работы RAC и ASM
RAC - в общем случае не решает задачи "отказоустойчивости БД"
Скорее это решение задачи "масштабирования"

> Тоесть на одном одном узле будет приходить репликация данных настроеная при помощи той самой ASM
Ты имеешь ввиду реализацию raid-1, средствами ASM (хотя ASM технология не совсем зеркало в обычном понимании)

maverick2104,

Советую разобраться в чем разница реализаций:
RAC - одна база (набор файлов), несколько экземпляров (наборов процессов) работающих на разных узлах

RAC One Node - одна, или несколько баз, размещенных на ASM, или shared filesystem, в каждый момент времени, экземпляр обслуживающий конкретную базу, работает на одном узле, может легко перемещен на любой другой узел


Physical Standby, база и экземпляр (или RAC) на одном узле (наборе узлов), накатывает одну, или несколько своих копий на другом узле (наборе узлов). В любой момент накат может быть остановлен и копия базы может быть открыта в режиме read only, например для получения отчетов.



Есть режим наката standby - real time apply (требует отдельной, недешовой лицезии: Active Dataguard), может быть открыть в режиме read-only в момент наката

Snapshot database - standby database, может быть переключена в режим snapshot database:
В какой то момент времени, snapshot database разрывает связь с мастер базой, открывается как независимая база.



После необходимых работ, все изменения на такой базе сбрасываеются, база возвращается к исходному состоянию и продолжается, остановленный на время работы в режиме snapshot, накат.



Ну и необходимо учитывать, что все эти плюшки, в основном доступны только для Enterprise Edidion, требуют лицензирования всех серверов, что Вы наворотили, + дополнительные лицензии на все сервера, если Вам потребуется например real time apply read only database.

Частино, некоторые доступны и на SE, или могут быть реализованы другими способами, смотри например: 21307530

maverick2104...
Использование пользовательских скриптов для решения некоторых проблем категорически запрещенны ( потому что якобы лишаемся сапорта Oracle )...


можно ссылку, откуда Вы это взяли?
Запрещено для SE например incremental backup, который может использоваться для быстрого наката standby, запрещено recover manager standby для SE. Запрещены snapshot standby, по той же причине.

но штатные команды recover доступны для любой редакции.

Но нужно учитывать необходимость лицензирования процессоров standby node.

Как вариант, возможно использование RMAN накат, как описано в ссылке на SQL.ru тему, что я давал.

Вместо shapshot standby, можно воспользоваться технологиями LVM storage snapshot, которые поддерживают некоторые volume manager

Пример (очень грубо)


После чего создаете клон filesystem/volume из полученного storage snapshot
монтируете его как filesystem на этом узле, или другом узле (если есть лицензия на дополнительные CPU), выполняете стандартные duplicate/recover операции для получения read/write копии master базы.

Производительности полученной файловой системы требуют отдельного обсуждения, но если получать storage snapshot c файловой системы manual standby базы, а не с master db, до это решение, вполне может иметь место в реальной практике.