Резервное копирование / восстановление базы данных для тестирования Oracle 10g с использованием sqlplus или rman

Question

Использование Oracle 10g с нашим тестовым сервером - это самый эффективный / простой способ резервного копирования и восстановления базы данных в статическую точку, при условии, что вы всегда хотите вернуться к заданной точке после создания резервной копии.

Пример использования будет следующий

1. установить и настроить все программное обеспечение
2. Изменить данные для базовой точки тестирования
3. сделать резервную копию как-то (это часть вопроса, как это сделать)
4. сделать тестирование
5. вернуться к состоянию шага 3 (восстановить обратно в резервную точку, это другая половина вопроса)

Оптимально это может быть выполнено с помощью sqlplus или rman или с помощью другого скриптового метода.

Answer 1

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

Шаги для этого будут:

1. Запустите экземпляр в режиме монтирования.

   пусковое крепление;

2. Создать точку восстановления.

   создать точку восстановления до и после проверки базы данных флэшбека;

3. Откройте базу данных.

   изменить базу данных открытых;

4. Запустите ваши тесты.

5. Выключите и смонтируйте экземпляр.

   немедленное отключение; автозагрузка;

6. Воспоминание о точке восстановления.

   флэшбэк база данных для восстановления точки before_test;

7. Откройте базу данных.

   изменить базу данных открытых;

Answer 2

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

Цитируется с сайта,

Flashback Database - это как кнопка перемотки для вашей базы данных. Он обеспечивает восстановление базы данных на определенный момент времени, не требуя восстановления резервной копии базы данных. Если вы устраняете время, необходимое для восстановления резервной копии базы данных с ленты, восстановление базы данных происходит быстро.

Answer 3

Исходя из моего опыта, импорт / экспорт - это, вероятно, путь. Экспорт создает логический моментальный снимок вашей БД, поэтому вы не найдете его полезным для больших БД или строгих требований к производительности. Тем не менее, он отлично подходит для создания снимков и тому подобного для использования на нескольких машинах.

Я использовал его в проекте rails, чтобы получить снимок продукта, который мы могли бы поменять местами между разработчиками для интеграционного тестирования, и мы выполнили работу в рамках сценариев rake. Мы написали небольшой скрипт sqlplus, который уничтожил БД, а затем импортировал файл дампа поверх.

Некоторые статьи, которые вы можете проверить: OraFAQ Cheatsheet Oracle Wiki

По-видимому, Oracle больше не любит imp/exp в пользу насоса данных, когда мы использовали насос данных, нам нужны были вещи, которых у нас не было (например, привилегии SYSDBA, которые мы не могли получить в общей среде). Так что взгляните, но не унывайте, если насос данных не ваша сумка, старый imp/exp все еще там:)

Я не могу рекомендовать RMAN для такого рода вещей, потому что RMAN требует много настроек и нуждается в конфигурации в БД (у него также есть свой собственный каталог БД для резервных копий, что является проблемой в общеизвестном смысле для восстановления с нуля).

Answer 4

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

Answer 5

Решение @Michael Ridley отлично подходит для сценариев и будет работать с любой версией oracle.

Это именно то, что я делаю, у меня есть скрипт, который запускается еженедельно

1. Откат файловой системы
2. Применить производственные архивы журналов
3. Сделайте новый снимок FS "Pre-Data-Masking"
4. Сбросить логи
5. Примените "предпроизводственное" маскирование данных.
6. Сделайте новый снимок "Post-Data-Masking" (позволяет выполнить откат для публикации замаскированных данных)
7. Открытая база данных

Это позволяет нам поддерживать наши базы данных разработки близко к нашей производственной базе данных.

Для этого я использую ZFS.

Этот метод также может использоваться для ваших приложений или даже для всей вашей "среды" (например, вы можете "откатить" всю свою среду с помощью одной (скриптовой) команды.

Если вы используете 10g, первое, что вы, вероятно, захотите посмотреть, это Flashback, поскольку он встроен в базу данных.