647.You executed the following commands in a database session:
What could have caused the recycle bin to clean up?
A. There is demand for space from the new table
B. The undo tablespace does not have sufficient free space
C. The new table name is the same as the table name in the recycle bin
D. The temporary tablespace that is assigned to you does not have sufficient free space
Answer: A
7.4.6 Recycle Bin Capacity and Space Pressure
There is no fixed amount of space preallocated for the recycle bin. Therefore, there is no guaranteed minimum amount of time during which a dropped object will remain in the recycle bin.
The rules that govern how long an object is retained in the recycle bin and how and when space is reclaimed are explained in this section.
7.4.6.1 Understanding Space Pressure
Dropped objects are kept in the recycle bin until such time as no new extents can be allocated in the tablespace to which the objects belong without growing the tablespace. This condition is referred to as space pressure. Space pressure can also arise due to user quotas defined for a particular tablespace. A tablespace may have free space, but the user may have exhausted his or her quota on it.
Oracle never automatically reclaims space or overwrites objects in the recycle bin unless forced to do so in response to space pressure.
7.4.6.2 How the Database Responds to Space Pressure
When space pressure arises, the database selects objects for automatic purging from the recycle bin. Objects are selected for purging on a first-in, first-out basis, that is, the first objects dropped are the first selected for purging.
Actual purging of objects is done only as needed to meet ongoing space pressure, that is, the databases purges the minimum possible number of objects selected for purging to meet immediate needs for space. This policy serves two purposes:
-
It minimizes the performance penalty on transactions that encounter space pressure, by not performing more purge operations than are required;
-
It maximizes the length of time objects remain in the recycle bin, by leaving them there until space is needed.
Dependent objects such as indexes on a table are selected for purging before the associated table (or other required segment).
If space pressure is due to an individual user's quota on a tablespace being exhausted, the recycle bin purges objects belonging to the tablespace which count against that user's space quotas.
For AUTO EXTEND-able tablespaces, objects are purged from the recycle bin to reclaim space before datafiles are extended.
7.4.6.3 Recycle Bin Objects and Segments
The recycle bin operates at the object level, in terms of tables, indexes, and so on. An object may have multiple segments associated with it, such as partitioned tables, partitioned indexes, lob segments, nested tables, and so on. Because the database reclaims only the segments needed to immediately satisfy space pressure, it can happen that some but not all segments of an object are reclaimed. When this happens, any segments of the object not reclaimed immediately are marked as temporary segments. These temporary segments are the first candidates to be reclaimed the next time space pressure arises.
In such a case, the partially-reclaimed object can no longer be removed from the recycle bin with Flashback Drop. (For example, if one partition of a partitioned table is reclaimed, the table can no longer be the object of a Flashback Drop.)