Как восстановить таблицу в sql oracle

Обновлено: 05.07.2024

Одно из нововведений Oracle 10g это корзина. Эта возможность работает аналогично корзине в OC Windows или Mac OS. В этой статье будет описано, как работать с корзиной.

Начало

Существует два представления корзины: USER_RECYCLEBIN и DBA_RECYCLEBIN. Для удобства синоним RECYCLEBIN указывает на ваш USER_RECYCLEBIN. По умолчанию корзина активирована, но ее можно отключить в инициализационном параметре RECYCLEBIN, на уровне сессии или системы.

Когда корзина активна, любые таблицы, которые вы удаляете, не удаляются полностью, а попадают в корзину. Вместо того что бы удалить таблицу, Oracle переименовывает ее и все связанные объекты (индексы, триггеры, LOB сегменты и т.д.). Дает им системное имя, которое начинается на BIN$.

Например, рассмотрим такую ситуацию:

Если параметр RECYCLEBIN выставлен в значением ON, (по-умолчанию в Oracle 10g он включен), удаление таблицы приведет к ее перемещению в корзину.

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

Поскольку данные все на месте, то не составит труда вернуть из корзины таблицу обратно. Эта операция известна как «flashback drop». Команда FLASHBACK TABLE. TO BEFORE DROP переименовывает таблицу из имени с BIN$ в ее оригинальное имя, в нашем случае TEST.

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

Есть несколько опций удаления. Можно удалить все из USER_RECYCLEBIN используя PURGE RECYCLEBIN; пользователь с привилегиями DBA может удалить все из всех корзин, используя DBA_RECYCLEBIN; и наконец, можно очистить корзину по схеме и пользователю, используя PURGE TABLESPACE USER.

Oracle сохраняет объекты в таблице до тех пор пока вы не удалили их, или в табличном пространстве хватает места, или не превышена квота пользователя. Очистка произойдет одной операцией с текущего момента до тех пор, пока не освободится достаточно места для текущей операции. Если файлы данных табличного пространства с опцией AUTOEXTEND ON, корзина будет очищена до того как сработает автоприращение.

Удаление версий таблицы

Точно так же как в корзине Windows может быть несколько файлов с одинаковым именем и расширением, в корзине Oracle может быть несколько версий таблицы. Создадим и удалим дважды таблицу TEST.

Сделаем запрос к таблицам, что бы убедится, что они разные:

Теперь возникает вопрос, какую версию Oracle восстановит при указании FLASHBACK DROP?

Oracle всегда восстанавливает последнюю по времени версию объекта. Чтобы восстановить более раннюю версию можно указать имя таблицы для восстановления. Сейчас в корзине две версии:

Для восстановления первой версии будем использовать имя первого экземляра:

Вторая версия осталась в корзине:

Зависимые объекты

В современных базах данных очень редки ситуации, когда таблица существует сама по себе. Как правило, они имеют индексы, триггеры, связи ограничения. Удаление таблицы приводит к удалению всех зависимых объектов. При удалении все объекты, как и таблица, переименовываются, их новое имя начинается так же с BIN$.

Представление RECYCLEBIN имеет и другие столбцы, показывающие и связь между TEST и TEST_COL_IDX.

Колонка PURGE_OBJECT содержит номер самого объекта, BASE_OBJECT содержит номер главного объекта. Таблица TEST имеет номер 233031, базовый объект для нее – тот же самый, т.е. она сама себе базовый объект. Индекс TEST_COL_IDX имеет номер 233434, а базовый объект для него – 233031, таблица TEST.

Если выполнить FLASHBACK TABLE для таблицы TEST, ее индекс будет восстановлен, но Oracle не переименует его обратно в оригинальное имя. У индекса так и останется имя BIB$.

Скорее всего, Oracle не особо заботится о сохранении оригинального имени индекса. Если сейчас снова удалить копию таблицы TEST, то выяснится, что Oracle «не помнит» оригинального имени индекса.

Обратите внимание на значения в столбцах CAN_UNDROP и CAN_PURGE (мы их показываем как UND и PUR) для индекса. Индекс не может быть восстановлен без таблицы, значение CAN_UNDROP равно NO. В то же время индекс может быть удален без таблицы.

Сейчас если восстановить таблицу, то она будет восстановлена без индекса

Если удалите таблицу со связанными LOB сегментами, то с ними будет подобная ситуация, исключение состоит в том, что они не могут быть независимо удалены, CAN_UNDROP и CAN_PURGE будут выставлены в NO. Если восстановить таблицу то они будут восстановлены вместе с ней, если таблица будет удалена из корзины, то и они будут удалены.

