Melkomyagkii_newbi,


Мессир, не надо быть таким категоричным
Вы не знаете систему ТС, не знаете какие задачи требуется решать. Какие специалисты доступны.
не факт, что и ТС их полностью знает :)

Как вариант, надо срочно откатиться на предыдущий день, или потребуется быстро получить clone существующей базы.

Каждый инструмент хорош для своей задачи, Да и какая разница чем был получен datafile image copy?

Melkomyagkii_newbiVadim LejninMelkomyagkii_newbi,


Мессир, не надо быть таким категоричным
Вы не знаете систему ТС, не знаете какие задачи требуется решать. Какие специалисты доступны.
не факт, что и ТС их полностью знает :)

Как вариант, надо срочно откатиться на предыдущий день, или потребуется быстро получить clone существующей базы.

Каждый инструмент хорош для своей задачи, Да и какая разница чем был получен datafile image copy?

В чем категоричность? Мне просто интересно. Может бакап виртуалки вообще открывается моментально. А может можно подобное и на рмане сделать - восстанавливать раз в день базу на соседнем серваке - и бакап отвалидирован и восстановиться тоже шустро.

Все зависит от того, как организовано и для чего используются storage snapshot/clone
если для получения consistent copy тома, и дальнейший слив на ленту - это одно, например,
если backup software умеет сливать snapshot diff - то это и есть инкрементальный backup диска

При наличии таких инструментов, у вас появляется возможность настроить разнообразные сценарии backup/restore/flashback/clone томов vm

Другое дело, что нужно разбираться в используемых инструментах, чтобы применять их правильно.

Кроме того, используя backup software, вы сливаете данные на удаленный диск не по ethernet, а по fc/шине обмена, часто контроллером.
Конечно можно смонтировать по fc backup том и лить на него данные через RMAN, но этот том будет доступен только этой VM, что не всегда удобно.

Кроме того, часто backup software умеет регистрировать в rman полученные копии.

По поводу операций с полученными snapshot:
1) Откат/clone на основе полученного snapshot - как правило выполняется очень быстро.

2) удаление/merge snapshot - требует переиндексации данных, достаточно длительная операция, но она может выполнятся контроллером дискового массива используя гораздо более быстрые внутренние шины массива.

Почитай про технологию storage snapshot/clone - многие вопросы отпадут.

p.s. в RMAN 12с+ появилась поддержка storage snapshot,
кляуза SNAPSHOT TIME 'XXXX' в команде recover

Melkomyagkii_newbi,

Сильно зависит от задач и конкретных решений
Например, для разработки
storage snapshot/clone например на zfs позволяет очень быстро получать копии базы

em oms DBaaS cloud plugin позволяет получать thin clone db основанное на snapshot

В принципе, Вы то же самое можете реализовать с помощью скриптов

Для одного клиента строил систему:

PROD -> STANDBY -> MASTERDB (обновляется раз в день)
C master db после обновления делается storage snapshot
Далее, с помощью emctl делается template для thin clone
За неделю snaphot хранят ежедневно
За месяц - еженедельно
Далее квартал и год
То есть вы можете относительно быстро получить копию базы на эти моменты.


Есть Hyper-V, где хранятся шаблоны рабочей станции разработчиков, с предустановленным набором разработчика.

разработчик через портал Orchestrator заказывает себе рабочее место, создается vm разработчика, портал запрашивает по json у oms список доступных template.
далее разработчик по списку выбирает момент времени на который ему нужна база, Orchestrator
отправляет json запрос на получения клона oms, после выполнения запроса ему возвращается
connect string, dba user, Orchestrator формирует tnsnames.ora и передает управление разработчику.

Зачем это было сделано - не спрашивайте, не я автор такого решения :)
Но, допустим, для студентов курсов - вполне работоспособное решение.