Database Reference
In-Depth Information
Because the Recycle Bin is a logical container, as opposed to a physical con-
tainer, there is no Recycle Bin tablespace or data file into which the dropped
objects are moved. Instead, the objects remain in their original tablespace
and are simply renamed using a special naming convention. This naming
convention ensures that database objects with the same name will not be
assigned duplicate identifiers when they are moved into the Recycle Bin.
Demonstrating How the Recycle Bin Works
To demonstrate how objects interact with the Recycle Bin, this section will provide a series of
examples showing how a dropped table is represented in the Recycle Bin. We will use the HR
sample schema provided with the 12 c database and grant DBA privileges to the HR schema
to simplify the execution of the examples. To begin, we first must drop a table, as shown here:
SQL> drop table job_history;
Table dropped.
Once the table has been dropped, our next step is to view the contents of the Recycle
Bin to verify that the table is truly there. One simple way to do this is to use the SHOW
RECYCLEBIN command, as shown here:
SQL> show recyclebin
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ -------------------
JOB_HISTORY BIN$2siLENifTmCBmAu0+mXAuQ==$0 TABLE 2013-09-16:12:45:37
For a table to be recoverable using Flashback Drop, it can't reside in
the SYSTEM tablespace, and the tablespace in which it resides must be
locally managed.
The SHOW RECYCLEBIN command confirms that our table now resides in the Recycle Bin,
as expected. It also provides several other pieces of useful information. These are described
in TableĀ 8.1.
TABleĀ 8.1 SHOW RECYCLEBIN Columns
Column Name
Description
ORIGINAL NAME
This column stores the original name of the object (at the time when
it was dropped).
 
Search WWH ::




Custom Search