That is a common misconception, one that Oracle wholeheartedly supports. Flashback Query (FBQ) depends upon the smon_scn_time table, which is popluated in 9i, regardless of the undo_management setting. This table is populated regardless of the UNDO_RETENTION parameter. This parameter is the guideline (not absolute) that Oracle uses when deciding which extents to reclaim when it needs space. If Oracle needs space, it may take extents containing committed transaction info that is still within the UNDO_RETENTION time.
You can perform FBQ using RBSs, though this is probably not supported by Oracle, so use it at your own peril. The chances of success are diminished because of the difference in undo space management (rbs reuses space more often). I have done this several times, but in a non-production environment.
IIRC, v$undostat is not populated unless the undo_management is set to auto. This really does not help in making the transition from rbs to aum. It would be nice to have it populated regardless so that you would have data to use to set the undo tablespace size and the value of UNDO_RETENTION.
I did make one mistake. You have to enable flashback for a table or have the flashback_any_table privilege (Thanks, Kirti).
Dan
Gogala, Mladen wrote:
Flashback query is enabled by setting the UNDO_RETENTION parameter to thedesired number of seconds. Table V$UNDOSTAT contains the column MAXQUERYLENwhich gives the max time that you can use to dynamically set UNDO_RETENTION.You also have to enable flashback for session using DBMS_FLASHBACK.Mladen Gogala
Oracle DBA
Phone:(203) 459-6855
Email:[EMAIL PROTECTED]
