Oracle восстанавливает базу данных до «более новой» версии - PullRequest
Новая
       7

Oracle восстанавливает базу данных до «более новой» версии

2 голосов
/ 28 сентября 2011

Можно ли проверить инкрементные резервные копии ... ну, пошагово? Если так: как? и не использовать слова «дубликат» и «резерв».

Настройка

  • База данных Multi-TB Oracle 11g (11.2.0.2), около 70% данных находятся в табличном пространстве только для чтения.
  • Резервное копирование: еженедельная копия уровня 0 (кроме чтения только), полудневная инкрементная запись уровня 1 (разностные данные + архив журнала).

После резервного копирования уровня 0 мы отправляем все файлы резервных копий на испытательный стенд (в автономном режиме для всех целей и задач) и выполняем полное восстановление и восстановление. Я хочу переместить инкрементную резервную копию (<50G) на испытательный стенд и проверить только эти биты. Тест на восстановление может (в моей голове) завершиться за несколько минут или, альтернативно, за несколько часов, если данные для чтения могут быть каким-то образом сохранены. В противном случае полное восстановление + восстановление занимает ~ 9 часов. </p>

Конечная цель - сократить время тестирования аварийного восстановления на ~ 70%, занимаемое табличным пространством только для чтения в 12-часовых инкрементных циклах - полное восстановление / восстановление раз в неделю требуется политикой.

Если мое (пока еще не законченное) решение не подходит, предложения приветствуются (все еще не используются «дубликаты» или «резервные»: o).

РЕДАКТИРОВАТЬ 4 октября 2011 г .: Итак, я выяснил, как избежать восстановления табличного пространства только для чтения при каждом тесте, чтобы сэкономить 70% времени. Осталось выяснить, возможно ли восстановить только последнюю инкрементную резервную копию на испытательном стенде.

Чтобы было ясно: в воскресенье я получаю при свежем восстановлении + восстановление всего, включая readonly. Каждые 12 часов я выполняю новый тест восстановления, который пропускает биты только для чтения, но выполняет восстановление уровня 0 оставшихся 30%, затем применяет инкрементальные значения - по сути, откат до воскресенья с последующим увеличением до последнего инкремента.

Мне бы хотелось сделать полное воскресенье восстановления и каждые 12 часов «применять» только последнюю инкрементную резервную копию к этому восстановлению и избегать отката до воскресенья.

Ответы [ 2 ]

0 голосов
/ 09 декабря 2011

Я чувствую, что на этот вопрос нужно ответить, хотя бы частично, поэтому вы идете:

Часть восстановления все еще открыта, но избегание бита readonly-tablespace решается с помощью переносимых табличных пространств.По сути,

  • помечает табличное пространство только для чтения как передаваемое
  • , создает файл дампа, используя expdp
  • , копирует ваши файлы данных на тестовую установку
  • do aвосстановить, но пропустить рассматриваемое табличное пространство
  • удалить табличное пространство из базы данных
  • impdp в вашу базу данных.(по существу, воссоздание из импорта)

Мы сделали это для табличного пространства размером 3 ТБ, заняло все 30 секунд.(и 10 часов для копирования: oP)

Предостережение: помечать как передаваемые и отбрасывать табличное пространство, возможно, неправильно, особенно если у вас есть зависимости между табличными пространствами.

0 голосов
/ 30 сентября 2011

Я не уверен в разделении между временем резервного копирования, временем передачи и временем восстановления для вашей конфигурации, но вот мои мысли.

Если вы хотите сократить время restore , изучите параметр CHECK READONLY для команды RMAN RESTORE. Похоже, вы можете хранить копии файлов данных, доступных только для чтения, в целевой системе и не понести накладных расходов на RMAN, разгоняющий все эти биты и байты во время восстановления.

Вы не упомянули версию, так что из документации 9i RMAN для команды RMAN RESTORE:

ПРОВЕРЬТЕ ЧТЕНИЕ Проверяет заголовки файлов только для чтения, чтобы убедиться в их актуальности, прежде чем исключать их из восстановления.

Если вы хотите сократить время передачи вашего резервного набора данных уровня 0 и можете гарантировать безопасность файлов данных только для чтения, изучите параметр SKIP READONLY для команды BACKUP.

Пропустить только Указывает, что файлы данных только для чтения должны быть исключены из набора резервных копий.

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

Но просто знайте, как вы справляетесь с этой ситуацией - будет ли выполняться та же процедура в случае истинного сценария восстановления (будь то ПРОВЕРКА ЧИТАТЬ ТОЛЬКО или другой метод)?

...