Ограничения

Если удаляется таблица и затем восстанавливается, ссылочная целостность теряется.
Для материализованных представлений, если удаляется таблица, все журналы определенные для этой таблицы удаляются без помещения в корзину.
Если удаляется базовая таблица, то bitmap индексы не помещаются в корзину. При восстановлении таблицы из корзины индексы не восстанавливаются.

Отключение корзины

Аналогично корзине в Windows, где можно удалить файл, минуя корзину, в Oracle реализован такой же механизм. Для этого в предложении DROP TABLE указывается PURGE.

Если отключать корзину на уровне сессии, то требуется выполнить предложение ALTER SESSION SET RECYCLEBIN=OFF. Это даст тот же эффект, что и добавление PURGE в предложение DROP TABLE. Но, стоит отметить, что можно использовать FLASHBACK DROP для восстановления объектов, которые были помещены в корзину до того как было выполнено отключение корзины.

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

Выполняется операция UPDATE , если строки существуют, и операция INSERT , если это новая строка:

исключает необходимость в отдельных обновлениях;

повышается производительность и простота использования;

удобна в приложениях хранилища данных.

Сервером Oracle поддерживается инструкция MERGE для операций INSERT , UPDATE и DELETE . Используя эту инструкцию, можно обновить, вставить или удалить строку по условию в таблице, таким образом исключая необходимость применения нескольких инструкций DML. Решение о выполнении обновления, вставки или удаления в целевой таблице основывается на условии в предложении ON .

Необходимо иметь объектные привилегии INSERT и UPDATE на целевую таблицу и объектную привилегию SELECT на исходную таблицу. Чтобы задать предложение DELETE для merge_update_clause , необходимо также обладать объектной привилегией DELETE на целевую таблицу.

Инструкция MERGE является детерминированной. Одну и ту же строку целевой таблицы невозможно обновить несколько раз в одной и той же инструкции MERGE .

Альтернативный подход состоит в использовании циклов PL/SQL и нескольких инструкций DML. Однако инструкцию MERGE удобно использовать и проще выразить в виде одиночной инструкции SQL.

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

Синтаксис инструкции MERGE

Используя инструкцию MERGE , можно по определенному условию вставлять, обновлять и удалять строки в таблице.

Объединение строк

Используя инструкцию MERGE , можно обновлять существующие строки и вставлять новые строки по определенному условию. Применяя инструкцию MERGE , можно удалить устаревшие строки одновременно с обновлением строк в таблице. Чтобы сделать это, в синтаксис инструк- ции MERGE включите предложение DELETE со своим собственным предложением WHERE .

Предложение INTO - задает целевую таблицу, которая обновляется или в которую выполняется вставка.

Предложение USING - идентифицирует источник обновляемых или вставляемых данных; может быть таблицей, представлением или подзапросом.

Предложение ON - условие, по которому операция MERGE выполняет обновление или вставку.

WHEN MATCHED | WHEN NOT MATCHED - предписывает серверу, как реагировать на результаты условия объединения

Более подробно изложено в документации Oracle Database 11g SQL Reference (Справочник по SQL для базы данных Oracle 11g).

Сокрушилося сердечко,
Взволновалась в сердце кровь,
Потеряла я колечко,
Потеряла я любовь.

Музыка народная, слова М. Н. Ожегова.

Введение

Потеря таблицы целиком, или нужных строк из нее, есть классический несчастный случай при работе с базой данных и практика БД не может не давать на него ответ. И в общей практике баз данных, и в Oracle в частности есть многообразие способов выкрутиться из возникшей неприятности, а конкретные действия зависят от суммы обстоятельств.

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

б) наличием или отсутствием физической копии

в) наличием или отсутствием у используемой БД режима архивирования освободившихся журналов.

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

Как видно, способы, предлагаемые Oracle , действительно многообразны, возможно даже избыточно. Из них наиболее универсальными остаются классические для баз данных восстановление по логической копии таблицы, полученной с помощью exp , и восстановление по физической копии. На второе место по универсальности можно поставить восстановление по истории изменений, почерпнутой из журналов (как активных, так и архивных копий), а на третье – ряд интересных возможностей версий 9 и 10, хотя и специфичных, но также обладающих своими достоинствами.

Здесь будет рассмотрен классический вариант восстановления образа таблицы по физической резервной копии. Восстановление по логической копии таблицы программой imp совсем уж очевидно. Отмечу только, что

