Examine the command and its output:
SQL> DROP TABLE EMPLOYEE;
SQL> SELECT object_name AS recycle_name, original_name, type FROM recyclebin;
RECYCLE_NAMEORIGINAL_NAMETYPE
————————————————————————————————————–
binsgk31sj/3akk5hg3j21kl5j3d==$0EMPLOYEE TABLE
You then successfully execute the command:
SQL> FLASHBACK TABLE “BINSgk31sj/3akk5hg3j21kl5j3d==$0” TO BEFORE DROP;
Which two statements are true?
A.
It flashes back the employee table and all the constraints associated with the table.
B.
It automatically flashes back all the indexes on the employes table.
C.
It automatically flashes back any triggers defined on the table.
D.
It flashes back only the structure of the table and not the data.
E.
It flashes back the data from the recycle bin and the existing data in the original table is permanently lost.
ans (a,c) or (b,c)
Ans B and C
A – is wrong because the referential constraints cannot be brought back after the flashback.
They can:
The recycle bin is a logical container for all dropped tables and their dependent objects. When a table is dropped, the database will store the table, along with its dependent objects in the recycle bin so that they can be recovered later. Dependent objects which are stored in the recycle bin include indexes, constraints, triggers, nested tables, LOB segments and LOB index segments.
https://docs.oracle.com/cd/B19306_01/backup.102/b14192/flashptr004.htm
OK… It’s BC 😉
The recycle bin does not preserve referential constraints on a table (though other constraints will be preserved if possible). If a table had referential constraints before it was dropped (that is, placed in the recycle bin), then re-create any referential constraints after you retrieve the table from the recycle bin with Flashback Drop.