Можно ли игнорировать некоторые табличные пространства при выполнении физического резервного копирования - PullRequest
Новая
       4

Можно ли игнорировать некоторые табличные пространства при выполнении физического резервного копирования

3 голосов
/ 13 декабря 2011

У нас есть сценарий оболочки, который выполняет физическое резервное копирование нашей базы данных Oracle (tar + сжатие всех наших файлов базы данных). Недавно мы создали табличное пространство, содержащее таблицы, которые нам не нужны для резервного копирования его содержимого.

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

PS: мы не хотим использовать RMAN.

1 Ответ

1 голос
/ 25 января 2012

Я предваряю здесь свои замечания примечанием: это НЕ нормативный образец. Обычно мы используем RMAN для резервного копирования ВСЕХ файлов данных в базе данных. С этим сказал ...

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

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

 STARTUP NOMOUNT;

 ALTER DATABASE MOUNT ;

 ALTER DATABASE DATAFILE '<complete_path_to_datafile>' OFFLINE DROP ;

 ALTER DATABASE OPEN ;

 DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS ;

Затем продолжите восстановление базы данных (RECOVER DATABASE;)

Очевидно, что имя табличного пространства, указанное вами в команде DROP TABLESPACE, будет тем, которое связано с удаленным файлом данных.

Очевидно, что это не будет работать для табличного пространства SYSTEM. И я бы не посмел попробовать это на других табличных пространствах, таких как UNDO, SYSAUX, USERS. И есть другой синтаксис для удаления и добавления ВРЕМЕННЫХ ТАБЛИЦ.

Я не знаю каких-либо «ошибок» с «DROP TABLESPACE ... ВКЛЮЧАЯ СОДЕРЖАНИЕ», но считаю, что объекты в других табличных пространствах могут быть затронуты. (Учтите, что удаленное табличное пространство может иметь индексы для таблиц в других табличных пространствах, влияние на ограничения внешнего ключа, влияние на хранимые процедуры и т. Д.)

И само собой разумеется, что вам потребуется проверить этот тип процедуры восстановления в тестовой среде до , когда вы будете использовать эту технику в производстве.

Без тестирования вы бы гораздо лучше обслужили, используя RMAN для резервного копирования ВСЕХ файлов данных.

ПРИМЕЧАНИЕ: я не делал ничего подобного со времен Oracle 8, возможно, Oracle 7.3 (тогда, когда нам приходилось накатывать собственные сценарии hotbackup). С тех пор, как мы начали использовать RMAN, у меня не было необходимости тестировать что-то подобное.

ПРИМЕЧАНИЕ. Возможно, потребуется запустить базу данных RECOVER до открытия ALTER DATABASE. Я думаю, что вы можете получить предупреждение об исключении «файл данных нуждается в большем восстановлении», как вы делаете это при запуске базы данных, когда табличное пространство оставлено в режиме BEGIN BACKUP ...

...