Восстановление по физической холодной копии

Если в распоряжении администратора имеется физическая холодная копия БД (полный комплект файлов, образующих в Oracle БД, и скопированных при остановленной БД), можно извлечь образ нужной таблицы по состоянию на момент закрытия БД перед снятием холодной копии. Идея такого восстановления очень проста: запустить БД по холодной копии, извлечь из нее таблицу программой exp и перенести в текущую БД. Тем не менее здесь тоже могут быть свои небольшие хитрости:

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

Итак, пусть сейчас в активном состоянии находится БД MYDB и в каталоге c:\oracle\oradata\mydb\backup\1-cold (операционной системы Windows ) находится полный комплект файлов ее холодной копии.

Подготовка файлов холодной копии для запуска

Заведем каталог и скопируем туда все файлы холодной копии, где бы они не находились изначально. Все равно мы их потом удалим, так что иметь их в одном каталоге просто удобнее. Например :

Откорректируем файл c:\oracle\temp\init.ora . Заменим все имена каталогов, имя СУБД и добавим один новый параметр:

Менять имя БД в реанимированной холодной копии не будем (хотя это и возможно), а СУБД для ее активизации назовем иначе ( TEMP ), так как две СУБД с одинаковым именем на одной машине одновременно работать не смогут. Но одной только смены имени СУБД недостаточно; чтобы не было конфликта имен из-за сохранения имени БД, мы вынуждены добавить в INIT -файл новой СУБД специальный параметр LOCK_NAME_SPACE с указанием ее (нового) имени.

Активация новой БД

В Windows мы обязаны завести службу ОС:

Запускаем СУБД, открываем контрольный файл и запрашиваем исходные расположения файлов БД холодной копии:

Теперь следует пройтись по полученному списку файлов и поменять им в контрольном файле имена, например:

Теперь базу можно открыть:

SQL> ALTER DATABASE OPEN;

Восстановление данных

Вот как может выглядеть извлечение данных:

SQL> HOST exp scott/tiger TABLES=(emp)

Вот как может выглядеть восстановление:

Убираем за собой

Данные извлечены, реанимированная БД стала не нужна, и компьютер от нее нужно освободить. Для этого ее можно закрыть, удалить все связанные с ней файлы, а в Windows еще почистить реестр ОС. Например в Windows это обеспечат следующие действия:

Восстановление по физической горячей копии

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

Отличия в копировании

При копировании файлов горячей копии можно сэкономить на копировании файлов табличных пространств, где нет данных интересующих нас таблиц. Например, в нашем случае достаточно скопировать в каталог c:\ oracle\ temp только файлы табличных пространств SYSTEM и USERS . Правда, смонтировав новую СУБД мы должны будем, как и прежде, переименовать файлы – но только те, что скопировали, а вот оставшиеся нужно будет попросту отключить, например:

Отличия в восстановлении

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

Фраза RESETLOGS при открытии после незавершенного восстановления данных технически обязательна.

В результате мы извлечем из резервной копии таблицу SCOTT . EMP такой, какой она была 10 сентября 2004 года в 12 часов дня.

Технологические упрощения благодаря использованию RMAN

Программа RMAN из штатной поставки Oracle часто позволяет организовать процедуры резервирования и восстановления более удобно, нежели чем при ручном выполнении операций. Ниже приводится особо отчетливый тому пример. Правда, он исходит из определенных допущений, однако ни в коей мере не отражающих функциональные «ограничения» RMAN , а сделанных лишь для простоты. Конкретно будем считать, что:

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

Вот как теперь можно восстановить таблицу, используя синтаксис RMAN версии 9:

То есть мы сохранили текущие контрольный и журнальные файлы, восстановили базу на 10 суток назад, извлекли нужные данные, вернули текущие контрольный и журнальные файлы на старое место, восстановили базу «как и было» и занесли в нее старые данные таблицы.

Что последнем сценарии избыточно, а что необходимо, читатель разберется сам в порядке упражнения. Замечательно однако, что приведенный перечень действий легко оформляется файлом, то есть легко автоматизируется. Например, если приведенные команды разместить в файле restore_emp.rcm , то восстановить образ таблицы по состоянию на 10 суток назад можно, набрав в ОС:

Внимательный читатель заметит, что подобную автоматизацию можно организовать и без использования RMAN , работая через SQL * Plus . Верно, но RMAN все же открывает больше возможностей. Например, горячие копии, по которым мы восстанавливаемся, могут быть инкрементальными, а потому гораздо более компактными, что существенно для чисто физической возможности их более долговременного хранения.

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

