Sql tuning set explain plan

Question

A hypothetical question came up between dbas in the office.   We regularly take tuning sets before making significant changes on the DB.  Populate from cache.  Great little way of checking to see if anything changed.  Someone asked if a table T1 was accessed during a given day where we had a tuning set being populated from the cache (no reason for auditing to be on at the time).  Well first thing to do is search the sql_statements
select * from DBA_SQLSET_STATEMENTS
where sqlset_name = 'my_sts'
and sql_text like '%select * from t1%'
but no rows returned, so next idea is to query the plan in case a synonym was used
select * from DBA_SQLSET_PLANS
where sqlset_name = 'my_sts'
and object_name = 'T1'
And yes, its there we had a select against the table, the main sql_text in the dba_sqlset_statments view was using a synonym.  great, so now we might be able to use this as a alternative audit method (mmv depending on whether you have the diag pack). 
Heres the question, can we always be guaranteed an object will be in a plan?

Answer 1

Dom Brooks wrote:
Also, the presence of a SQL statement in the shared pool does not indicate it was run today - you'd need to check the relevant column, something like last_active_time.
More importantly, the absence of a SQL statement from the shared pool does not indicate that it was not run today.
Just that it's no longer in the shared pool.
I'm concious of that when running the populate,  even in a busy period our pools last over an hour,  with that in mind when Im populating my tuning set, I set the frequency to 10 minutes to poll the cache where distinct IDs and HASHes are overloaded in the tuning set if theyre already there. 
http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_sqltun.htm#CACJHDDC
Note that in production systems the time limit and repeat interval would be set much higher. You should tune the time_limit and repeat_interval parameters based on the workload time and cursor cache turnover properties of your system.