Q:

mysterious oracle query

if a query in oracle takes the first time it is executed 11 minutes, and the next time, the same query 25 seconds, with the buffer being flushed, what is the possible cause? could it be that the query is written in a bad way?
set timing on;
set echo on
set lines 999;

insert into elegrouptmp select idcll,idgrpl,0 from elegroup where idgrpl = 109999990;
insert into SLIMONTMP (idpartes, indi, grecptseqs, devs, idcll, idclrelpayl)
    select rel.idpartes, rel.indi, rel.idgres,rel.iddevs,vpers.idcll,nvl(cdsptc.idcll,vpers.idcll)
from
    relbqe rel,
    elegrouptmp ele,
    vrdlpers vpers
    left join cdsptc cdsptc on
            (cdsptc.idclptcl = vpers.idcll and
             cdsptc.cdptcs      = 'NOS')
where
    rel.idtits = '10BCPGE ' and
    vpers.idbqes = rel.idpartes and
    vpers.cdqltptfc = 'N' and
    vpers.idcll = ele.idelegrpl and
    ele.idgrpl = 109999990;

alter system flush shared_pool;
alter system flush buffer_cache;
alter system flush global context;

select /* original */ mvtcta_part_SLIMONtmp.idpartes,mvtcta_part_SLIMONtmp.indi,mvtcta_part_SLIMONtmp.grecptseqs,mvtcta_part_SLIMONtmp.devs,
mvtcta_part_SLIMONtmp.idcll,mvtcta_part_SLIMONtmp.idclrelpayl,mvtcta_part_vrdlpers1.idcll,mvtcta_part_vrdlpers1.shnas,mvtcta_part_vrdlpers1.cdqltptfc,
mvtcta_part_vrdlpers1.idbqes,mvtcta_part_compte1.idcll,mvtcta_part_compte1.grecpts,mvtcta_part_compte1.seqc,mvtcta_part_compte1.devs,mvtcta_part_compte1.sldminud,
mvtcta.idcll,mvtcta.grecptseqs,mvtcta.devs,mvtcta.termel,mvtcta.dtcptl,mvtcta.nusesi,mvtcta.fiches,mvtcta.indl,mvtcta.nuecrs,mvtcta.dtexel,mvtcta.dtvall,
mvtcta.dtpayl,mvtcta.ioi,mvtcta.mtd,mvtcta.cdlibs,mvtcta.libcps,mvtcta.sldinitd,mvtcta.flagtypei,mvtcta.flagetati,mvtcta.flagwarnl,mvtcta.flagdonei,mvtcta.oriindl,
mvtcta.idportfl,mvtcta.extnuecrs
from SLIMONtmp mvtcta_part_SLIMONtmp
left join vrdlpers mvtcta_part_vrdlpers1 on
(
   mvtcta_part_vrdlpers1.idbqes = mvtcta_part_SLIMONtmp.idpartes
   and mvtcta_part_vrdlpers1.cdqltptfc = 'N'
   and mvtcta_part_vrdlpers1.idcll = mvtcta_part_SLIMONtmp.idcll
)
left join compte mvtcta_part_compte1 on
(
   mvtcta_part_compte1.idcll = mvtcta_part_vrdlpers1.idcll
   and mvtcta_part_compte1.grecpts = substr (mvtcta_part_SLIMONtmp.grecptseqs, 1, 2 )
   and mvtcta_part_compte1.seqc = substr (mvtcta_part_SLIMONtmp.grecptseqs, -1  )
   and mvtcta_part_compte1.devs = mvtcta_part_SLIMONtmp.devs
   and (mvtcta_part_compte1.devs = ' ' or ' ' =  ' ')
   and mvtcta_part_compte1.cdpartc not in ( 'L' , 'R' )
)
left join mvtcta mvtcta on
(
   mvtcta.idcll = mvtcta_part_SLIMONtmp.idclrelpayl
   and mvtcta.devs = mvtcta_part_SLIMONtmp.devs
   and mvtcta.grecptseqs = mvtcta_part_SLIMONtmp.grecptseqs
   and mvtcta.flagdonei <> 0
   and mvtcta.devs = mvtcta_part_compte1.devs
   and mvtcta.dtvall > 20101206
)
where 1=1
order by mvtcta_part_compte1.devs,
mvtcta_part_SLIMONtmp.idpartes,
mvtcta_part_SLIMONtmp.idclrelpayl,
mvtcta_part_SLIMONtmp.grecptseqs,
mvtcta.dtvall;

A:

"if a query in oracle takes the first
  time it is executed 11 minutes, and
  the next time, the same query 25
  seconds, with the buffer being
  flushed, what is the possible cause?"

The thing is, flushing the DB Buffers, like this ...
alter system flush shared_pool
/

... wipes the Oracle data store but there are other places where data gets cached.  For instance the chances are your OS caches its file reads.  
EXPLAIN PLAN is good as a general guide to how the database thinks it will execute a query, but it is only a prediction.  It can be thrown out by poor statistics or ambient conditions.  It is not good at explaining why a specific instance of a query took as much time as it did. 
So, if you really want to understand what occurs when the database executes a specific query you need to get down and dirty, and learn how to use the Wait Interface.  This is a very powerful tracing mechanism, which allows us to see the individual events that happen over the course of a single query execution.  Each version of Oracle has extended the utility and richness of the Wait Interface, but it has been essential to proper tuning since Oracle 9i (if not earlier).  
Find out more by reading  Roger Schrag's very good overview .
In your case you'll want to run the trace multiple times.  In order to make it easier to compare results you should use a separate session for each execution, setting the 10046 event each time.  