This chapter describes how to recover tables and table partitions to a specified point in time. This chapter contains the following topics:

Overview of Recovering Tables and Table Partitions from RMAN Backups

This section describes the purpose and basic concepts of recovering tables and table partitions from RMAN backups.

There are other methods of recovering tables to a specified point in time such as Oracle Flashback and TSPITR. For more information about the scenarios in which these methods are useful and how to recover tables using these methods, see:

Purpose of Recovering Tables and Table Partitions from RMAN Backups

RMAN enables you to recover one or more tables or table partitions to a specified point in time without affecting the remaining database objects. You can use previously-created RMAN backups to recover tables and table partitions to a specified point in time.

Recovering tables and table partitions from RMAN backups is useful in the following scenarios:

You need to recover a very small number of tables to a particular point in time. In this situation, TSPITR is not the most effective solution because it moves all the objects in the tablespace to a specified point in time.

You need to recover tables that have been logically corrupted or have been dropped and purged.

Flashback Table is not possible because the desired point-in-time is older than available undo.

You want to recover data that is lost after a DDL operation modified the structure of tables. Using Flashback Table is not possible because a DDL was run on the tables between the desired point in time and the current time. Flashback Table cannot rewind tables through structural changes such as a truncate table operation.

Backups Required to Recover Tables and Table Partitions

To recover a table or table partition, you must have a full backup of undo, SYSTEM , SYSAUX , and the tablespace that contains the table or table partition.

To recover a table, all partitions that contain the dependent objects of the table must be included in the recovery set. If the indexes or partitions for a table in tablespace tbs1 are contained in tablespace tbs2 , then you can recover the table only if tablepsace tbs2 is also included in the recovery set. To recover a table, all partitions that contain the dependent objects of the table must be included in the recovery set.

To recover tables in a PDB, you need backups of the following:

SYSTEM , SYSAUX , and undo tablespace of the root

SYSTEM and SYSAUX tablespaces of the following: seed database ( PDB$SEED ) and PDB containing the tables or table partitions

Tablespace containing the tables or partitions

Basic Concepts of Recovering Tables and Table Partitions from RMAN Backups

RMAN uses the RECOVER command to recover tables or table partitions to a specified point in time.

To recover tables and table partitions from an RMAN backup, you need to provide the following information:

Names of tables or table partitions that must be recovered

Point in time to which the tables or table partitions must be recovered

Whether the recovered tables or table partitions must be imported into the target database

RMAN uses this information to automate the process of recovering the specified tables or table partitions. As part of the recovery process, RMAN creates an auxiliary database that is used to recover tables or table partitions to the specified point in time.

The steps used by RMAN to automate the recovery process are described in Steps Performed By RMAN to Recover Tables and Table Partitions.

Steps Performed By RMAN to Recover Tables and Table Partitions

RMAN performs the following steps while automating the process of recovering tables or table partitions from an RMAN backup:

Determines which backup contains the tables or table partitions that need to be recovered, based on the point in time specified for the recovery.
Creates an auxiliary database on the target host and recovers the specified tables or table partitions, until the specified point in time, into this auxiliary database.

You can specify the location on the target host to which the recovered data files are stored in the auxiliary database.

You can specify the name and the location of the export dump file used to store the metadata of the recovered tables or table partitions.

You can choose not to import the export dump file that contains the recovered tables or table partitions into the target database. If you do not import the export dump file as part of the recovery process, you must manually import it later using the Data Pump Import utility.

About the Location of Auxiliary Database Files During RMAN Table Recovery

To recover the specified tables or table partitions, RMAN creates an auxiliary database that it uses during the recovery process. Use one of the following techniques to specify the location, on the target host, that is used to store data files for the auxiliary database:

AUXILIARY DESTINATION clause in the RECOVER command

SET NEWNAME command

Use a RUN block containing the RECOVER command and required SET NEWNAME commands that rename the data files.

Oracle Database Backup and Recovery Reference for information about these commands and clauses

It is recommended that you provide a location for data files in the auxiliary database by using the AUXILIARY DESTINATION clause. When you use the SET NEWNAME command, if you omit the name of even one data file required for the recovery process, the tables or table partitions cannot be recovered.

About the Data Pump Export Dump File Used During RMAN Table Recovery

After recovering tables or table partitions to the specified point in time on the auxiliary database, RMAN creates a Data Pump export dump file that contains the recovered objects. You can either specify a name and location for this dump file or allow RMAN to use a default name and location.

