Делаю горячий backup с рабочей базы на тестовую(точно такую )



На тестовой - восстанавливаю


В основном работает без проблем(бэкап начинается с 19 часов - рабочий день у нас до 17.30).
Но если люди задерживаются после работы и активно работают во время бэкапа, то при переносе на тестовую базу
начинаются проблемы - база не консистентна - file 1 needs more recovery to be consistent а именно System.dbf
И тут начинаются пляски с бубном - я добавляю новый UNDO- переключаюсь на него. Иногда сразу помогает.
А иногда начинают валится REDO логи и помогает только полное восстановление с пересозданием control файла.
Я не понимаю физики происходящего. Я одной стороны я же архивирую полностью базу с архив логами, которые создаются пока идет бэкап. Плюс я сохраняю control файл со всеми текущими SCN. Правда на тестовой базе тоже работают, но там я перед восстановлением перевожу базу в состояние mount, восстанавливаю контрол файл из бэкапа и все связанные с ним данные.
Я понимаю, что нужен open resetlogs - но почему возникаю более сложные проблемы? Может быть мне ПЕРЕД восстановлением из бэкапа принудительно сбрасывать redo логи? Читая доку по ORACLE обратил внимание, что они нигде в примерах не делают горячего бэкапа базу. Только тейблспейсами при условии конструкции alter database begin backup. Но это совсем другой метод.
Что посоветуете?

run09alex_lipЧто посоветуете?
Перед восстановлением полностью чистите директорию или восстанавливайте в другую.
Что значит чистить директорию? Я копирую бэкап архив на другой сервак, в свою отдельную папку - делаю rman catalog в той папке. Делаю crosscheck. И восстанавливаюсь из конкретного каталога. Вы имеете в виду что FRA надо почистить - RMAN что-то предыдущее от туда забирает ?

Как раз из многократного прочтения официальной документации по Oracle я и делаю вывод, что они не советуют делать горячий бэкап
так как я делаю( у них либо mount либо alter database begin backup)
Однако в разных интернет источниках - пишут что вроде бы как можно делать так....
Надо спросить у Toma ))

A KУ вас путаница в понимании стратегий бекапа.
Грубо говоря, что бы вы поняли, вы можете делать бекапы с помощью RMAN-а, тогда никаких "alter database begin backup" делать не нужно ! А можно делать что называется "вручную" скриптами (тогда использовать или нет alter database begin backup будет зависеть от того в горячую или вхолодную вы будете делать бекап), но это другая стратегия отличная от RMAN-a. А уже горячий или нет - это не имеет значения когда вы делаете выбор между "ручником" или RMAN-ом.

Если вы выбрали стратегию "ручника", тогда:
1 Выбрали делать на холодную. - Тушите БД копируете все файлы БД (так называемая имидж-копия).
2. Выбрали делать на горячую - Внимание! Только теперь вам нужно использовать конструкцию "alter database begin backup" В этом случае бекапируете контролсы, затем сброс редолога, затем alter database begin backup затем копируете все датафайлы на диск в другое место. затем alter database end backup. затем опять сброс редолога. Теперь у вас есть - контролсы + горячие копии датафайлов + архивредологи. Из них вы поднимаете тестовую бд со сбросом редологов перед открытие БД.

Видимо я плохо пишу текст(((.
Я же привел скрипт при помощи которого делаю ГОРЯЧИЙ бэкап RMAN'ом.
Я НЕ делаю alter database backup.

У меня вопрос - есть ли у кого-нибудь практика горячего full бэкапа RMAN'ом при достаточно нагруженной базе(Я базу не хочу останавливать!) и переноса оного на другой сервак?
Еще раз. Этот перенос у меня работает - НО не стабильно - иногда при восстановлении оказывается недостаточно open resetlogs
И приходится или играться с UNDO, или делать полное восстановление. Несмотря на то, что у меня есть full backup+controlfile+ archive log's

to tru55
====
И по горячему backup там вполне достаточно описаний.
====
А можете ссылкой тыкнуть где это про RMAN написано ? Просто я вижу с RMAN-ом в официальное доке примеры только холодного бэкапа(((

Извиняюсь что не сказал версию Oracle - 11.2

==================
If a database runs in ARCHIVELOG mode, then you can back up the database while it is open. The backup is called an inconsistent backup because redo is required during recovery to bring the database to a consistent state. If you have the archived redo logs needed to recover the backup, open database backups are as effective for data protection as consistent backups.
To back up the database and archived redo logs while the database is open:

Start RMAN and connect to a target database.

Run the BACKUP DATABASE command.

For example, enter the following command at the RMAN prompt to back up the database and all archived redo log files to the default backup device:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

==================
Читал я это конечно. Я же приводил свой скрипт. Там так и написано. Только, насколько я понимаю это делается для того, чтобы восстановиться на той же базе.
Я же данные переношу на другую, но такую же. И еще раз повторюсь - у меня это работает, но иногда раз в месяц - иногда чаще при
восстановлении происходят проблемы. Приходится делать полное восстановление с пересозданием controlfile
Поэтому я и спрашиваю - есть ли у кого-нибудь подобная практика?

Vieweralex_lipТолько, насколько я понимаю это делается для того, чтобы восстановиться на той же базе.
Я же данные переношу на другую, но такую же.
Расшифруй что сказал...
)) Сначала было слово...

Есть две изначально одинаковые базы. Одна получена полной копией другой.
Одна - рабочая. В другой балуются разработчики. Раз в сутки карета превращается в тыкву. То есть не останавливая рабочую базу
я обновляю базу данных для экспериментов. Делаю это при помощи скриптов RMAN. Скрипты приведены в шапке. Из скриптов видно, что выгружаю я на горячую, а загружаю из каталога в состоянии mount - скрипт тоже приведен (3-е сообщение)
И все бы хорошо, но иногда при восстановлении бывают проблемы file 1 needs more recovery to be consistent а именно System.dbf .
После плясок с бубном, которые тоже описаны я восстанавливаю базу. Все норм. Но мне непонятно почему это происходит и как сделать, чтобы этого не происходило!

Тестовую базу - я останавливаю. Рабочую - нет

Ну это вовсе не finish
Даже в этом случае есть способы восстановить базу. Ведь проблемы не с основными данными, а с undo и rollback. С учетом full backup + archive logs+ control file - нет ничего невозможного.

Так это для стэндбая вроде бы?

FINISH Specify FINISH to complete applying all available redo data in preparation for a failover.

Use the FINISH clause only in the event of the failure of the primary database. This clause overrides any specified delay intervals and applies all available redo immediately. After the FINISH command completes, this database can no longer run in the standby database role, and it must be converted to a primary database by issuing the ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY statement.

Знает - в МИФИ (теперь как-то по другому называется) не так давно в цокольном этаже построили православный храм. И теперь физики с Ф факультета помолясь идут к ядерному реактору )))
На самом деле если нет в доке - то как-то странно... или Вы что-то знаете?