Where to find the SQL text in v$ views?

Question

Hi All,
Oracle 11.2.0.3 on RedHat.
I am trying to find out SQL activity on my database for a very narrow time window. Please see the SQLs I did
SQL> select distinct user_id, sql_id
  2  from v$active_session_history
  3  where sample_time between to_date('20120704012000','yyyymmddhh24miss') and
  4            to_date('20120704012200','yyyymmddhh24miss')
  5  and user_id = 111 ;
   USER_ID SQL_ID
       111
       111 gjg25k7stx9ba
       111 a8m049aj31b1y
       111 asjw7b7h99w4m
       111 fvffk1aqrb55n
       111 9gskv9b1u7mau
       111 03tsb9pp3h1uj
       111 dm0jppss5z0ay
       111 44n0svyuc000x
       111 16t1tpr7mdqnf
       111 bzpu510tng689
       111 dsqzhqdvzamys
12 rows selected.
SQL> select * from v$sqltext where sql_id='16t1tpr7mdqnf' order by piece ;
no rows selected
SQL> select * from table( dbms_xplan.display_awr('16t1tpr7mdqnf') ) ;
no rows selectedI can see the text for all SQLs in v$sqltext, except 16t1tpr7mdqnf. User id 111 is the user used to run our batch processes.
Where can I find the text for this SQL id 16t1tpr7mdqnf ?
This SQL has run about 8 hours ago.
Thanks in advance

Answer 1

When you say, ASH captures active sessions, does that mean, it only captures "session" information, which may not include details about SQL ?Exactly, it's a snapshot of session level information for active sessions.
So, session X can be executing sql statement abc123 and be captured by ASH which takes a snapshot of all active sessions every 1 second in V$ACTIVE_SESSION_HISTORY.
1 in 10 of these active sessions is stored in the repository - DBA_HIST_ACTIVE_SESS_HISTORY (in practice, this 1 in 10 sample is literally as simple as store the active sessions from every 10th second).
Independently of this, obviously you have the shared pool and V$SQL. If your statements are in here then great.
Otherwise you have AWR which captures the top N sql from each interval.
So, as mentioned, perfectly normal to have references to sql ids and sql plan hash values captured in ASH but not AWR.
One interesting thing here is, sql_exec_id is blank. What does that say? It depends.
It's likely to be one of two things:
1. some sort of bug or limitation - there are certain operations and time limits were some of the ASH values get cleared out or don't get cleared out.
2. occasionally I've seen the ASH information be misleading when it comes to certain recursive operations - one specific example I can think of related to the recursive merge of sql plan baseline metric tracking operations.