Use the DATAPUMP DESTINATION clause of the RECOVER command to specify the location in which the Data Pump export dump file is created. The location is typically the path of the operating-system directory that stores the dump file. If you omit this clause, the dump file is stored in the location specified by the AUXILIARY DESTINATION parameter. If you do not specify an auxiliary destination, the dump file is stored in a default operating system-specific location. On Linux, this default location is $ORACLE_HOME/dbs . On Windows, the default location is %ORACLE_HOME\database .

Use the DUMP FILE clause of the RECOVER command to specify the name of the Data Pump export dump file . If you omit this clause, RMAN uses a default operating system-specific name for the dump file. On Linux and Windows, the default dump file name is tspitr_ SID-of-clone_n .dmp , where SID-of-clone is the Oracle SID of the auxiliary database created by RMAN to perform the recovery and n is any randomly-generated number. If a file with the name specified by DUMP FILE exists in the location in which the dump file must be created, then the recover operation fails.

About Importing Recovered Tables and Table Partitions into the Target Database

By default, RMAN imports the recovered tables or table partitions, which are stored in the export dump file , into the target database. However, you can choose not to import the recovered tables or table partitions by using the NOTABLEIMPORT clause of the RESTORE command.

When NOTABLEIMPORT is used, RMAN recovers them to the specified point and then creates the export dump file . However, this dump file is not imported into the target database. You must manually import this dump file into your target database, when required, by using the Data Pump Import utility.

If an error occurs during the import operation, RMAN does not delete the export dump file at the end of the table recovery. This enables you to manually import the dump file.

About Renaming Recovered Tables and Table Partitions During RMAN Recovery

When you recover tables or table partitions, you can rename the recovered objects after they are imported into the target database. The REMAP TABLE clause enables you to rename recovered tables or table partitions in your target database. To import the recovered tables or table partitions into a tablespace that is different from the one in which these objects originally existed, use the REMAP TABLESPACE clause of the RECOVER command. Only the tables or table partitions that are being recovered are remapped, the existing objects are not changed.

If a table with the same name as the one that you recovered exists in the target database, RMAN displays an error message indicating that the REMAP TABLE clause must be used to rename the recovered table.

When you recover table partitions, each table partition is recovered into a separate table. Use the REMAP TABLE clause to specify the table names into which each recovered partition must be imported. If you do not explicitly specify table names, RMAN generates table names by concatenating the recovered table name and partition name. The generated names are in the format tablename_partitionname . If a table with this name exists in the target database, then RMAN appends _1 to the name. If this name too exists, then RMAN appends _2 to the name and so on.

When you use the REMAP option, any named constraints and indexes are not imported. This is to avoid name conflicts with existing tables.

Limitations of Recovering Tables and Table Partitions from RMAN Backups

When you use the RECOVER command to recover tables or table partitions contained in an RMAN backup, the following limitations exist.

Tables and table partitions belonging to SYS schema cannot be recovered.

Tables and table partitions from SYSTEM and SYSAUX tablespaces cannot be recovered.

Tables and table partitions on standby databases cannot be recovered.

Tables with named NOT NULL constraints cannot be recovered with the REMAP option.

Preparing to Recover Tables and Table Partitions

The preparation for recovering tables or table partitions from RMAN backups involves the following steps:

Verifying that the prerequisites required to recover tables or table partitions are met

Determining the point in time to which the tables or table partitions must be recovered

Deciding if the recovered tables or table partitions must be imported into the target database

By default, RMAN imports the recovered tables or table partitions into the target database. However, you can specify that RMAN must not import the recovered objects.

Prerequisites for Recovering Tables and Table Partitions from RMAN Backups

The target database must be in read-write mode.

The target database must be in ARCHIVELOG mode.

You must have RMAN backups of the tables or table partitions as they existed at the point in time to which you want recover these objects.

To recover single table partitions, the COMPATIBLE initialization parameter for target database must be set to 11.1.0 or higher.

Determining the Point-in-time to Which Tables and Table Partitions Must be Recovered

It is very important to determine the exact point in time to which you want to recover the tables or table partitions. RMAN enables you to specify the required point in time using one of the following:

Recovers tables or table partitions to the state that they were at the time specified by the SCN.

Recovers tables or table partitions to the state they were in at the specified time. Use the date format specified in the NLS_LANG and NLS_DATE_FORMAT environment variables. You can also use data constants such as SYSDATE to specify the time, for example SYSDATE-30 .

