Ну. Тут, смотря что вы понимаете под датагардом. Не зря вы этот термин в кавычки взяли.
В буквальном смысле достичь функций вендорского датагарда - не получится. Ну там: актив-датагард, различные моды работы датагарда - максимум протекшен/авайлабилити/перфоманс, эмуляция обслуживания дмл-команд (вдруг вы про 19с) ) что там ещё.

Однако слепить физикал-стендбай бд (прям натурально - Physical standby): никто и ничто не запрещает и в SE.
Исходную бд: в архлог, желательно режим форс-логгирования.
Ресторите, из рман-бэкапов, исходной бд, на отдельной серверной площадке, датафайлы.
На исходной бд варите контрольник, для PS-базы, по

Передаёте его на сторону серверной площадки, где лепите standby-базу.
Монтируетесь с него, оно замонтируется именно как physical standby.
Ну и всё.
Дальше (ну, практически то - уже должно быть сделано): как угодно: организовываете передачу арх. логов, со стороны исходной субд, на сторону вновь слепленной standby-базы.
И накат-ротирование накаченных арх-логов, на стороне вновь слепленной standby-бд.
Имхо: удобно, для этих целей, использовать скриптики на связке incrond+rsync.
На стороне primary-бд: оно само среагирует на событие появления нового арх-лога и отправит его, куда надо (ну, если постараться, в скриптописании)
На стороне standby-бд: само среагирует на поступление нового арх-лога и можно проскриптовать действия: накат, удаление накаченных арх-логов.
Накат: ну, имхо проще всего рман-ом, по "recover database;"

Если ещё подать на обе серверные площадки какой то шаредный сторидж, с рман-бэкапами primary-бд + прописать скрипт наката арх. логов, на стороне standby-базы так чтобы оно каталожило рман-бэкапы у себя - оно ещё и гап-ы проходить будет самостоятельно.

При этом: вы ничего не нарушаете, до тех пор пока ваша SE-standby-бд: она именно standby-бд.
Когда она выводится в работу вот там - да, у вендора может возникнуть почва для вопросов, в зависимости от того - как и насколько времени выводите.

Vadim Lejnin,

авторВы не можете запустить на не лицензированной платформе накат standby, так как работает правило 10 дней (для master datafile) и правило правило 4х2 для standby datafiles.
Ну. Это всё верно. Если речь идёт о субд редакциях в которых датагард - поддерживается вендором.
Т.е.: вот этот документ он - о чём, о SE/SE2-редакциях?
Он про EE, ибо датагард может быть только там.

Т.е. с т.з. вендора, если я соберу "standby" в SE - ну и, что, это некая моя поделка и не более того.
Притянуть вендорский аудит тут меня не сможет, ни по какому поводу: база стоит себе в маунте, я на неё накатываю арх. логи и всё.
Это не дев, не тест, не прод.
Собрать такое вендор мне не запрещает.
То что ом мне запрещает: касается других редакций/опций этих редакций, а тут - SE.

При выводе в работу se-standby, ну, SE - оно лицензируется по сокетам.
Т.е. если у меня помер старый сервер с продовой бд, и я активировал se-standby на другом сервере, который, квантитативно (по сокетам, по ОС-и) - попадает под имеющееся в организации лицензирование (ну, практически - такой же как померший сервер субд): ну опять же - за что тут меня вендор притянет?
Это, практически - просто миграция бд с одного сервера на другой, точно такой же и не более того.

Vadim Lejnin,

автора где написано именно про standby или dataguard?
В документе охвачены любые копии/backup datafile на другом сервере.
Вычитал документ , внимательно.
Действительно.

Выражаясь прокурорским языком: квалифицирующие признаки DR-env - copying/syncing/mirroring;
Т.е.: датафайлы бд - копировал, с исходной машины, на вторую? Да, копировал.
Синхронизация копии - делается (не важно как)? Да, делается.
Ну и всё, значит это: DR-env.
And, as a consequence: "In these Data Recovery deployments all Oracle programs that are installed and/or running must be licensed per standard policies documented in the Oracle Agreement."

Признаю: был не прав, вводил народ в заблуждение, своими фантазиями.