If you are referring to which tables are used by Flashback Data Archive, a.k.a FDA, you need first to understand how Oracle works with Flashback query.
Let me show you an example. I will create a small flashback archive group and a table will be assigned to it.
SQL> create flashback archive fda_test tablespace tbrepdata quota 1g retention 1 year ;
Flashback archive created.
SQL> grant flashback archive on fda_test to test ;
Grant succeeded.
SQL> grant flashback archive administer to test ;
Grant succeeded.
SQL> GRANT EXECUTE ON DBMS_FLASHBACK_ARCHIVE TO test;
Grant succeeded.
SQL> create table test.t1 ( c1 number, c2 number ) flashback archive fda_test ;
Table created.
SQL> insert into test.t1 values ( 1 , 1 ) ;
1 row created.
SQL> insert into test.t1 values ( 2 , 2 ) ;
1 row created.
SQL> insert into test.t1 values ( 3, 3 ) ;
1 row created.
SQL> commit ;
Commit complete.
SQL> update test.t1 set c1=4,c2=4 where c1=3 ;
1 row updated.
SQL> commit ;
Commit complete.
Now, if I do a query
SQL> col versions_startscn format 9999999999999999
SQL> col versions_endscn format 9999999999999999
SQL> r
1 SELECT versions_startscn,
2 --versions_starttime,
3 versions_endscn,
4 --versions_endtime,
5 versions_xid,
6 versions_operation,
7 c1,
8 c2
9* from test.t1 versions between scn minvalue and maxvalue
VERSIONS_STARTSCN VERSIONS_ENDSCN VERSIONS_XID V C1 C2
----------------- ----------------- ---------------- - ---------- ----------
13142361651647 13001C0000AB0000 U 4 4
13142361651581 13142361651647 20002A00BD960000 I 3 3
13142361651581 20002A00BD960000 I 2 2
13142361651581 20002A00BD960000 I 1 1
Let's check the plan
SQL> set autotrace traceonly
SQL> r
1 SELECT versions_startscn,
2 --versions_starttime,
3 versions_endscn,
4 --versions_endtime,
5 versions_xid,
6 versions_operation,
7 c1,
8 c2
9* from test.t1 versions between scn minvalue and maxvalue
Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 164 | 4264 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T1 | 164 | 4264 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
5 recursive calls
4 db block gets
22 consistent gets
0 physical reads
0 redo size
1091 bytes sent via SQL*Net to client
591 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4 rows processed
As you can see, Oracle is just accessing the table. Why ? Because the data is still in the undo tablespace, as the undo blocks have not yet expired. When you use FDA, Oracle will use always this approach when you use flashback query:
- If the data to the Undo Tablespace, data is recover from it.
- If the data is no longer available in the Undo tablespace, then it will retrieve the rows from the underlying FDA table.

The underlying table contains the archive data based on the retention established for the archive group
SQL> set lines 200
SQL> SELECT owner_name,
2 table_name,
3 flashback_archive_name,
4 archive_table_name,
5 status
6* FROM dba_flashback_archive_tables where owner_name = 'TEST' and table_name = 'T1'
OWNER_NAME TABLE_NAME FLASHBACK_ARCHIVE_NAME ARCHIVE_TABLE_NAME STATUS
------------------------------ ------------------------------ ------------------------------ ------------------------------ -------------
TEST T1 FDA_TEST SYS_FBA_HIST_2779773 ENABLED
If you are sure that the data you are recovering with as of timestamp
is no longer in the undo tablespace, you can use a 10046
event to generate a trace file to really see how Oracle is really getting the data.
Although I wonder what is you are looking for in getting that level of detail.