Performing Oracle Advanced Recovery - OCP: Oracle Database 12c Administrator Certified Professional - page 319

COUNT(*)
----------
0
SQL> select count(*) from SALGRADE;
COUNT(*)
----------
5
During testing, something terribly bad happens. Instead of individual rows being deleted,
the new bulk update application, lacking an appropriate WHERE clause in the DELETE state-
ment, managed to remove all the records in all the tables instead of unique ones. After the
application ran, the row counts looked like this:
SQL> select count(*) from DEPT;
COUNT(*)
----------
0
SQL> select count(*) from EMP;
COUNT(*)
----------
0
SQL> select count(*) from BONUS;
COUNT(*)
----------
0
SQL> select count(*) from SALGRADE;
COUNT(*)
----------
0
It's a shame, but the developers also forgot to export their test schema before the test.
It's not a good day for the developers. The developers are upset about the loss of their data
and the knowledge that the whole database will probably have to be restored instead of just
the HR schema. Lots of good and important data exists in other schemas.
They call you, their DBA, and ask how they can get their data restored. Fortunately for
you, the database is running Oracle Database 12 c . You tell them to hang tight and you will
take care of the problem. After asking them what time they started their testing, you tell them
you will restore HR to the second before testing and get back to them when you have finished.
One important bit of information that the developers were able to give you was the specific
point in time that you need to restore the table objects to. We will assume it's the same time
and date that the query against V$DATABASE gave us earlier in this section.
Sitting down at your laptop you set your Oracle environment for the correct database and
start RMAN. Now you use the RMAN RESTORE command to restore the tables in the HR