Database Reference
In-Depth Information
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 20.09.2013 21:39
Statement processed
Although the technology is not really new—you could achieve the same result in 11.2—the syntax is very
straightforward and especially with OMF the switch to the new data file name is done automatically in the control file.
Both of these commands you just read about are a huge convenience boost.
Point-in-Time Table Recovery
Despite all the great tools available to the database administrator to prevent “accidental” changes to a table or set of
tables, mistakes do happen. Sometimes it is impossible to recover a table. This could be because a Flashback Version
Query has run out of undo or a table has been dropped with the “purge” keyword. Or an over-eager DBA has issued
a “purge dba_recyclebin” command to free up space... The list is long. In previous Oracle versions you almost always
had to do a point-in-time recovery in this case. If your data was self-contained on a tablespace then you were lucky
to be able to perform a Tablespace Point-in-Time Recovery or TSPITR. But sometimes objects were scattered across
multiple tablespaces, making a TSPITR impossible. In that case you had to bite the bullet and perform a full point in
time recovery. Not necessarily in your production environment! A restore of a backup from before the accident on a
different host may enable your application developers to get enough data to produce a set of scripts and export dumps
to rectify the situation.
The inevitable question this build-up of tension should provoke is: is there no other way to do this? With Oracle
12c there is indeed, and it is available in the form of an extension of the RMAN recover command. Luckily the designers
thought of Pluggable Databases as well, which is what this section covers. Non-CDBs have this functionality available too.
The following example demonstrates the use of the “recover table” command. While connected to a PDB, additional
tablespaces are created, which all will contain a table, plus a unique index. The scenario presents itself as follows:
USER1@PDB1> select table_name,tablespace_name from tabs;
TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
T_3 PDB1_TBS_3
T_1 PDB1_TBS_1
T_2 PDB1_TBS_2
Each of these tables has been created using the “create table ... as command”, using dba_objects as the source.
To demonstrate the usefulness of the new feature a little chaos will be created, simulating an inexperienced operator.
The current SCN of the database has been found to be 1993594.
USER1@PDB1> truncate table t_3;
Table truncated.
USER1@PDB1> truncate table t_2;
Table truncated.
USER1@PDB1> drop table t_1 purge;
Table dropped.
 
Search WWH ::




Custom Search