Recovers tables or table partitions to the state they were at the time specified by the log sequence number and thread number.

Recovering Tables and Table Partitions

This section describes the steps required to recover tables or table partitions in a non-CDB to a specified point in time.

To recover tables or table partitions to a specified point in time:

Perform the planning tasks described in "Preparing to Recover Tables and Table Partitions" .
Start RMAN and connect as TARGET to the target database. You must connect as a user with the SYSBACKUP or SYSDBA privilege.

You can use the following additional clauses in the RECOVER command:

DUMP FILE and DATAPUMP DESTINATION

Specifies the name of the export dump file containing recovered tables or table partitions and the location in which it must be stored. See "About the Data Pump Export Dump File Used During RMAN Table Recovery" for information.

Indicates that the recovered tables or table partitions must not be imported into the target database. See "About Importing Recovered Tables and Table Partitions into the Target Database"

Renames the recovered tables or table partitions in the target database. See "About Renaming Recovered Tables and Table Partitions During RMAN Recovery"

Recovers the tables or table partitions into a tablespace that is different from the one in which these objects originally existed. See "About Renaming Recovered Tables and Table Partitions During RMAN Recovery"

For examples on recovering tables and table partitions, see:

Oracle Database Backup and Recovery Reference for more examples on recovering tables and table partitions

Recovering Tables and Table Partitions in PDBs

RMAN enables you to recover one or more tables or table partitions in a pluggable database ( PDB ) to a specified point-in-time without impacting other objects in the PDB. The steps used to recover tables or table partitions in a PDB are similar to the ones used for non-CDBs, with the differences described in this section.

To recover tables or table partitions in a PDB:

Perform the planning tasks described in "Preparing to Recover Tables and Table Partitions" .
Start RMAN and connect to the root as a user with the SYSDBA or SYSBACKUP privilege.

You must use the AUXILIARY DESTINATION clause and one of the following clauses: UNITL TIME , UNTIL SCN , or UNTIL SEQUENCE .

Depending on your requirements, you may also need to use the one or more of the following clauses: DUMP FILE , DATAPUMP DESTINATION , NOTABLEIMPORT , REMAP TABLE , or REMAP TABLESPACE .

The following command recovers the table PDB_EMP in the PDB HR_PDB to the state that it was in 4 days before the current date. HR is the name of the schema that contains the table. The recovered table is renamed to EMP_RECVR .

Examples: Recovering Tables and Table Partitions From RMAN Backups

This section contains the following examples that demonstrate how to recover tables and table partitions to a specified point in time by using RMAN backups:

Example: Recovering Tables to a Specified Point in Time

In this example, assume that you want to recover two tables EMP and DEPT to the state they were in two days ago, before some logical corruption occurred. However, you do not want RMAN to import these tables into the target database. RMAN must only create the export dump file , called emp_dept_exp_dump.dat , in the location /tmp/recover/dumpfiles . Using NOTABLEIMPORT indicates that these tables must not be imported into the target database. You can import these tables, when required, by using the Data Pump import utility. The auxiliary destination used during the recovery process is /tmp/oracle/recover .

To recover tables EMP and DEPT without importing them into the target database:

In this example, you need to recover tables to a point in time specified by an expression that uses SYSDATE . However, the recovered tables must not be imported in to the target database.

The following RECOVER command recovers the EMP and DEPT tables.

Oracle Database Backup and Recovery Reference for additional examples about recovering tables to a specified point in time

Example: Recovering Table Partitions to a Specified Log Sequence Number

In this example, the table sales , in the schema sh , contains the following partitions: sales_1998 , sales_1999 , sales_2000 , and sales_2001 . This table is stored in the sales_ts tablespace. You need to recover two partitions, sales_1998 and sales_1999 , to a point in time that is specified by a redo log sequence number. The recovered tables must be automatically imported into the target database and mapped to the tablespace SALES_PRE_2000_TS .

To recover the partitions sales_1998 and sales_1999 to a specified log sequence number:

In this example, you need to recover two table partitions to a specified log sequence number and then import these partitions into the target database.

In this case, the specified table partitions are imported as separate tables, called historic_sales_1998 and historic_sales_1999 , into the sales_pre_2000_ts tablespace of the target database. The REMAP TABLE clause specifies the names used for the imported tables. The auxiliary destination used during the recovery process is /tmp/oracle/recover .

If you omit the REMAP TABLE clause, RMAN uses default names for the imported tables. The name is a combination of the original table name and the partition name.

Читайте также: